0

I'm using LibGDX at the moment for an Android project but I think the answer to this question can be usefull whatever framework/library or language you use.

All the tutorials I've found on internet (for LibGDX) make calculations like moving entities when the render() method of the whole application is called, and just before drawing each entity. I think this is probably necessary because for example if you have an object that should move at 3m/s when render() method is called you will do something like position.y = velocity.y * deltaTime so the movement makes sense according to the speed of the object.

But what about calculations like -> what path an AI-controlled object should follow not to hit a wall or according to player's moves ? In 2D, and so even more in 3D, there can be a lot of calculs, arethmical operations etc... and results are not linked to the deltaTime and don't need to be aware of it. Also this could slow down the rendering and so the application when running on some phones or tablets that are not very powerfull.

So should this type of calculation be done at rendering time or only when needed in another Thread ?

Improve this question
2
  • Actually, you generally want only rendering-specific stuff in your display threads. Obviously, this can still be fairly intense in it's own right. However, things like updating a unit's position in the physics simulation, AI calculations, etc, should be in a separate thread (depending on system resources, and architecture, one apiece) - you want that render thread to be as fast as possible. Commented Aug 31, 2012 at 15:28
  • Thanks, I was not sure. Please can you post as answer so I can accept it. Commented Sep 4, 2012 at 14:31

1 Answer 1

Reset to default
1

Actually, you generally want only rendering-specific stuff in your display threads. Obviously, this can still be fairly intense in it's own right. However, things like updating a unit's position in the physics simulation, AI calculations, etc, should be in a separate thread (depending on system resources, and architecture, one apiece) - you want that render thread to be as fast as possible.

There's also something called separation of concerns - if you're both updating an object's position on screen (re-drawing), and moving it, in the same thread, then it's doing two things, which may make future modification/maintenance more difficult.

Please note that if you are doing multi-threaded architecture, your setup will need to have some way to ensure that you're not updating things while you're rendering them, or you may get some odd results.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

updating an object's position is the same as moving it, no ?
Whups, meant updating on-screen (redrawing). Clarification added.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.