Message-ID: From: Shawn Hargreaves 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) Content-Type: text/plain; charset="iso-8859-1" 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.