Getting better 2d Frame Rate
Jason
Im starting work on a 2d graphics game using Directx7 but when it comes to
frame rates I can't seem to get anything better than 18 per second. I
thought this was strange because it doesn't matter how much stuff is being
displayed and calulated (I could have TONS of stuff going on or nothing at
all and I still get 18 frames per second)
The formula I used to calculate the frames per second is
//Current time minus the time it was the last time FPS was checked
DWORD Tick = GetTickCount() - g_FPSTick;
if(Tick < 1)Tick = 1; //dont wanna divide by zero
//divide 1000 miliseconds (1 second) by the number of miliseconds between
flips
FPS = 1000 / Tick
//Get the current time
g_FPSTick = GetTickCount();
This FPS function is called every time I flip the front and back buffers so
this should be telling me that at best I can only flip buffers 18 times per
second. The function that actually updates the screen is a Timer procedure
and the timer is set up so that it's interval is only 1 milisecond (so it
runs every chance it gets)
I know in 3d programs you can get frame rates plus 70/sec and there's 3d
rendering and a game being played so it seems to me like it's not a huge
stress on the system (espescially 2d wise) to push that 18 up but I'm not
sure.
Is there something I'm missing or am I doing something wrong or do 2d
programs just not perform nearly as well as 3d when it comes to frame rate
or what?
Jason
Nathan Mates
Jason <ozu...@home.com> wrote:
[Most of the original post snipped]
>This FPS function is called every time I flip the front and back buffers so
>this should be telling me that at best I can only flip buffers 18 times per
>second. The function that actually updates the screen is a Timer procedure
>and the timer is set up so that it's interval is only 1 milisecond (so it
>runs every chance it gets)
Don't use Windows timers for games anymore. Those are limited to
around 18 times per second, etc. With the pre-emptive multitasking
under win32 (Win95 and later), your main loop should look something
like this:
int KeepRunning=1; // Set this to 0 to exit the game if gamelogic says so
void GameMainLoop(void)
{
// Local varbs snipped.
while(KeepRunning)
{
// Process all windows messages
while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
if (msg.message == WM_QUIT)
return; // We're done.
TranslateMessage(&msg);
DispatchMessage(&msg);
}
// Functions in the rest of your code to do one frame's worth of work.
// You may have slightly different names.
BeginFrame();
UpdateEverything();
DrawEverything();
EndFrame();
}
}
This is how modern games work-- the above loop grabs as much of the
CPU as the OS allows it to get, which means the framerates will be as
high as possible.
Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Jason
This boosted my FPS to around 80
Jason
Peter James Cowderoy
> Don't use Windows timers for games anymore. Those are limited to
> around 18 times per second
Looks a little suspicious ;-)
Sorry, I left my obscure quote at home today...
Anthony Graham
the main thread when there are no window messages. Just my opinion...
- Anthony
"Nathan Mates" <nat...@visi.com> wrote in message
news:Gyzn6.1172$q7.1...@ruti.visi.com...
Oliver Gerlach
you don't want the game to run faster on faster machines. You want it to run
smoother. Otherwise the game would be unplayable on high-end machines (i
cant play Commandos, for example :-( ).
Oliver
"Nathan Mates" <nat...@visi.com> schrieb im Newsbeitrag
news:Gyzn6.1172$q7.1...@ruti.visi.com...
Nathan Mates
Anthony Graham <A.M.Graham*NOSPAMFORME*@btinternet.com> wrote:
>I prefer to create a second thread for the gameloop, and use Sleep(0); in
>the main thread when there are no window messages. Just my opinion...
While that may work (0 is a magic value to Windows, handing
execution to other threads), I think the constant task-switching can
be slightly slower than the single-threaded loop I mentioned. Unless
you're in the seconds-per-frame game speed, waiting on messages until
the end of the frame isn't a problem.
Personally, I've found that multithreaded programming has a great
potential to initially work fine, but cause all sorts of obscure and
timing-dependent bugs that are a pain to track down. I would not
recommend multithreaded programming at all to a novice programmer
until they have a good deal of education in that field. I'd be wary of
processing a WM_QUIT message while in the middle of a frame, as that
could lead to resource leaks or other fun.
Nathan Mates
Oliver Gerlach <oliver....@planet-interkom.de> wrote:
>And which function do YOU use to deterime how much time has passed?
>I mean, you don't want the game to run faster on faster
>machines. You want it to run smoother. Otherwise the game would be
>unplayable on high-end machines (i cant play Commandos, for example
>:-( ).
Wow, I thought games that go bonkers on fast machines had gone
the way of the 486, but it looks like there's still some stragglers.
Personally, I've found that GetTickCount() is usable for such
tasks. If you note the ticks when the last frame began, and ensure
that it's some small epsilon less than the current frame's, you'll
avoid divide-by-zero and other fun stuff. Waiting for vblank or
assuming that each begin/end frame combo is at least 1/60 of a second
is asking to have problems.
60fps is a tick increment of 16.667, so if you kill time so that
your tick increment between frames is at least 5 ticks, you've put a
cap of 200fps on your game, which sure seems high enough to me right
now. :)
Marcus Lindblom
"Oliver Gerlach" <oliver....@planet-interkom.de> wrote in message
news:97re1h$q619c$1...@ID-67077.news.dfncis.de...
> And which function do YOU use to deterime how much time has passed? I
mean,
> you don't want the game to run faster on faster machines. You want it to
run
> smoother. Otherwise the game would be unplayable on high-end machines (i
> cant play Commandos, for example :-( ).
> Oliver
Try GetPerformaceCounter() :)
It has plenty of resolution..
/Marcus
Marcus Lindblom
> In article <97re1h$q619c$1...@ID-67077.news.dfncis.de>,
> Wow, I thought games that go bonkers on fast machines had gone
> the way of the 486, but it looks like there's still some stragglers.
Incoming is the perfect example of this problem persisting still. :)
It's actually varying as you play, depending on wether you see only
sky (and you shoot 300 shots/second and fly fast as hell), or you
turn down to the terrain with all the tanks (everything bogs down
to slowmotion). Yuck!
/Marcus
Wei-ju Wu
your approach which you mentioned works under Win 9x, but under
NT, my input is totally blocked, if I only take the
PeekMessage() and without synchronizing with timeGetTime() !!!
Do you have a solution for that ?
I poll for the input states with DInput 3 and render everything in OpenGL
Thanx, Wei-ju
Nathan Mates
Wei-ju Wu <Wei-...@joyful-noise.de> wrote:
>your approach which you mentioned works under Win 9x, but under
>NT, my input is totally blocked, if I only take the
>PeekMessage() and without synchronizing with timeGetTime() !!!
Sorry, I can't quite say I've heard of your problem. That
PeekMessage() per frame loop I quoted earlier in this thread is
exactly what Battlezone 2 and Dark Reign 2 do, and they both read
input successfully under 9x/ME/Win2000. Many other games do the
same thing; this is hardly a unique setup.
>Do you have a solution for that ?
>I poll for the input states with DInput 3 and render everything in OpenGL
You may want to look at the Quake 1 sources, as that's an OpenGL
game. I can't say for certain how it does things (or if it uses
DInput), but I'm pretty sure it's got something similar to what's been
posted already.
Oliver Gerlach
> In article <97re1h$q619c$1...@ID-67077.news.dfncis.de>,
> Oliver Gerlach <oliver....@planet-interkom.de> wrote:
> >And which function do YOU use to deterime how much time has passed?
> >I mean, you don't want the game to run faster on faster
> >machines. You want it to run smoother. Otherwise the game would be
> >unplayable on high-end machines (i cant play Commandos, for example
> >:-( ).
>
> Wow, I thought games that go bonkers on fast machines had gone
> the way of the 486, but it looks like there's still some stragglers.
>
> Personally, I've found that GetTickCount() is usable for such
> tasks. If you note the ticks when the last frame began, and ensure
> that it's some small epsilon less than the current frame's, you'll
> avoid divide-by-zero and other fun stuff. Waiting for vblank or
> assuming that each begin/end frame combo is at least 1/60 of a second
> is asking to have problems.
>
> 60fps is a tick increment of 16.667, so if you kill time so that
> your tick increment between frames is at least 5 ticks, you've put a
> cap of 200fps on your game, which sure seems high enough to me right
> now. :)
>
This is how I do it, too. I just wanted to now what to do without
GetTickCount(). But Marcus has mentioned a good alternative.
Oliver
Gerry Quinn
>
>"Nathan Mates" <nat...@visi.com> schrieb im Newsbeitrag
>news:Zseo6.35$y6.2...@ruti.visi.com...
>> In article <97re1h$q619c$1...@ID-67077.news.dfncis.de>,
>> Oliver Gerlach <oliver....@planet-interkom.de> wrote:
>> >And which function do YOU use to deterime how much time has passed?
>> >I mean, you don't want the game to run faster on faster
>> >machines. You want it to run smoother. Otherwise the game would be
>> >unplayable on high-end machines (i cant play Commandos, for example
>> >:-( ).
>>
>> Wow, I thought games that go bonkers on fast machines had gone
>> the way of the 486, but it looks like there's still some stragglers.
>>
>I thought the same before playing Commandos.
>
Or Magic the Gathering *and* its sequel by MicroProse - an excellent
game utterly ruined by this.
Gerry Quinn
--
http://bindweed.com
Puzzles, Strategy Games, Kaleidoscope Screensaver
Download evaluation versions free - no time limits
New puzzle challenge: "Dragon Scales"
Peter James Cowderoy
Nathan Mates wrote:
>
> In article <97re1h$q619c$1...@ID-67077.news.dfncis.de>,
> Oliver Gerlach <oliver....@planet-interkom.de> wrote:
> >And which function do YOU use to deterime how much time has passed?
> >I mean, you don't want the game to run faster on faster
> >machines. You want it to run smoother. Otherwise the game would be
> >unplayable on high-end machines (i cant play Commandos, for example
> >:-( ).
>
> Wow, I thought games that go bonkers on fast machines had gone
> the way of the 486, but it looks like there's still some stragglers.
>
Damn, time to see how far I can underclock this t-bird then...