driver->getFPS() update intervall

[binford]

I'd like to make the movement of my camera independent of the frame rate. I have a speed constant and divide it by the frame rate using driver->getFPS(). The problem is that getFPS() seems to calculate the frame rate only every second or so. Thus the camera speed varies if you have just moved from a low poly area to a high poly area (or vice versa).

Is ther a way to speed up the fps calculation or do I just have to code my own FPS counter?

[zeno60]

Yeah, getFPS only updates the framerate every second, probably why they call it "frames per second." You could use this function found in most calcFPS tutorials:

Code: Select all

float timeElapsed = 0.0f;
float FPS = 0.0f;
int frameCount = 0;

void CalcFPS(float timeDelta)
{
     frameCount++;
     timeElapsed += timeDelta;
     
     //1.0f will equal one second, so if you need it updated every
     // half a second, set it to 0.5f every tenth of a second, 0.1f etc.
     if(timeElapsed >= 1.0f)
     {
          FPS = (float)frameCount / timeElapsed;
          
          timeElapsed = 0.0f;
          frameCount = 0;
     }
}

Code: Select all

float lastTime = 0.0f;

while(device->run())
{
     driver->beginScene();

     float currTime  = (float)device->getTimer()->getTime();
     float timeDelta = (currTime - lastTime)*0.001f;
     CalcFPS(timeDelta);

     driver->endScene();
     lastTime = (float)device->getTimer()->getTime();
}

Then use FPS in place of driver->getFPS();

Had to cut and paste from my own messy code, hopefully I haven't missed any of it, but it should do the trick if you change it to update the fps every millisecond or whenever you need. Good luck.

[JP]

Or you could just do the movement based on the time elapsed since the last frame and leave the FPS out of it completely. So the amount to move the camera would be distance = speed * elapsed time.

[binford]

thx for the code, zeno60. btw, you could use

Code: Select all

FPS =  static_cast<float>(frameCount)  / timeElapsed;

instead of C-style casting. Not realy important but makes it more C++-ish.

[vitek]

I realize that you are trying to make your node speed 'frame-rate independent', but don't use the FPS to help determine the distance to move your node. You just use the elapsed time since the last frame was rendered...

Code: Select all

irr::ITimer* realTimer = device->getTimer();
u32 t0 = realTimer->getRealTime();

f32 velocity = 5.f; // or whatever

while (device->run())
{
  u32 t1 = realTimer->getRealTime();
  f32 elapsed = (t1 - t0) / 1000.f;
  t0 = t1;

  // now calculate distance. this is frame-rate independent
  f32 distance = velocity * elapsed;

  //...
}

Note: The original code I posted wasn't perfect. I forgot to update t0 in the loop. I've fixed that.

[wREAKAILDRON]

i used this formula, and i cant seem to apply it to the integer X Y and Z members of a core::vector3df. How do i apply this formula to a vector3df if the movement is smaller then 1?

My character just move in either the x or z directions, and i cant seem to get any movement out of the formula, and im guessing its because the amount turns out to be smaller then 1; which is the velocity that my character moves at. When i plug in the variable distance into my either X or Z direction, my guy doesnt go anywhere, and im guessing its because the velocity of my guy is 1. and when you plug less then 1 into an integer, you get 0 i thought.

The way i did the movement, is to calsulate where my guy will be placed by the applied velocity, and then i set him in that position; post velocity calculation.

am i going to have to limit my frame rates, or is there a way to get a number less then 1 to fit into the x y or z integer members of a vector3df?
________
Gm 54-Degree V6 Engine

[rogerborg]

i used this formula, and i cant seem to apply it to the integer X Y and Z members of a core::vector3df.

Are you really using a vector3df, or is it a vector3di?

[wREAKAILDRON]

i was using vector3df.

i tried to make a function out of vitek's formula, and i think i should have used jp's idea in the first place. Id get the time the frame took with aid of the timer, and divide the movement by the percentage of a second that the frame took.
________
LIST OF FACTORIES

[vitek]

Uh, JP and I are telling you to do exactly the same thing. It just so happens to be exactly the same thing that you are trying to describe.

You use the system timer to calculate the elapsed time [f32 elapsed = (t1 - t0) / 1000.f]. Then you use the elapsed time to calculate the distance travelled [f32 distance = velocity * elapsed].

Travis

[wREAKAILDRON]

I program with the macintosh this time around.
Are you telling me to use the macintosh timer(system timer) or the Irrlicht timer?

I dont think im using the output of the ITimer well. It accumulates seconds at a non steady rate. I know myITimer->getRealTime() spits out a u32. what is the format of the u32 output?
what format does u32 -myITimer>getTime() spit out? I used myITimer->start() before the while(device->run()), did i have to? do i have to use myITimer->tick() on each frame?
________
MARIJUANA BUBBLER

[vitek]

Are you telling me to use the macintosh timer(system timer) or the Irrlicht timer?

I don't really care. It is probably easiest if you use the cross-platform method that is provided [the Irrlicht timer].

It accumulates seconds at a non steady rate.

The time returned by getTime() should be the current time of the simulation in milliseconds. If one render takes 100 milliseconds, and another takes 123, the will appear to change sporadically. It will not increase in a perfectly linear fashion. That is expected.

I know myITimer->getRealTime() spits out a u32. what is the format of the u32 output?

It is the number of milliseconds since the system was started. It's covered in the docs.

You probably only need to use getTime(), but it really depends on your application. You don't need to call tick() unless you don't call device->run() for some reason. You don't need to call start()/stop() unless you need to start and stop the system timer.


Travis

[wREAKAILDRON]

this is the ONLY THING that is caising me a production pause in the GREAT IRRLICHT engine. ANY PROGRAMMER should take notice of the WONDERS of the EASY TO USE irrlicht engine. EVERTHING ABOUT THE IRRLICHT ENGINE IS GREAT AND FAST.

mabey im just SPOILED because the irrlicht engine is so EASY AND GREAT to USE. The timer function, im only on day two of getting it working. Im realy sorry that im bringing attention to this two day scant through the timer function. the irrlicht engine get you thinking that youll understand EVERYTHING about it from the get go, so im sorry im complaining about only two days of meandering through mis understanding a function. all the other functions that seemed to take me longer with other engines, like the rotation and loading and collision functions, well theyre a BREEZE to understand. god the irrlicht engine is GREAT.

mabey i could go on to complain about how the ogre engine takes a genius just to compile it, and when you get around to understanding the classes, you have to reprogram them just to get the base classes that you wanted in the first place. and that i dont appreciate a gigbyte of ogre classes, when i think i only need five classes to make a game with.

Ive only spent about two weeks on programming with the irrlicht engine, and i already have enemies, land, a hero, and im almost doing my 3d kick and punch combo fighting already! this is beautiful! the graphics are taking me 4 tgimes longer to come up with then the programming!

i dont think ill ever stray from the irrlicht engine, becaus it provides you with powerful functions that do the work for you, where other engines make you use up to 5 to 10 functions, just to get your character to show up on the screen, and move it.

and if youve done collision detection before yourself, youll see that the irrlicht engine has done all your past work for you aswell. another wonderful bonus of the irrlicht engine suite.

if someone is going to spend their time getting frustrated at the irrlicht engine, they may need to ask themselves if thier too dumb to program video games in the first place. theres other engines far more over thought that you could spend your time getting mad at. and if they ever return to the irrlicht engine, mabey they could give that some concideration.

ive used LOADS of three d engines.

some engines that i feel are too complicated:
ogre.
powerrender.
nebula.
blits basic(you cant use classes at all, real heavy drag).
i forgot what else ive gone through over the years

thsi may be my last post, so i thought id include this summary of why ive found the irrlicht engine to be so great.
________
HOTELS IN MEXICO