Archived

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

BlueFrog

The memory monster

Recommended Posts

Can anyone direct me to some serious documentation on the whole screen buffer and blitting saga.(or if you wanna help here, thanks). Here''s what I mean.(using SDL) I setup a screen buffer of 640x480x16 using the video memory, double buffer flags....I then set up a simple particle engine to simulate snowfall(as well as a bitmap background) and sit back, this produces a framerate of ~39...when I up the bpp to 24 bits, the framerate goes to about 50~FPS, and finally when I drop the resolution to 320x200, FPS shoots up to ~150, which is pointless, as with my current 1600x1200x24 OS resolution, I get 75Hz refresh or something around there. Anyway, when I use the hardware acceleration flag, no difference. Are these FPS bad or good(specs below), and what are the right ways to allocate memory, I know you can write to VRAM fast, but read slow or something like that...is all 2D graphics stuff done this way, or not....I know if all you gonna do is pixel manipultions...guys tend to allocate the screen buffer in system RAM, and use locks to directly manipulate the pixel info, then call a simple update function, since system RAM is fast....see this is why I need it spelt out, so I know once and for all....I mean how does quake get such high FPS at such high resolutions, etc, etc. Athlon 1.3Ghz DDR, 256 meg RAM DDR, NVidia Geforce 2 64 meg VRAM DDR Thanks for your input guys...I''ve been hacking up so much test code to try ease my mind, and just need some pro help.

Share this post


Link to post
Share on other sites
Maybe I should mention how I''m measuring FPS...

SDL allows you to call a function SDL_GetTicks, which returns the amount of milliseconds that have elapsed since SDL was initialised....so, after a frame is drawn, I check how much time has elapsed and subtract the last frames value from it..and then set a temp value to the new value.

so if last frame was drawn 10 msecs after SDL was initialised and this frame was drawn 20 msecs after, then for one frame to get created(full cycle) took 10 msecs, which means at that rate, I could produce 100 unique frames every second....if you add this to a pool and keep a counter, you can then average all frame rate calculations over the duration of the test.

Of course this makes the first frame report an incorrect value as the first frame gets created 10 milliseconds into the apps life and has nothing to subtract from it, but it''s only one sample.

Share this post


Link to post
Share on other sites