Author Topic: getting current fps?  (Read 1357 times)

guess what you have to do in order to render?

That's right, process. Contradiction found.
Processing is done on a seperate loop and values from the processing are referenced by the render loop to get the data from the processing loop. That's not a contradiction, you seem to not understand how variables work at all.

Processing is done on a seperate loop and values from the processing are referenced by the render loop to get the data from the processing loop.

Torque does not use multiple main loops in separate threads.

Torque does not use multiple main loops in separate threads.
It does. Writing a game engine where the speed the engine itself runs is directly reliant on how many frames per second are processed by the GPU is probably one of the worst things you can possibly do, not even GameMaker links the two.

It does. Writing a game engine where the speed the engine itself runs is directly reliant on how many frames per second are processed by the GPU is probably one of the worst things you can possibly do, not even GameMaker links the two.
Rendering has nothing to do with script execution. If the engine ran at the framerate done by the GPU, then people with good computers' games would actually run faster, as if they changed the timescale.

Rendering has nothing to do with script execution. If the engine ran at the framerate done by the GPU, then people with good computers' games would actually run faster, as if they changed the timescale.
So.. you pretty much just proved the point I was making.

So.. you pretty much just proved the point I was making.
no, i'm saying nobody smart enough to make a game would make that mistake.
I'm also saying that having two loops makes no sense, why would frame rendering even need a loop anyway?

no, i'm saying nobody smart enough to make a game would make that mistake.
And that's literally exactly what I said in the post you quoted.
I'm also saying that having two loops makes no sense, why would frame rendering even need a loop anyway?
Because if the frame rendering was in the same loop as the code execution, the loop would be slowed down by the rendering calculations and that would do what we pointed out is stupid.

then people with good computers' games would actually run faster, as if they changed the timescale.

I don't even know of a game that doesn't measure the mspf and factor that into calculations for things such as physics, animations, etc.


guess what you have to do in order to render?

That's right, process. Contradiction found.
Oh look, Ipquarx talking about stuff he doesn't have a clue about again. Any good game engines separate logic from rendering. They do not depend on each other.
no, i'm saying nobody smart enough to make a game would make that mistake.
I'm also saying that having two loops makes no sense, why would frame rendering even need a loop anyway?
Kind of hilarious that you're talking about "smart game devs" when you actually don't understand game development at all. Rendering is a very expensive process. You don't seem to understand the concept of concurrent programming.
I don't even know of a game that doesn't measure the mspf and factor that into calculations for things such as physics, animations, etc.
You realise that the concept of stepping by delta isn't exclusive to rendering right? Having the logic on a separate thread does the exact same thing, except it uses the time delta between ticks.
« Last Edit: October 27, 2012, 03:06:06 AM by Destiny/Zack0Wack0 »

You realise that the concept of stepping by delta isn't exclusive to rendering right? Having the logic on a separate thread does the exact same thing, except it uses the time delta between ticks.

When did I claim that "the concept of stepping by delta isn't exclusive to rendering"?

When did I claim that "the concept of stepping by delta isn't exclusive to rendering"?
You didn't, that's why I asked you.