delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/10/22/13:43:01

Message-ID: <F77915E7F086D31197F4009027CC81C9027B34@ASL-NT-EXCH2>
From: Shawn Hargreaves <SHargreaves AT acclaimstudios DOT co DOT uk>
To: djgpp AT delorie DOT com
Subject: Re: Plague of the slow 'blit' routine :)
Date: Fri, 22 Oct 1999 14:24:21 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Reply-To: djgpp AT delorie DOT com

Tom Fjellstrom writes:
> The only way I have thought of determining that a bitmap is in
> video memory is too add a variable to the bitmap struct when indicate
> creating it to whether or not it is in video memory.

That certainly sounds like a good idea to me: there are many, many
situations where you might want to know what type of bitmap you
are dealing with, so it only seems sensible to store that information
somewhere in it! I would suggest as a flags bitfield, so you can
easily add other information as well as what type of memory it lives
in.

> If that is the only safe way of doing it I guess i'll have to.

If your problem is that you need to move from A to B, where either
or both of these might need to use farptr memory accesses but you
don't know which, a very simple (and fast) method would be to use 
the movedata() library function. Or if you are doing this yourself
in asm, load %ds and %es with the relevant selectors, use a 
rep; movs instruction to copy the data, and then make sure to put
%ds and %es back when you are done!

If you have a lot of functions that need to do different things
depending on what type of bitmap you are using them with, though,
you may find it both simpler and faster to do this by storing a
pointer to the function inside your bitmap structure, so it can
automatically go straight to the right bit of code. Allegro does
this for almost all graphics related code, and since it sounds
like your setup is quite similar to how Allegro bitmap objects
behave, this might not be a bad idea for you also. It also 
gives you far more flexibility if you need to do other unexpected
things in the future, like writing different drawing code for
other color depths, wanting to support unusual ways of drawing
things for special hardware modes, etc...


	Shawn Hargreaves.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019