Alright, this has probably been addressed before, but I like the feel of asking my own questions-
I am writing an overhead tile game (for fun- so I can learn the interfaces) for DirectX and I just managed to start displaying my background map tiles, yet In displaying the 14x16 array of 32x32 bitmaps my framerate suddenly descends to 7-10 refreshes/second. Is there something I can do to speed this up? My map is stored as a vector of vector of tiles, each of which keep a pointer to a direct Draw surface and the co-ordinates of thier cell... Nothing else is being called in the program, other than a blakc colorfill for the back buffer, this tile fill for the back buffer and a flip routine.
any help would be appreciated
-Fnj
---
Incompetence is a double edged banana
---

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.

thank''s all- I am using DirectX''s provided blit and all the surfaces are in video memory, I''m not sure how I could put the back buffer in system memory since I created it as a complex with the front buffer on the video card... neway I''ll be going back fiddling with it.

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.

Those two lines make your app execute in real-time, basically at a higher priority than other apps. This is a completely crazy thing to do, since it means that your game is now on the same level as system-critical things like disk caching, network routing, and even the system GUI.

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.

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''!

woo! windows calls to crash my machine, I gotta try that out- alright to update again, I am using all of teh screen so I got rid of the color fill, but still I get 7 frames per second, I think optimization is what I need, but I''m drawing tiles from an array so how could I access my data members without a lot of dereferencing? I probably need to include some source code to make this make sense, but I don''t want to take up too much space in teh discussion- essentially- I have a vector of vectors of my class of tiles. I pass a pointer to this array to my display tile function and it goes through and blits each one to the back buffer. I''m thinking about jsut having a huge offscreen surface(my current *read: bad* idea) that it initialized with the array of tiles and then the display coudl jsut take 640x480 chunks out of it each blit- any further thoughts?-Fnj

Try creating an offscreen surface to hold the displayed14x16 tiles. Draw your tiles into this surface and thenbltfast the whole thing into your frame buffer.

If you keep an additional 14x16 matrix that tracks whichtile is drawn in each cell of the offscreen surface, youdo a quick comparison and see if you need to redraw eachtile on each subsequent pass through the map drawing.