Problem with FixedLogicrateGame

I’ve been using FixedLogicrateGame for my program and it had been working with no problems on my main desktop.



When I tried it out on two of my laptops (a dell 700m and a 600m) I started getting crazy results.



On the 700m it was telling me that update was being called 2000 times a second even though I set it do 200 updates a second. On the 600m it would stay at 200 updates per second unless a particle effect went off in which case it would spike up to 400 updates per second then go back down once the particles went away.



On the 700m the particle effects updates incredibly slow (like molasses). I could understand the game running slow on the laptop but not the odd update count.



I’m getting the update rate by doing timer.update() in the update() method. I assumed this just counts the number of times update() gets called per second.

I wanted to try and have a FPS count and UPS (Updates per Second) count but it seems like you can only have one Timer . Is that correct?



I’m really confused now haha.



Anyone have an example of using FixedLogicRate?

Hm, never had problems with this. I simply took an app extending SimpleGame and Changed that to extending FixedLogicrateGame then i copied in all the missing methods and variables from SimpleGame and fixed the imports.

At last i changed all calls to methods to use 1.0f as the time passed (with the exception of the fps counter) and that was the main part.

But maybe this is not the best way to do it so an example (best put in jmetest itself) would be fine.

On the first question, i think that the fps counter does not work well with FLGame and goes up, when in fact the fps goes down below the desired setting?

Why are you passing 1.0 as the tpf? Don’t all the methods in your update need the time per update (rather than the time per frame).

the Update method in FixedLogicrate game always passes 1 as the frame interpolation is never different. The tpf should be:



float tpf = 1/numOfTicks;



you have to declare your number of ticks, there should be a getter really…



How are you measuring the number of updates in a second?



DP

I was just using the Timer to get tpf.



updateTimer.update()

tpf = updateTimer.getTimePerFrame();



I was assuming getTimerPerFrame() just returns the time interval between the last update() call.



I was also using getFramesPerSecond() to get the number of updates per second which was always hovering around 200. (That’s the number I set it to). On my laptop though that number is reported as 2200 or so which doesn’t seem to make any sense.



Also the update() call in fixedLogicrateGame returns -1 for me which I think is correct meaning you don’t use it right?

okay … here’s the problem when using FixedLogicrateGame





If your framerate ever drops below your targeted update rate than it just breaks.





So if I want 200 updates per second but I can only get 120 FPS then it all goes crazy.



Notice how I’m very vague and use the term “crazy”. That’s becuase I don’t know what’s going on yet hehe.

That’s interesting. That’s also not good… I wanted to use FixedLogicrateGame for my game, but if this happens… When I was using Xith3D, i would have the logic executed in a separate thread using a Timer object. That seemed to work perfectly no matter what the framerate was. Any jME gurus can tell me which method is better?

I think the problem can be fixed by changing the way fixedLogicrateGame works. Unfortunately, I haven’t really made it a priority to figure out how the FixedLogicrateGame is working right now as I’m trying to fix lots of other bugs that keep me from compiling hehe.





IF you do come up with a solution though pleeeease let me know :smiley:

imho, FixedLogicrateGame and other such types have not really received that much attention and could be upgraded significantly. Look for upgrades to come in future releases.

"renanse" wrote:
imho, FixedLogicrateGame and other such types have not really received that much attention and could be upgraded significantly. Look for upgrades to come in future releases.
Why haven't they though? As far as I can see, if you want a real production quality game, you need the logic to be executed at a fixed rate, especially if it's to be multiplayer. Also, what do you think about what I said a few posts up about using a Timer object to execute the logic?

Why haven’t they? Because there are many features to implement yet and what one person may feel is important to have now varies from another. All I can say is that it will be dealt with as the schedule dictates.



As for your suggestion, that’s possible, as long as any direct calls to gl (if any) were synced properly.

Why haven't they though?


Originally, it was meant that a user would extend AbstractGame with a game type of his own (matched to his specific needs). That was the original entent, as there would never be a game loop that fit everyones needs. However, as time went on, we found ourselves doing the same thing over and over again for the demos, so SimpleGame was born. Similarly, other game types got committed into the base line over time that people found useful (and others didn't).

I still maintain that you should start from AbstractGame and go from there, allowing you to custom build a game loop to your needs.
I still maintain that you should start from AbstractGame and go from there, allowing you to custom build a game loop to your needs.


Yeah ... I agree. I'll eventually replace FixedlogicrateGame with my own (or a fixed version of fixed logic :) )

Of course that being said if a game type is committed to the jME core it should work the way it's supposed to.

Once I figure out what the problem is I'll be sure to post the code here so everyone can use it.

Just an update if anyone else is curious about this (shochu and I’ve already talked about this), the FixedLogicrateGame works just fine, you just need to make sure you don’t over-compensate by multiplying your motion by the time-per-update (like you’d do with BaseGame).