Bliting from system mem to vid mem. Please read
Author
OK i guess this might be a bit of a "newbie" question but i''ve either missed something or i''m not as good at this as thought i was.
I''m running a little game which purrs along at a fairly decent (i think) max of about 250 fps, Bliting about 800K of image data every frame. I''ve been quite happy with that but recently i''ve forced it to run using system memory and i''ve seen the frame rate dive to a little over 80 fps.
after a little investigation i''ve found that simply bliting the secondary buffer from system memoy to the primary surface adn displaying the fps each turn results in a little performance increase (shock!) but only to 90-100fps. So i''m thinking either i''ve got the directDraw stuff setup wrong, it''s the windows message processing stuff thats slowing things down OR i''m missing something.
Go on, someone give me a hint. I would start pulling apart my code randomly but it''ll take 10 times as long compared to informed targetting of which code to destroy.
cheers for any pointers,
zipless
A little more information on what the surface sizes are and how they are being used might be helpful..
I''d say its most likely you''re just running into fillrate limitations on the video card. Moving all your surfaces from video memory only to system memory is of course going to be a big performance hit (especially if it introduces a need to read from videomemory..are you using any alpha blending?)... Now the program has to transfer the memory from general RAM to VRAM every frame and that takes time (how much is obviously dependent on how large the surfaces are, in width/height/bitdepth).
Why is it that you''re forcing everything into system memory, anyway? You should use video memory whenever possible. You can mix the two -- init the surfaces likely to be drawn most first and put them in video memory and then just put things in system memory when you run out of space in VRAM.
If you absolutely NEED to run in system memory for some reason, consider doing all of your rendering to an offscreen system memory buffer that''s the same size as the framebuffer(s) and then blit the parts of that offscreen buffer that have been changed each frame (using a simple dirty rectangle system) to the main framebuffers..You''ll usually get much better results that way, especially if you''re drawing lots of surfaces to the screen that may obscure each other..It saves you from writing a lot of pixels from system-mem->VRAM each frame that won''t be displayed anyway)
I''d say its most likely you''re just running into fillrate limitations on the video card. Moving all your surfaces from video memory only to system memory is of course going to be a big performance hit (especially if it introduces a need to read from videomemory..are you using any alpha blending?)... Now the program has to transfer the memory from general RAM to VRAM every frame and that takes time (how much is obviously dependent on how large the surfaces are, in width/height/bitdepth).
Why is it that you''re forcing everything into system memory, anyway? You should use video memory whenever possible. You can mix the two -- init the surfaces likely to be drawn most first and put them in video memory and then just put things in system memory when you run out of space in VRAM.
If you absolutely NEED to run in system memory for some reason, consider doing all of your rendering to an offscreen system memory buffer that''s the same size as the framebuffer(s) and then blit the parts of that offscreen buffer that have been changed each frame (using a simple dirty rectangle system) to the main framebuffers..You''ll usually get much better results that way, especially if you''re drawing lots of surfaces to the screen that may obscure each other..It saves you from writing a lot of pixels from system-mem->VRAM each frame that won''t be displayed anyway)
Author
Yeah sorry in my attemp to keep the post short i''ve left stuff out, here goes.
I''m forcing it into system memory as it''s only a simple(ish) 2D game and i want it to run on almost anything. The particular case in question is my mates Duron 600 with the sucky onboard gfx (which has a truly astounding 12K of free video memory).
I''m running in windowed mode, using a 640x480 window and the fps rates are all for 16 bit surfaces. I''m creating all my surfaces in system memory so theres only 1 blit to video memory once per frame when i transfer the secondary to the primary surface. I''m not reading anything from vid mem.
The background blited to the secondary surface is made of 32x32 tiles (forgot about them earlier) so i''ve got 300 Blits from sys to sys moving a total of 600K, then another 100K or so Blited before the entire surface (600K) is Blited from sys to vid mem. I make that 600*100 = 60Megs per second. Now i''m using a GeforeDDr and i''m damm sure that the bandwidth is far greater than 60 megs per second.
Unless the overhead on the Blits is way higher than i expected for some reason then i should be getting much better frame rates.
zipless
I''m forcing it into system memory as it''s only a simple(ish) 2D game and i want it to run on almost anything. The particular case in question is my mates Duron 600 with the sucky onboard gfx (which has a truly astounding 12K of free video memory).
I''m running in windowed mode, using a 640x480 window and the fps rates are all for 16 bit surfaces. I''m creating all my surfaces in system memory so theres only 1 blit to video memory once per frame when i transfer the secondary to the primary surface. I''m not reading anything from vid mem.
The background blited to the secondary surface is made of 32x32 tiles (forgot about them earlier) so i''ve got 300 Blits from sys to sys moving a total of 600K, then another 100K or so Blited before the entire surface (600K) is Blited from sys to vid mem. I make that 600*100 = 60Megs per second. Now i''m using a GeforeDDr and i''m damm sure that the bandwidth is far greater than 60 megs per second.
Unless the overhead on the Blits is way higher than i expected for some reason then i should be getting much better frame rates.
zipless
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
