Movement inside a 2D rendering loop

Java 2D
#1

I’ve been writing a little 2D project called warlock (http://www.cokeandcode.com/warlock)

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…

Kev

#2

Don’t use ms as your animation timing reference; use frame ticks. Your character moves 1 pixel every tick.

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.

Cas :slight_smile:

#3

Ahh, I see, so you’re saying to actually limit the frame rate to a set value, and control it of that…

What a wonderful idea!!!

Thanks Cas,

Kev

#4

ALL BOW DOWN UNTO CAS…

I’ve played around with the rendering loop, to move in it the direction you suggested. I limit currently to 40fps, but I think you were implying I should adjust based on hardware available?

Anyway, the result is that the little 2d game happily runs smoothly on a 4MB graphics card, sub ghz processor and little memory…

Woo!

Thanks again,

Kev

#5

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 ???

#6

No, it’s more of a human factors issue. Tests have shown that that human eye can’t ‘see’ at any more than 60Hz, so anything faster is really just information being lost.

#7

[quote]No, it’s more of a human factors issue. Tests have shown that that human eye can’t ‘see’ at any more than 60Hz, so anything faster is really just information being lost.
[/quote]
ARRRGGHHH!!! Not again. It’s a myth that the eye can only see 60 FPS. (They said that about 30fps BTW.) Here’s my (OLD!) attempt to clear this up:

http://www.JavaGaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=2D;action=display;num=1049985932;start=6#6

EDIT: I just realized that I never responded in that thread to this response from SWPalmer:

[quote] The original post saying that 10fps was all that you could see is also inaccurate.
[/quote]
I said that 10fps is all the eye can PHYSICALLY see. Which is true. The brain sifts out the information and interprets the rest.

#8

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 :wink:

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

#9

[quote]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 ???
[/quote]
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.

#10

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?

#11

[quote]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?
[/quote]
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.

#12

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.

Cas :slight_smile:

#13

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’m now off to try Alien Flux ;D

#14

I tried the Alien Flux Demo, but it crashed and had all sorts of errors :frowning:

#15

Scrub that, I didn’t have the OpenAL drivers. It works now.

#16

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?

Thanks!