Do you use DirectDraw''s Blit command? If so, try and make sure that the more commonly used surfaces are in VRAM - OR that the backbuffer and your surfaces are in system ram. VRAM->VRAM is fast, System RAM->Sytem RAM is fast, System Ram -> VRAM is slow.

I don''t think you can create the backbuffer in system memory, if you really want to work on system memory you have to create a surface (on system memory) with the size of your screen, build the tiles on that surface, blt the surface onto the backbuffer and then flip.
But I think it''s faster (not only from the memory, but because you also save one blt) to try to work only in vidmem. Only if you need to some fiddling around with the buffers (alpha channels in software come to mind) should you work in sys mem.

Ok, when loading the bitmaps, do it in video memory. if the call to create the surface fails, then do it in system memory.

That way you put as much in video memory as possible.


Also, remember to use bit shifting when possible. Optimize your code.

And lastly to speed it up "A TON", insert these lines after you have initialized all the directdraw crap:

HANDLE hProc=GetCurrentProcess();
SetPriorityClass(hProc,REALTIME_PRIORITY_CLASS);

That will speed it up a ton and smooth it completely.

I have to agree with Mason.

Boosting the priority level that high is a sure way to bring your system down in a spectacular flaming blue screen. (you also run the risk of corupting data on your HD)Boosting priority levels is not a bad idea for short time critical tasks once in a while, but not that high. REALTIME_PRIORITY_CLASS is normaly only used by device drivers, and low level code inside the OS that handles thing like IRQ handlers.

You can temporarily increase the priority class of your application (for a very short period) to HIGH_PRIORITY_CLASS to draw a new frame, and then switch it back to NORMAL_PRIORITY_CLASS after you have completed the frame update. But, again, you cannot take a lot of time to complete the frame update or you run the risk of preempting important OS functions.

It is best to get your speed up to an acceptable level with out boosting the priority class.

YOU HAVE BEEN WARNED!

Int86x was just a little bit off there. First, you do this:

HANDLE hProc=GetCurrentProcess( );
SetPriorityClass( hProc, REALTIME_PRIORITY_CLASS );

then you do this

SetThreadPriority( GetCurrentThread( ), THREAD_PRIORITY_TIME_CRITICAL );

This makes Windows stop paying attention to even input events, and therefore it doesn''t even move the mouse on your behalf. Hella fun if you''re using DirectInput, though. By the way, I was just being stupid there. I compeletely disagree with Int86x on this, and hope he was joking. Don''t mess with Windows like this. The most it''s going to do is screw things up, and you can only squeeze about 5 extra fps (in NT at least) using this method. The best thing to do when framerates drop is to make sure that you''re not doing something wrong, that you''re not calling Lock() very often and when you do, not leaving it locked for long, and do standard optimizations (decrease dereferencing, use shifts and bitwise operations, etc.) Also, remember that if you fill your screen, you don''t need to clear it before drawing (and I hope you can fill your screen in a game), and think about your color depth. If you''re running in 32 bit mode, and all you really need is 16, go for it. You''ll end up transferring half as much data across the bus, and you can fit more in video memory. One final tidbit - make sure that you''re not using transparency when you don''t need to. If you''re putting the ground tile down, just put it down with BltFast and no transparency and such. If you''re putting down a tree or something that does need transparency, also use BltFast. BltFast apparently can have a 10% increase in speed, plus you technically can''t stretch (stretching=slow) the bitmap.

Andy

PS If you really want to see some fun, try the top of this post in Win9x. My app jumped from 100fps to over 250fps with those two lines. Yeah, my system was hosed and I basically had to pull the old fashioned reset (CTRL+ALT+DELETE became disabled at this point), but boy was I hummin''!