Archived

This topic is now archived and is closed to further replies.

Foxbear kikz my arse in performance!why?

This topic is 6357 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Man that sucks! I am having the same problems with my game! So come on all you geniuses (or should that be genii?) out there, reply to this post and give poor SikCiv (oh, and me) a hand here!

wise_guy

Share this post


Link to post
Share on other sites
Guest Anonymous Poster


You can also try adding another buffer into your flipping chain...set backbuffer count = 2 see if that helps.

Share this post


Link to post
Share on other sites
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?


Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
About your question about 24bit to 16bit conversion... no, DirectDraw does not convert to and from color modes. You are responsible to do this yourself. When you set a display mode, all the surfaces created in the future will be in the same color mode. So, this should not cause the slowdown...

BTW, what color mode does FoxBear run in?

VBMaster

Share this post


Link to post
Share on other sites
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?

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



Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Foxbear counts actual flips called by ->flip() using the wait flag. My game works the same.

The only difference is that *at the moment for debug reasons* my game is ONLY blitting a 640x480x16bit surface and flipping it, whilst foxbear is blitting about 4 huge colorkeyed trees, a bgnd, and a few sprites...acheiving 60FPS. Im getting 31 FPS at the most (in fullscreen)!

My surface IS in VidMem, so really all im doing is blitting from vidmem to vidmem using NO colorkeying, then doing a standard flip.

Ive even checked Foxbears routine for blitting and flipping, its the same as mine, but somehow my app refuses to give me credit.

Share this post


Link to post
Share on other sites
WhichLord was right, im using the debug libs!!!!!

I recompiled Foxbear using the DX7 Debug libs, and its getting the same framerate as my app.

I cant find my DX7 CD, can someone email me the DX7 Release libs to me?

Or can I disable debugging using the debug libs?
Ive noticed when I link my app, there is a command being used called -Debug:full, how do I set it to no debugging (im not very familiar with makefiles)?

This is my makefile (parts of it)

[
!include
#!include "dxsdk.inc"

proj=CApp

mycflag=/G5 /GX /RELEASE
#mycflag=/G5 /GX /DEBUG



cl ....etc..
..
..


$(proj).res: $(proj).rc
rc -r -fo $(proj).res $(proj).rc

$(proj).exe: $(objs) $(proj).res
$(link) $(guiflags) -out:$(proj).exe \
$(objs) $(proj).res \
$(guilibs) dxguid.lib ddraw.lib winmm.lib ijl.lib dsound.lib uuid.lib ole32.lib


]



(SikCiv@Hotmail.com)

Thanks.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Have you tried the Foxbear example that comes with MGL? I find MGL a million times better to code for than DirectDraw and it''s cross platform. Give that a try, you wont regret it.
http://www.scitechsoft.com/

I know it doesn''t directly solve your DirectDraw problem, but it sort of does.

Share this post


Link to post
Share on other sites