Thanks for replying. Hmmm. Maybe since this issue has moved
from hypothetical to actual it should be moved to the game board.
I tried both of those, but neither of them seemed to work well.
Originally Posted by Bubba
I can't remember my exact reasoning for going with my current
method because it was so long ago, though.
Here's my entire clock class:
static cl_Clock& Global();
unsigned int Counter;
cl_Clock::cl_Clock(): TicksSinceSystemStart(0), TicksPerSecond(0), CurrentTime(0.0f), PreviousTime(0.0f), DeltaTime(0.0f)
cl_Log::Global().Error("High Resolution Timer not supported");
I call cl_Clock::Update() at the beginning of the main game loop and base
PreviousTime = CurrentTime;
//get time ("ticks") since system start
//convert to seconds
CurrentTime = ((double)TicksSinceSystemStart / (double)TicksPerSecond);
DeltaTime = (CurrentTime - PreviousTime);
all the movement and such off of DeltaTime.
On my Radeon 9800Pro, my framerate is about 1600 and everything runs
Summary of issues:
* The main character can walk off the screen and cannot come back
* The window can lose focus and will lose the title bar thus making it impossible to close. Trap for the set focus message or the message windows sends when a window is about to lose focus. If you are using DirectInput this will require you to unacquire() the mouse and then reacquire it.
* The window update function is not updating correctly for all frames. First 3 or 4 iterations work fine and then it starts skipping around. Seems like a timer issue.
* Input lags behind render due to the timing issue - input is accepted but render skips so both seem to lag.
* Pressing CTRL ALT DEL to bring up task manager, sticks your game inside the task manager window b/c the window loses focus and thus loses title bars and turns into a mess.
fine. In fact, if I don't draw the background each frame, the fps can get to
over 3000 (and stays relatively consistant) and still no problems timing wise,
no input problems either. Still runs silky smooth.
The only problem that does happen is that, see.. I draw the entire background
each frame and draw the other stuff over that. Everytime I draw the background,
the previous frame is effectively erased. When I don't draw the background,
I get just a bunch of images drawn over each other. But that's expected.
I don't experience any of those issues. And the other people who I've
asked to test it with ATI cards don't, either. But my friend with his Geforce
6800GT, Gametaku with his Geforce 7800something both experience them.
Jawib tried it on both an ATI card and an nVidia Quadsomething. He had
the problems on the nVidia card but said it worked on his ATI.
If you hit "E", the framerate will lock to about 60fps. But I just did that with
Sleep() to make sure physics things would happen independent of the framerate.
I wanted the blood to fall at the same speed whatever the framerate was.
As far as input goes, I'm only using WM_KEYUP / WM_KEYDOWN messages
to set a state in a cl_Keyboard class. I'm not using DInput or anything. And
I don't experience any problems.
while(PeekMessage(&Message, Handle, 0, 0, PM_REMOVE))
if(Message.message == WM_KEYDOWN)
if(Message.message == WM_KEYUP)
Oh, yes. I did do the artwork. I'd love to be a part of things, but my
If you made the artwork then congrats because it is very good and I'd like to use your talents for a game we are working on
digital graphics experience is limited to MSPaint. I bought a book on
Maya a few months ago. Haven't had a chance to read it. And the newest
version of Corel Painter *is* on my Amazon wish list along with a Wacom