After lots of advice from here I decided to go for (what seems to be the standard) route of having one central game loop that runs on the main thread and controlling pretty much everything from there..

However, I have a small problem. My characters are moved one pixel at a time every about 20 ms. However, if my frame rate falls particularly low (infact anywhere under 50) the characters movement is actually slowed down compared to faster systems. This seems logical in that the character doesn't get as many chances to move.

Now, I've considered making the movement a factor of time. This would pretty fiddly for the little spritey type game I'm writing. I was just wondering if there is a better way.. I considered another thread to run the movement, but I've seen that most people here don't think seperate threads are a good idea...

Any help, or feedback on the game at all... would be most appreciated..

The key to 2D is absolute consistency. If your target system cannot manage 60Hz updates, then halve the framerate to 30Hz and animate your characters at twice their normal rate, eg. 2 pixels every tick.

Don't attempt under 30Hz because it looks awful. Don't attempt over 60Hz because it's a waste of time.

[...]I said that 10fps is all the eye can PHYSICALLY see. Which is true. The brain sifts out the information and interprets the rest.

Eh... it's below 10 fps (~8hz iirc) and it's not the frequency of the whole eye; instead it's the frequency of a single "pixel" (don't know the right term).

The "pixel" refresh is asynchronous... we all know the result - it's motion blur

A bunch of different pixels is needed if we want to identify different frames. If the frames already have motion blur (tv/cinema*) a framerate of 25-30 is needed. Sharp computer graphics need at least twice as much frames because there is no motionblur and the interframe blending has to be "computed" in our brains.

*=They use _heavy_ motion blur in the cinema if the cam turns.

Btw... turns... for first person shooters you need even a higher framerate, because everything on the screen changes quickly if you move the mouse just a *bit*.

And even if you have steady 85fps@85hz you will be able to see single frames if you get into the zone.

Sometimes I'm able to see the hidden messages/pictures in movies/tv series (the ring, home improvement etc)... but I'm usually unable to notice color shifted text messages w/o slowmotion o_O

Hello, just out of interest why don't you recommend 85Hz? I run all of my games at this refresh rate, or is this more of a resource/java issue ?

Well, human factors and Java issues aside, while many people have good monitors that can display 85Hz, many people don't. Also, laptop and flat screens will usually refresh at a maximum of 60Hz, due to the differences between TFTs and CRTs.

If your game *requires* 85Hz, no one with a laptop, a flat screen or an old monitor will be able to play it. If you *recommend* 85Hz, and tie all your animations in to this frequency, the game will run too slow.

I guess it's best to at least support 60Hz. Depending on your target market, for slower machines or older monitors it may be worth considering 30Hz as well. For people on higher-quality monitors? I don't know - is the step up to 85Hz worth storing another set of timing calculations for? That's entirely dependant on your target audience and the type of game.

Ok. But I have to say I can tell when my monitor is running at 60Hz compared to 85Hz, it actually hurts my eyes. Maybe because I'm used to running everything at 85Hz?

Are you talking about in the game or under Windows? Under Windows, 60Hz can be painful, but for a game (where the screen changes rapidly) 60Hz should be more than sufficient in most cases. If 60Hz in games hurts, you might need a new monitor. (Preferrably one with a better dot pitch.) Adjusting the brightness a little lower can also help by making colors more vibrant.

Coffeemonster - (plug alert) go and download the Alien Flux demo and see what it looks like. Then for an experiment you can try it in 30Hz mode (Options menu). Alien Flux demonstrates everything you need to know about (and do) in 2D games programming so it's a handy reference in that respect.

Yeah, I mean in Windows. My monitor is actually pretty high end CRT job, 0.24mm pitch, so it isn't anything to do with it being poor quality AFAIk. I may just be used to 85Hz, I'm not sure. I run my desktop and all games at that refresh rate.

Anyway I should have pointed out that I haven't actually programmed any games as of yet, so I wasn't fully aware of the rendering/refresh rate issues. Obviously, restricting games to only 85Hz is a daft idea as lots of people only run at 60Hz or less.

I think the idea of deciding movement rate based on frame ticks is great. I have just started doing some pre dev testing before I dive into my first game development effort, and this forum is helping out a bunch. I do have a question though: How exactly do you determine the frame ticks? I was figuring I would have to do a timing loop (based on ms values) to determine when actions had completed and update a counter...

UMM... actually... in writing this out it's all become clear (I think). The ticks happen when your render loop executes as JAVA can't draw to the screen faster than you're selected refresh rate, so if you build all of your logic into that single render loop (ok, by that I mean make the appropriate logic calls to other Objects to calculate behavior) then everything will gel...

Hehe.. I guess I know that my FPS counter is working then (as it gets to 85.0 and sits there at home - with an 85Mhz refresh and 75.0 and sits there at work - with a, you guessed it, 75Mhz refresh). Also, if the render loop is taking too long I'm assuming that you will still experience slow-downs, so it makes sense to limit the refresh to a rate that's compatible with the system specs you are designing for (or offer options to change the rate). Am I getting it?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org