Hi !
Featured games (85)
games approved by the League of Dukes
Games in Showcase (623)
Games in Android Showcase (176)
games submitted by our members
Games in WIP (676)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  What's the best way to move object  (Read 3025 times)
0 Members and 1 Guest are viewing this topic.
« Posted 2008-05-17 10:38:14 »

I've been thinking that which way is the best to move something to some direction in some time.

Let's say that I have Thread that sleeps 100 ms and I move image to right with x+=1. I can make image move as much in same time to right so that I put thread to sleep 200 ms and move Image x+=2. Which way is better (or is there a better way at all)? 
Offline oNyx

JGO Coder

Medals: 2

pixels! :x

« Reply #1 - Posted 2008-05-17 15:18:37 »

If you mean a separate thread... then no. Don't do that.

Move everything in the main thread. Moving things more often (and in smaller steps) will look smoother. Try to aim for the de facto standard of 60 fps.

弾幕 ☆ @mahonnaiseblog
« Reply #2 - Posted 2008-05-18 09:57:32 »

Thank you for answering!

Ok. Why everything should be in main thread? I have nothing against that but I am just curious. Is it because then repainting and moving would be synchronied?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder

Medals: 2

pixels! :x

« Reply #3 - Posted 2008-05-18 16:23:52 »

Ok. Why everything should be in main thread? I have nothing against that but I am just curious. Is it because then repainting and moving would be synchronied?

Yes, it's synchronous and there is also little overhead. In some games you have 2000 or even more objects. Using a thread for each would slow it down to a crawl. Parallelizing things on such a low level simply doesn't work with most languages. Or let me put it this way: it doesn't work with threads.

Erlang for example is able to parallelize even the tiniest tasks, but Java or C/C++ use a different architecture. Threads are pretty heavyweight and should be only used for rather big tasks.

Multitreading isn't required or even remotely sensible for most small-scale games. It's a source of really nasty errors and there is very little to gain. It's good for speeding up the loading process (if you know what you're doing) or making the loading screen smooth though.

弾幕 ☆ @mahonnaiseblog
« Reply #4 - Posted 2008-05-18 19:58:46 »

Thanks for your information!

Offline Eli Delventhal

JGO Kernel

Medals: 42
Projects: 11
Exp: 10 years

Game Engineer

« Reply #5 - Posted 2008-05-18 21:40:24 »

I recommend learning how to use a time lapse variable in your main loop, like tau. I actually have a write-up I made for it, which I can post for you. Note that this comes from a technical report on the process of making my game Agent: 00PK, and is meant for the layman. As such, some of this might be completely obvious.

Any “continuous” video game is controlled via what is called a game loop, or sometimes
a main loop. This is a place in the code that constantly cycles over and over again – in a long
loop. Every time the loop cycles, it performs the same game actions.  These might be to draw, to
calculate physics, to update positions, to run the AI, or more. Any actions that must happen
“constantly” are actually called within the game loop in extremely rapid intervals. This gives the
appearance of constancy and a continuous function.

 A good analogy to this would be a runner going around a track. The track is surrounded
by other events, like shot put and the high jump. On this particular track, however, the runner is
being followed by a cameraman. The people in the other events only want to perform when they
have camera exposure. So, as the runner passes the shot put, the strong man throws the ball. As
soon as the runner leaves, the shot putter stops. As the runner passes the high jump, the
contestant hurdles himself up over his goal, but he doesn’t make another attempt until the runner
comes back. The track meet will finish eventually, but will only continue as the runner passes by
each contest. Now imagine that the runner and cameraman are incredibly fast – so quick that the
shot putter and the high jumper can’t even tell when they’re being filmed or not. As a result, they
will appear never to stop – even though they are actively waiting for the camera; it comes around
so often they go as fast as they can.

 The game loop is more than similar to this situation – it is practically the same. The only
difference is that in the game loop the cameraman stops and waits at each event before he goes to
the next one. If the contestants are incredibly fast, then the observers can’t even tell that any
waiting is happening; they assume that everything is happening all at once. The game loop is run
by a computer, and so naturally is this fast. The result is that, although all actions are called
incrementally, they appear to be happening simultaneously.

 But what happens if the shot putter takes too long and forces the cameraman to wait? The
answer, of course, is that every other contestant can’t go until the shot putter finishes. To the
game, this circumstance would either result in a temporary freeze or a permanent one. But, these
circumstances are only caused by errors or poor code, so there’s not much that can be done about
them. What we are concerned with, however, is when one shot putter is faster than the contestant
before him. In this case, the cameraman will be going around the track at seemingly random
speeds, which will definitely confuse the observers.

 In the game loop, some operations may take significantly longer in one time step than
they did in the previous one. This gives a non-constant rate of change, so the gravity can’t simply
say to apply 9.8 meters per loop, because the span will be different every time. Without
constancy, there needs to be some way of measuring the irregularity, and then adjusting

 The result is a variable called tau. Despite having a greek name, its value is quite simple:
it records the amount of time since the last time step by measuring the system clock. If tau is
very large (meaning that the cameraman had to wait an extra long time), then gravity needs to
work extra in order to account for the longer “second.” If tau is very small, then everything
happens at a smaller fraction of the rate it would normally.

 Think of tau like a ratio that controls observable time. It’s analogy in the track and field
world would be the cameraman’s feed to the television. He wants the audience to see exactly 100
respective events per hour, regardless how long each event actually takes. So, if each loop
around the track, all events considered, takes him 36 seconds, that means that the audience will
see the targeted 100 events in an hour. This golden number, which we’ll call our normal time, is
the exact number of milliseconds we want every lap to take. The cameraman can’t control how
fast the shot putters and the high jumpers are, but he can control how fast he is. So if the shot
putter takes 10 seconds and the high jumper takes 5, that makes the tau 15. The cameraman
therefore has 21 seconds to finish the lap. If the tau increases up to 30, then the cameraman needs
to put on the juice and run around the lap in just 6 seconds. If tau is only 2, then the cameraman
needs to slow down, finishing his lap in a snail’s pace 34 seconds.

 Although it might not be completely obvious, what’s really being changed is the
cameraman’s velocity. If the track is 100 meters around, then with a 15 second tau the
cameraman needs to run at 4.76 meters per second. With a tau of 30, the camerman must run at
16.66 meters per second. With a tau of 2, the cameraman will be moving at only 2.94 meters per

 Agent: 00PK’s game loop is just like the cameraman, except it’s significantly faster, and
instead of changing the cameraman’s speed, we’re changing all applied velocities. Someone’s
downward velocity, for example, might be 5 meters per second with a tau of 1, and 10 meters per
second with a tau of 2. This means that, no matter how slow or fast a computer might get, the
resulting physical changes will always happen at a steady rate. This concept is detailed more
specifically in the physics below.

Basically what you do is make your thread yield when it's going too fast, ( Thread.yield() ), and move everything a certain amount times tau each timestep. The bigger tau is (the longer the wait), the more you move each object. The opposite is naturally also true.

See my work:
OTC Software
« Reply #6 - Posted 2008-05-19 17:48:07 »

Thank's for your help!

I have to read that text few times now. Due to my average english skill I have to focus to everything that I read and it takes time to understand everything.
Offline Eli Delventhal

JGO Kernel

Medals: 42
Projects: 11
Exp: 10 years

Game Engineer

« Reply #7 - Posted 2008-05-19 18:30:42 »

Thank's for your help!

I have to read that text few times now. Due to my average english skill I have to focus to everything that I read and it takes time to understand everything.
Sure. If you've got questions, I can help as well. Just post them here.

See my work:
OTC Software
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

basil_ (42 views)
2015-09-30 17:04:40

shadowstryker (21 views)
2015-09-29 15:55:06

TheSpaceHedgehog (27 views)
2015-09-29 01:58:48

GamerC4 (50 views)
2015-09-24 21:10:38

GamerC4 (70 views)
2015-09-24 21:09:48

htuy (24 views)
2015-09-24 04:57:24

htuy (34 views)
2015-09-24 04:56:35

htuy (25 views)
2015-09-24 04:56:09

htuy (26 views)
2015-09-24 04:47:33

Roquen (63 views)
2015-09-21 12:54:28
Math: Inequality properties
by Roquen
2015-10-01 13:30:46

Math: Inequality properties
by Roquen
2015-09-30 16:06:05

HotSpot Options
by Roquen
2015-08-29 11:33:11

Rendering resources
by Roquen
2015-08-17 12:42:29

Rendering resources
by Roquen
2015-08-17 09:36:56

Rendering resources
by Roquen
2015-08-13 07:40:51

Networking Resources
by Roquen
2015-08-13 07:40:43

List of Learning Resources
by gouessej
2015-07-09 11:29:36 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‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!