Make sure your back buffer is in system memory not video memory, even if you do that you probably shouldn''t be getting more then about 50 fps but its probably not your bliting routine thats slowing it down.
Bliting is probably like less then 5% of the time its taking per frame. Updating the front buffer is what is likely to be using the majority of your time at this state in your engine because access video memory is extremely slow, and to update the front buffer software the cpu has to copy the whole screen from system memory to video memory.
And if your wondering it would be even slower to have the backbuffer in video memory cause then all your blit routines would would have to access video memory, and thats worse.
The memcpy blit is probably the fastest your going to get (you might be able to shave a few cycles off the outer loop if you wrote it in asm but entirely not worth it). But if you wanna do fancier blits (like alpha blending, or colorkeying) you should do the blit in the same way only replace memcpy with your own function thats written in asm, that way when writing those pain in the ass asm functions you only have to deal with one line at a time at let C handle the rest. Atleast thats the way I did it in the past but I was working on a 200mhz proccessor.
custom graphics functions too slow
quote:Original post by keethrusI think you are misunderstanding the point: Poeple aren''t suggesting you make your game 3D, they are suggesting you use a graphics library that takes advantage of hardware acceleration. Direct3D and OpenGL can both be used to make 2D programs, but using them you will get all kinds of neat features for ''free'', like alpha blending. Such effects in software are relatively slow, but in hardware they are extremely fast and don''t take CPU time you can use to do other things (like AI, procedural texture generation, running scripts to make a more intractive game, etc)
thanx for the replies. i understand that nowadays games are hardly 2D anymore. however, the game im developing is a top-down 2D game, where the focus isnt 3D graphics.[...]
[edited by - Big Brother on January 1, 1984 12:00:00 AM]
quote:Original post by Extrarius
I think you are misunderstanding the point: Poeple aren't suggesting you make your game 3D, they are suggesting you use a graphics library that takes advantage of hardware acceleration. Direct3D and OpenGL can both be used to make 2D programs, but using them you will get all kinds of neat features for 'free', like alpha blending. Such effects in software are relatively slow, but in hardware they are extremely fast and don't take CPU time you can use to do other things (like AI, procedural texture generation, running scripts to make a more intractive game, etc)
i know, i already acknowledged that.
quote:Original post by keethrus
i know i could still use hardware to make my graphics faster, 2D or not, but im still curious as to how to speed up my own custom graphics functions, even if its soley for learning purposes.
- jeremiah
inlovewithGod.com
[edited by - keethrus on May 6, 2003 4:03:57 PM]
quote:Original post by RPGeezus
If you are using the Windows GDI you'll have to remember that it is quite slow to draw to the screen. Even if your code is lightning fast, you're screen updates wont be.
The slowness of GDI has been greatly exaggarated. We published a 2D game drawing in resolutions from 1024x768 to 1600x1200 with completely reasonable framerates using nothing but SetDIBitsToDevice. Would it be faster with DirectDraw? Probably. Would this make the game better? Probably not.
[edited by - assen on May 7, 2003 11:43:05 AM]
Make sure you''re not compiling in Debug mode (assuming MSVC).
Switching to Release will usually give you about 3-10x speedup
Switching to Release will usually give you about 3-10x speedup
i just wanted to say thanx for all the replies!
ap: im using mingw as my compiler, so ill have to check if it has any debug or release modes and see what im doing. thanx.
- jeremiah
inlovewithGod.com
ap: im using mingw as my compiler, so ill have to check if it has any debug or release modes and see what im doing. thanx.
- jeremiah
inlovewithGod.com
quote:Original post by assen
The slowness of GDI has been greatly exaggarated. We published a 2D game drawing in resolutions from 1024x768 to 1600x1200 with completely reasonable framerates using nothing but DrawDIBitsToDevice. Would it be faster with DirectDraw? Probably. Would this make the game better? Probably not.
Good point-- I don't want to give the impression that GDI is so slow it's unuseable. As mentioned earlier, I've never had a speed issue with it that couldn't be attributed to something else. It's just not as fast as Direct Draw or the other direct access options..
I'm not familiar with the DrawDIBitsToDevice call. I searched MSDN for it and came up empty. Is this something you've written in house?
Could you post a URL to your game?
Cheers,
Will
[edited by - RPGeezus on May 7, 2003 10:37:50 AM]
quote:Original post by RPGeezus
I''m not familiar with the DrawDIBitsToDevice call. I searched MSDN for it and came up empty. Is this something you''ve written in house?
No, it''s something I quoted from memory :-)
It''s SetDIBitsToDevice, of course.
quote:
Could you post a URL to your game?
http://www.haemimontgames.com/celtickings/index.html
http://www.gamerankings.com/htmlpages2/22353.asp
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement