I took the advice of mojo and started by setting up a fixed fps version of simplegame, FixedSimpleGame.
its basically just a copy of simpleGame which extends FixedRateGame and has some misc code snippets copied over…so no biggie there. I just think people might have wanted it for the same reasons i did, I was tired of hearing my computer throttle to a few thousand fps everytime i wanted to see something in action. Anything that ran with simple game should run with FixedSimpleGame, just extend FixedSimpleGame instead of SimpleGame. I included FixedHelloKeyInput to give people the idea.
then i thought what the heck, why dont i make it possible for FixedRateGame to read the fps from the Jme properties dialog at startup and save it in the properties file. When i was making those changes I noticed something that I, at least, found odd.
if the timer resolution is always 1000 ticks per second and we use floats to calculate preferredTicksPerFrame strange things can happen. for example in the following case:
if timer.getResolution()= 100
and the user enters something larger then 1000; say fps = 1200
would yield a preferredTicksPerFrame of 0....which seems a bit odd...though i bet there might be an explanation for that.
I also got this strange case where the eclipse debugger was telling me
1000ticks / 2000fps made preferredTicksPerFrame =10
I thought maybe we should be using floats for this calculation...as I was under the impression thats what graphics api used for this kind of thing...got that idea from this site: http://www.accu.org/begincpp/public/disc_topics/doubles_floats.html ...anyway just thought I wouldbring it up, at least I`ll learn something from peoples replies.
It should also be noted that there is some strange behaviour in the calculations for the framerate somewhere down the line. Jme seems to be able to run at the rates specified until the 60fps region where if you continue to tell jme to go to a higher rate it will stay the same as it was before. If you try fps 60 and fps 100 they yield the same result perfomance wise, then if you put something huge in, say 3000 fps, jme goes back to almost a "as fast as possible" loop. Why this is i`m not sure.
I changed the default of 60 fps to being loaded from the dialog menu...this seemed important, as hardcoding it didnt quite seem flexible.
this:
Hm, well someone with a little more insight into the timer issues will have to look into that before this can be checked in.
Some other minor issues though. The "fps" box in the dialog should be optional, and off by default. Something like "max. fps" is probably more approriate than "fps". If I could check this in I would have made them myself…
I believe we need a more "pluggable" interface for that dialogue. It seems its pretty easy to create an interface which has "getWidth, getHeight…etc" and create your own JFrame, implement that interface and set the AbstractGame's properties dialogue to it. e.g. app.setDialogue(myDialogue);
Seems pretty easy, i'l get to implementing myself so that we can have a more extendable architecture for this.
your completely right llama, my quick and dirty solution there could be improved. i wont bother reposting it, if someone deems it appropriate to check this in they can do whatever tweaks they want including changing the label.
One thing to note is that making the fps entry optional opens a bit of a ball of wax, One nice thing to code would be to only show it when running code that would need it like fixedrategame…should have thought of that…anyway…i didnt need that funtionality at the time…so again maybe someone will build on what humble blocks i laid.
DarkProphet, sounds like a good plan, for now it does what i wanted it to do, but a more pluggable system can be nothing but better. ill wait and see how that goes.<br /> <br /> Id still really like to hear what people think about the timer/ long vs float /fps issues.
now that i think of it, I didnt really make any enormous changes, and I feel like a bit of a idiot for even posting it…i just thought someone might have had the same small gripe i had. In particular, I think the devs may not like the way I used that static reference in there…dont know what teh conventions would say about that. Im pretty new to the whole open source idea, so Im not really used to keeping things really clean and elegant, when all i wanted was a quick solution.
now that i think of it, I didnt really make any enormous changes, and I feel like a bit of a idiot for even posting it...i just thought someone might have had the same small gripe i had. In particular, I think the devs may not like the way I used that static reference in there...dont know what teh conventions would say about that. I`m pretty new to the whole open source idea, so I`m not really used to keeping things really clean and elegant, when all i wanted was a quick solution.
peace
Well, it seems you are on to something, so don't feel like an idiot. I'm just not familiar enough myself with the Timer code to make a judgement about it.
well i just realized i didnt put updated PropertiesDialog or PropertiesDialog2 into that zip, so i guess i do got a bit of idiot in me…lol…ive added them now.<br /> <br /> yeah, as for the timer, I hope someone can address my question, if nothing else id learn something from it.
on an slightly related note…Im starting to wonder what the best way of using the fixedLogicRate and fixedFrameRate in the same implementation is. Maybe im missing something, but the way frames are handled in logicrate isnt quite what i was thinking of.
I know all of this stuff isnt core related, but i think its worthwhile…
You could simply extend SimpleGame and override the update method and that should provide what you're looking for, right? Just modify the update method to work similar to FixedRateGame…
it seems to be a good idea to have a fixedSimpleGame !!!