How to use FixedLogicrateGame's 'percentWithinTick'?

Hi there!

I’m using my own subclass of FixedLogicrateGame which has essentially the same functionality as StandardGame but does not use multithreading and - yeah - a fixed logic rate ;D

Playing around with the tutorial code of ‘simplegame to standardgame’ and trying to use my custom class instead of Standardgame i noticed 2 things:

a) Since FixedLogicrateGame does not use the interpolation parameter(and therefore my subclass does neither) but instead passes -1.0f to the update()-functions of GameStates now the DebugGameState behaves kinda strange. By strange i mean that the FPShooter-movement seems to be inverted(pressing ‘w’ moves backwards, ‘a’ turns right, etc.). It’s not that much of an issue since i could fix it by making the moveSpeed in

input = new FirstPersonHandler(DisplaySystem.getDisplaySystem().getRenderer().getCamera(), -1.0f, 0.5f);

negative but it got me thinking about handling keyinput in general.
        My question is now: Does it make sense in general to pass -1.0f to for example InputHandler's.update()-method and (and other class's update()s as well) since it seems it does not work as intended or should i pass 'percentWithinTick'?(But where's the point in not using the interpolation parameter then?)

b)When i set the LogicTicksPerSecond to a reasonably low level like 15 the movement of the camera becomes quite choppy.(I know that it's supposed to be choppy when i only update 15 times a second) If i understand the general concept of FixedLogicrateGame i should now somehow use percentWithinTick inside the render()-function to draw an interpolated frame along the lines of:

Camera.xpos += speed*percentWithinTicks;

so that the camera is moving smoothly despite the low update rate.

But inspecting the code inside DebugGameState i can't seem to find a possibility to do something similar:

public void render(float tpf) {   
        // Render the rootNode

        if (showBounds) {
            Debugger.drawBounds(rootNode, DisplaySystem.getDisplaySystem()
                    .getRenderer(), true);

        if (showNormals) {
            Debugger.drawNormals(rootNode, DisplaySystem.getDisplaySystem()

        if (showDepth) {
            Debugger.drawBuffer(Texture.RTT_SOURCE_DEPTH, Debugger.NORTHEAST,

Where would i use percentWithinTicks? I mean the parameter 'tpf' doesn't even seem to affect the whole rendering-method at all, so?

Thanks in advance and sorry for the bad English :D

You could modify it to sent 1.0f instead of -1.0f and that would fix it. :-p

Do you realize that StandardGame doesn't require you to do "multithreading" and though it doesn't support fixed logic rate it does support fixed rate and vertical sync.  I've never really been very clear of why anyone would choose to use the fixed logic rate so perhaps that's where I'm missing something. :slight_smile:

Most aspects of jME's controls rely on tpf in order to determine how fast to adjust though, so you're going to have a lot of headaches there I think.

thx for the reply darkfrog and ,yea, that -1.0f to 1.0f "fix" came to my mind too ;D

My naive idea of working with fixed timesteps in jME was that I'd run the logic only several times(like 20) a second and then render as fast as the user's system configuration allows, since polling input, updating coordinates, etc. aren't things that have to be run like 60+ times a second.

For my past 2D game projects that worked like a charm since I didn't have to work with floats/doubles in my logic-function.

public void update()
         Player.yPos -= 5;

instead of

public void update(float tpf)
         player.yPos -= 5*tpf;

Then(to compensate for the obvious stutter in movement) I'd just compute something like 'percentWithinTick' and use that in my render function to draw the playersprite at an offset postion.

public void render(float tpf)
   Draw(player_sprite, player.xPos, player.yPos +tpf*yMoveSpeed)

I know that it's not much of a difference to a variable timestep model since i end up multiplying float values too(not in update() but in render() ;D) but it made the logic deterministic(which helps a lot when networking) and was slightly faster(at least on my less powerful machine).

But if like u said each and every update() requires the proper tpf to work correctly i might just switch to a variable timestep model as working with fixed logic seems not worth all the trouble^^(it seems as if jME clearly favours variable timestepping)

Regarding StandardGame:
I really like the the structure of the class and the whole gamestate-model to implement things but what really held me back from actually using it was(besides the fixed logic) the separated OpenGL-Thread which isn't that "newbie-friendly".

Having to focus on figuring out which statements have to be injected into the OpenGL-Thread and struggling with Callables and locking/unlocking gives me a much steeper learning curve than just having to worry about jME as is.

(as i attempt to use a variable timestep model now i guess that topic might be obsolete^^)

Well, like I said previously, StandardGame is designed around making it easy to do multithreading, but itself does not force you to do everything outside of the OpenGL thread.

You can easily make StandardGame all run in a single thread by creating your initial GameStates previous to calling StandardGame's start method or starting the app and then making the creation of the first GameState be part of a GameTask that gets inserted into the game.  From there as long as you design your GameStates to do creation of additional game states and do all of their work in the update/render methods it will never call anything outside of the OpenGL thread so you'll never have to worry about multithreading evils. :slight_smile:

Further, to elaborate on my previous statement, you can specify a fixed framerate or vertical-sync to drop the number of updates per second being done in your game and that should conform better to what you are previously used to.  StandardGame actually defaults to using vertical-sync (however, you can easily change this to fixed framerate or variable if you so desire).

Seems as if i should give StandardGame one more chance!

(I'll try to incorporate the "single-threadedness" you suggested - wish me luck ;D)

Why should I wish you something that does not exist? :wink:

I'll wish you success instead.  :stuck_out_tongue:

Lady Luck exists, otherwise Rincewind would have been dead long ago!

Stealing from a book that parody's fantasy books is not my idea of evidence my friend.  :stuck_out_tongue:

darkfrog said:

Stealing from a book that parody's fantasy books is not my idea of evidence my friend.  :P

i suppose you didn't read anything(or if, then not much) from terry pratchett yet, otherwise you wouldn't say that.