Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE30141121D@probe-2.acclaim-euro.net> From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: Re: scare_mouse() alternatives? Date: Mon, 7 Jun 1999 16:19:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Reply-To: djgpp AT delorie DOT com Jan Hubicka writes: > It can be nice, if allegro had some way to let me draw cursor to > bitmap (w/o removing original one on screen), putting bitmap with > the cursor to screen and then reventing back to normal mode draving > cursor on screen. This can avoid flickering in such bitmap blits. I don't see how this can be done in a suitably generic way, though. It is easy enough to lock the Allegro cursor while you do the blit (by setting the freeze_mouse flag), so you could lock it in place, draw your cursor to the memory buffer, do the blit, and then unlock the real cursor, but at this point Allegro will be left with a stale copy of what used to be underneath the cursor, so the screen will be corrupted as soon as the user moves the mouse. I can't see any way to automatically update the cursor backbuffer other than putting checks in every single piece of drawing code, which would be prohibitively expensive. Alternatively I could provide a function for the user to explicitly update the buffer with a new image, but that would be messy and too implementation specific for me to be happy with it (for example this wouldn't apply when using VBE/AF hardware cursors, running under X, etc). I think the best solution here is for you to just write your own pointer display code. That is trivial to do: just install a timer handler that copies a sprite to the screen at regular intervals. The differencce is that unlike Allegro, you presumably have a complete copy of the image in system memory, so you can use this to accurately remove the old pointer without any danger of restoring the wrong image and leaving trails. When you ask Allegro to display a mouse pointer, you are essentially setting up a second execution thread that is constantly updating the screen. Having two different threads trying to use the same resource at the same time is never a good idea, so the best thing is just not to do that... Shawn Hargreaves.