Recently ive tested my game on a Toshiba Portege 3010CT laptop expecting a poor performance due to the laptops seedy 2D on-board chip. I was right, my game ran at 11 FPS in Fullscreen and windowed mode @ a res of 640x480x16bit. Then for some unknown reason I excecuted the foxbear sample, and to my immediate suprise, Foxbear performed at a whopping 60FPS in FS and Windowed mode(!!!!!!!!) Obviously my game hasnt been coded properly, so i performed some tests, i.... 1) Moved all my surfaces to Video memory - only 2 FPS more. 2) Removed some excess blits per frame update - slight improve. 3) Removed all colorkeying - slight improvement. 4) Removed my UpdateFrame function and replaced it with: TempFrameUpdate() { // THIS IS ALL MY BLITTING lpDDSBack->BltFast(0,0,lpDDSBgnd, NULL, DDBLTFAST_WAIT); Flip(); // With 2 FPS improvement! } 5) I stopped all blitting! Resulting in 160FPS in Windowed mode. (cool..if i didnt want gfx) After all this I managed to get my FPS to A WHOPPING 15 FPS;-( (all im doing is blitting a 640x480 surface to the backbuffer, and doing a flip) -------------------------- -------------------------- Foxbear has lotza colorkeyed blits, about 3 huge trees, a full size background, and 2-4 blits, resulting in 60FPS at the same res as my app (even at 800x600 is runs at 60FPS!!) My Game... 1) is only blitting a full size background WITHOUT colorkeying. 2) My background surface is now in VidMem 3) no other routines are called 4) no other threads exist. 5) im using one back buffer,ive tried 2 and 0, with no luk 6) i use ->flip() for FS and ->Blt in Windowed mode. 7) I use BltFast where possible. 8) I always use DDBLT_WAIT in all my flip and blit calls. 9) My Primary and back buffers are created the same way as Foxbear. 10) I tried it on other systems, including a desktop - same prob. 11) My tolerance with DirectX is moving to another postcode. WhATs GoINg On ? How can one little 640x480 blit to the backbuffer kill 45 frames?

Ive tried 2 back buffers - still no improvement.

As for the DDBLTFAST_WAIT flag, it shouldnt affect the performance... Foxbear uses the WAIT flag, and my game is only blitting a single surface and flipping it right after the blit, nothing else is being calculated or blitted to slow the blitting timing, so all the games "power" is concentrated on just blitting and flipping.

------------------------

Question:

If u load a 24Bit BMP file to a surface, does it convert to 16bit if the Primary surface is 16bit? Maybe the problem is when the ->Blit function blits to the back buffer, maybe its converting 24bit data to 16bit before it blits?

Im thinking I need to convert my bitmaps to 16bit when loading the BMP''s, BUT I have a routine that reads the data of a surface source from a 24bit BMP, and its in 16bit format(2 bytes per pixel), so it shouldnt affect the performance ... but still, knowing DirectX there are some little things that can affect the overall performance of the app..



Anyone?

How big is the bitmap you are blitting, is it in VRam or SysMem? SysRam to VRam blitting is very slow

Im Always Bored
--Bordem
ICQ: 76947930

I managed to get 60 FPS in Fullscreen mode, but thats when im only blitting a 640x480x16bit surface to the backbuffer (nothing else). The surface is in Vidmem, if i put it in sysmem I get 13FPS. But when in Windowed mode I still only get 13FPS...why?
I have a backbuffer in windowed mode, is this necessary? Can I scrap the windowed backbuffer and just blit to the primary surface?

I also have 3 other 640x480 surfaces but they are in sysmem, and only a graphical mouse cursor is being blitted from one of the surfaces every frame, surely this cant degrade the performance by 70%? How does 3 extra surfaces slow the FPS down when they arent even being used?

Foxbear runs at multiple resolutions changable to whatever the video card is capable of by pressing F6.

With the color conversion, my primary surface is 16bit, but my BMP''s are 24bit, which are converted to 16bit by LoadResource()?? in ddutil.cpp. I know this because i have a routine that reads one of my surfaces, and its 16bit for every pixel. I think its just a vidmem-sysmem problem.


You''d think Microsoft would put an automated surface management system in DDraw to optimize Surface transferres/blits...Maybe in DirectX8 !?!?


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

By the way, when is DX8 going to be released?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

In past projects, I was able to speed it up a lot by checking whether the system was ready to flip. If it wasn''t I just moved on to the next frame, drew it, and checked the flipping status again. (instead of waiting for the system to be ready to flip).

I''m not familiar with this "Foxbear" demo you''re speaking of (sorry!) but is it possible that the demo is a bet messed? Like, does it count how many frames are *flipped*, or drawn per cycle? If it''s .drawn per cycle. then I think the above should up the frame rate.

Either way it should speed it up lots //it did for me.

~Queasy.