On Sat, Apr 03, 2004 at 08:34:38PM -0500, Tim Hentenaar wrote:
I had a look, and implemented a clip list with one rect to use the same code as with an hWnd since they are virtually the same. This app is wierd in the fact that it dosen't use the hWnd for clipping with one rect, but rather a clip list with one rect. That fixed the drawing somewhat.
Well, it's not THAT strange... Ie if you want to use the features of the clipper in, for example, a full screen applications, you do not need to create a HWND which is the size of the rectangle, you can just add your own clip list. And, if the hardware supports clipping with Blits, you gain time as you do not have to do a lot of stuff in the game engine (all the rectangle intersection code).
In OpenGL-land, this is called 'glScissor' :-)
So, if your game uses only one rectangle, it should be pretty easy to map to the current code. Of course, if it uses more than one, some adaptations would be needed :-/
For instance, I noticed that the app sets the clip list, then tries to blit to a destination rect that isn't present in the clip list. I'm guessing that it's meaning to clip the source rect, but why you would clip the source surface is foreign to me. :P
What do you mean by 'a destination rect that isn't present in the clip list' ?
I'll have to dig a little deeper yet to figure this out. The main thing that irks me, is that even with clipping implemented, wherever it has to draw any sort of constant animation it's horribly slow (most of the time). Though when it plays a movie it plays perfectly. I'm guessing this would be a flaw in the game engine.
Oh well, it can be LOTS of stuff... In Windows, they have direct frame buffer access so some games (like MI3) did a lot of updates of the screen (which leads to a lots of traffic in Wine between game memory, X11 and the frame buffer). It works perfectly well in Windows and will be slow as hell in Wine.
Lionel