Mac VS. PC

[davedes]

@kappa

@Gjallar

Now after looking for a way to cap the FPS in libGDX all I find is this (libGDX wiki):

//Good advice right at start: You should never code anything dependent on the framerate! Instead it is a good idea to make it depend on the time e.g. one of these:

 System.currentTimeMillis();
 System.nanoTime();
 Gdx.graphics.getDeltaTime();

I guess there’s no “setTargetFramerate();” … I already miss Slick2D’s simplicity

Also do have a look at LWJGL’s Display.sync(int fps) method (needs to be called every frame). Not sure if LibGDX exposes this through its API.

LibGDX’s LWJGL (desktop) backend uses Display.sync, but only if the following condition is met:

graphics.vsync && graphics.config.useCPUSynch

(Should be noted that it will use Display.sync by default, as both of those are initialized to true)

IMO Slick’s usage was more reasonable: You set a target frame rate which will be used by Display.sync, and then you can independently enable/disable hardware vsync with setVSync(boolean).

Currently, LibGDX’s unusual implementation could lead to bugs with Display.setVSyncEnabled never being reset.

[MacOLauncher]

Wow! Thanks for all the replies! ;D Really appreciate it!!! The only problem is most of this stuff passes straight over my head! But I’ll keep at it and find a solution!

So what I’ve learned from ya’ll:

1. [quote]The mac is giving a better performance then your windows.
   [/quote]

2. I could either use Delta or Fixed Rate.

3. princec(Cas) makes [quote]hundreds of thousands of dollars! xD
   [/quote]

4. [quote]Delta - complex (just try doing collision detection properly, go on), mercy of floating point, jerky movement. Absolutely horrible for 2D, in any form.
   Fixed rate - easy, can use integers all over the place, glassy smooth movement, perfect for 2D.
   [/quote]

5. [quote]The basic idea is to link your game to real time, not computer execution speed.
   [/quote]
   Thanks very much for all your help
   P.S. Any Code examples on how to actually do this would come in handy xD

• Mac

[Gjallar]

Now that I changed the Target FPS to 100 it seems to be smooth.

Any ideas why it’s smooth with 100 but not with 60 FPS?

@MacOLauncher

Thanks very much for all your help
P.S. Any Code examples on how to actually do this would come in handy xD

If you are using libGDX, the sample I posted seems to work now (with 100FPS though).

[theagentd]

Why not to use delta:

sEVSVGbj3uE

[ra4king]

Well screw all you guys. I’m sticking with delta. I can wrap my head around it and it loves me very much <3

[princec]

Fine, we shall both sit atop our huge mounds of cash from making games, and throw projectiles at each other. Though due to latency and random timing errors your projectiles will somehow warp right through me, and mine will knock you off 8)

Cas

[ra4king]

@princec

Fine, we shall both sit atop our huge mounds of cash from making games, and throw projectiles at each other. Though due to latency and random timing errors your projectiles will somehow warp right through me, and mine will knock you off 8)

Cas

Nuh uh! Not if my super awesome coding skills make my code absolutely perfect with almost non-existent timing errors that are corrected eventually! Mwahahahahahaha throws project at Cas

[Cero]

@ra4king

Well screw all you guys. I’m sticking with delta. I can wrap my head around it and it loves me very much <3

Just wait until you actually distribute something and people right and left say “well jitters for me !”

[ReBirth]

I still hope either Nate or badlogicgame come and explain libgdx’s.

[StumpyStrust]

hmmm… every where I went people said, “use delta as it keeps game steady,” and “only the best game loops use delta fixed rate sucks B.” So I started using delta (not bad, kinda cumbersome) and now its, “for the love of god do not use delta” Idk who to believe anymore.

Should I interpolate in the render? update? neither? I have to say that in meh game Neobat it is fixed rate and the collisions were shit as if anything moved even slightly to fast it would jump past an object. I really want to stop working on my current game as it uses delta but I really don’t want to use if it it will cause huge issues.

[delt0r]

Turning off delta is sort of easy to do.

[edit to fix typo]

[deathpat]

I’m using delta timing for Daedalus, and so far I had no issues reported … ( I cross my fingers )

[kappa]

Delta time is used in many commercial games, so not really fair to imply you’ll only make money when not using it

In fact in some use cases using delta time is more simple and flexible than a fixed rate.

Also the problem of large delta’s (e.g. collision detection failures due to sudden large movements) can easily be fixed by simply capping delta values.

Both approaches have their pro’s and con’s.

[princec]

Daedelus is sort of a special case, being essentially Quake3 but top-down. I bet it’s a lot more complicated than the thing we’re working on

Anyway - anyone who says delta will smooth your game out is utterly, utterly wrong. The brain’s perception of delta timing is that it does exactly the opposite.

Cas

[Roquen]

@ra4king

@princec

Fine, we shall both sit atop our huge mounds of cash from making games, and throw projectiles at each other. Though due to latency and random timing errors your projectiles will somehow warp right through me, and mine will knock you off 8)

Cas

Nuh uh! Not if my super awesome coding skills make my code absolutely perfect with almost non-existent timing errors that are corrected eventually! Mwahahahahahaha throws project at Cas

Then the reality of numeric integration & changing motion equations kick in.

In fact in some use cases using delta time is more simple and flexible than a fixed rate.

An example? (Other than sub-dividing a fixed rate)

[kappa]

@StumpyStrust

Should I interpolate in the render? update? neither?

There is a nice list of tutorials/articles here that explain various ways to do game loops and time stepping.