Jump to content

  • Log In with Google      Sign In   
  • Create Account


Elyas_321

Member Since 30 May 2011
Offline Last Active Sep 13 2011 05:52 AM
-----

Posts I've Made

In Topic: How does a game loop work?

09 September 2011 - 01:45 PM

if(timeElapsed > 16)
draw()

That is limiting the draw rate isn't it? But what you want is to draw as fast as possible....
You are right it may jump....that's one of the drawbacks..but I can't even get it working..well I can but there is something I don't understand about it..

From what I was told and understand

I calculate elapsedTime after update and draw...

But the thing is initially when I pass the timeDelta the elapsedTime would be 0.0f which is wrong

So I am confused... I am reading that dewitters page again, to see if I can understand it.

And btw, as a fellow beginner I am impressed how quickly you've grasped it :)

In Topic: How does a game loop work?

09 September 2011 - 01:21 PM

It got too long so I will continue from here...

	while(true)
        {
 		start_time = clock() ;
		
           	player->update(timeDelta)
		player->draw(backBuffer) ;
		end_time = clock() ;

		elapsedTime = end_time - start_time 



So, to calculate how much time elapsed for the next frame..the timeDelta will be position = velocity * timeDelta

where timeDelta = elapsedTime/16 * 100.

So If the duration was 10ms instead of 16ms
it would be 10/16 * 100 ..62.5 instead of the original 100px.
if the elapsed time was 16ms
then 16/16 * 100...exactly 100 units...But there is a bug in the code..which I am trying to solve

In Topic: How does a game loop work?

09 September 2011 - 01:16 PM

(Wish I was more used with english, my brain gets a little confused trying to read and explain some things in english)

But if startTime = 160ms, endTime = 170ms
then elapsedTime = 10ms!

The update and draw finished quickly, and if there was no code to say sleep(6ms) the next draw will be called, and it will be fast!



No, because what you will define a minimum time step in the beginning, and if the process if too fast, you will your time counter is AT LEAST higher than that minimum time step before drawing the next frame. So it will never be too fast. And if it goes too slow, you might have a problem in your logic that should be improved, or you will have todivide your update in multiple steps (think about this later, first try to implement these fixed time steps based on the actual elapsed time)

I will give you a real example. In my game, I usually have 60 fps. But I dont have enough animation frames on my sprites to change them 60 times a second! So what do I do then?

Well, its simple.

use the same example given above.


float updateTime = 100f;

float animationTimer = 0f;

void Update()
{
	animationTimer += TimeElapsed();

	if(animationTimer >= updateTime)
	{
		Animate();
	}
}



This will never be too fast. Its pretty simple actually, just clear your thoughts, and go over it from the beginning, because it seems like you already have your mind set into a way you think things are supposed to work (like defining how much time things are going to take, instead of defining WHEN are YOU going to do something) and thats confusing you a bit.



No problem, I also find it hard to understand people's explanation, and I know English lol.
But I don't understand why you say it is wrong... Using a fixed fps of 60fps so the frame may draw at 16ms

But it could happen that the frame finished updating the logic and drawing at just 4ms.
which means the remaining time of the time slice is 12ms...
So I start to update the next logic and then draw ahead of time....Which is fast? It makes sense to me.. but I don't know why you say it is wrong :(
Since we want each frame to have a duration of 16ms the way I can control it is to spend the remaining 12ms doing something else, and when it is up continuing update and draw...
So the update or game speed is dependent on the fps.
I thought I was making progress :(

But this is highly efficient because I am limiting at a constant fps and I have to use sleep, better to use a dynamic fps....which I am having a bit of trouble understand. You are right..

I need to clear my head and think about it.

To calculate the amount of frames to move..let me imagine a scenario where every 16ms I move the position by 100px

So, position+=100 ;

So I am moving 100px/16ms... I believe that is 6000px per second? Using sleep.

But to get rid of it, I will have to calculate the elapsed time between update() and draw().








In Topic: How does a game loop work?

09 September 2011 - 11:00 AM

Guys, I believe I understand...sorry for being so slow..

When we say a the game runs 60fps, it means we must draw the frame 60 times in a second. So a frame drawn to the screen - this is the part I didn't fully get - has a time slice of 16ms... In other words a frame must be drawn in the time allocated which is 16ms, right?

But the problem is maybe the update and draw takes too long so the the greedy frame uses more than 16ms..


So:
StartTime = 160ms, endTime = 200ms,
duration of update and draw is elapsedTime = 40ms. But a frame should have taken 16ms
So it was 24ms overtime, which means there is now a lag yeah?
And that sucks..big time....the only thing I may do is allocate a bigger frame rate, so that each frame may have sufficient time to finish update and drawing without stealing precious time from the next frame draw.

But if
startTime = 160ms, endTime = 170ms
then elapsedTime = 10ms!
The update and draw finished quickly, and if there was no code to say sleep(6ms) the next draw will be called, and it will be fast!

The best thing then is to use a variable time step.

We calculate the elapsed time the draw and update takes and use that as our speed.
so if it took more time:
10/16 * 2px that is elapsedTime/frameDuration * velocity will give me the amount of units I should move the player by instead of using the speed of 2px.

I think that is pretty much the idea of timing the game loop. My brain is still trying to cope with the concept, but I believe I am getting there!
Please correct me if I am wrong.

In Topic: How does a game loop work?

09 September 2011 - 04:31 AM

Hello again,
I decided that the only way to understand this timing stuff..it is to try and do a simple timing implementation myself, and try to understand it. I can't grasp the logic just by reading the examples :(

So this is what I have, and I need help understanding what is happening even if I wrote it



		float startTimer = 0.0f ; 
		float frameTimer = 1.0f/60 ;// 60 frames per second.


		while(gamerunning()) 
                {
			while(startTimer < 1000)
			{

				player->update() ;
				startTimer+=frameTimer  ; // so for every 0.016ms update the game logic....
			}
         		startTimer = 0.0f ;		
			player->draw(backBuffer) ; //draw the new endpoint?
       		}
       		

I recognize that even though I did startTimer < 1000, it doesn't necessarily mean that the update logic ran for 1 sec. It might run exactly second, on a higher processor finish in the 0.5secs ,or take 2 seconds on a slow processor. But in theory and for my sake, let's assume it did run for 1sec.
When I ran it, it actually drew reasonably well...I thought it was going to be choppy, since I was calling update 60 times and drawing once. I don't know why it drew reasonably well.
if the initial position X is at 0 and I kept pressing right..until the loop ended, it didn't end up at the other end of the screen or outside the screen window..can someone please explain why?

PARTNERS