Jump to content

  • Log In with Google      Sign In   
  • Create Account


DirectX and Frame Rate


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 Fnjord   Members   -  Reputation: 122

Like
Likes
Like

Posted 24 January 2000 - 05:06 AM

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

Sponsor:

#2 Bracket   Members   -  Reputation: 240

Like
Likes
Like

Posted 24 January 2000 - 05:26 AM

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.

#3 mason   Members   -  Reputation: 128

Like
Likes
Like

Posted 24 January 2000 - 07:17 AM

you could also probably get rid of that backbuffer color fill. no reason to fill with black if you''re just going to immediately put tiles on top.

Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com

#4 Fnjord   Members   -  Reputation: 122

Like
Likes
Like

Posted 24 January 2000 - 02:10 PM

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.

-Fnj

#5 alexmoura   GDNet+   -  Reputation: 450

Like
Likes
Like

Posted 26 January 2000 - 02:51 AM

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.

#6 Int86x   Members   -  Reputation: 122

Like
Likes
Like

Posted 26 January 2000 - 12:46 PM

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.


#7 Bigshot   Members   -  Reputation: 122

Like
Likes
Like

Posted 26 January 2000 - 12:49 PM

What does that do to speed up DirectX a ton?

Just wonderin,
Al

#8 mason   Members   -  Reputation: 128

Like
Likes
Like

Posted 26 January 2000 - 01:00 PM

I hope Int86x was joking.

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.

A completely crazy way to solve the problem.

Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com

Edited by - mason on 1/26/00 7:01:35 PM

#9 bstach   Members   -  Reputation: 122

Like
Likes
Like

Posted 26 January 2000 - 01:29 PM

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!


#10 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 26 January 2000 - 02:26 PM

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

#11 Fnjord   Members   -  Reputation: 122

Like
Likes
Like

Posted 27 January 2000 - 01:23 PM

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

#12 LordFoul   Members   -  Reputation: 122

Like
Likes
Like

Posted 27 January 2000 - 10:17 PM


Try creating an offscreen surface to hold the displayed
14x16 tiles. Draw your tiles into this surface and then
bltfast the whole thing into your frame buffer.

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






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS