Structure Questions

Started by dangerdoc, April 02, 2012, 12:20:51

Previous topic - Next topic

dangerdoc

Hello,
I am making a large program, and I was wondering if you need to add something like threads as part of the loop. Do large programs need something like multiple threads? If so, how does the thread exchange objects with the app? If you really don't need the threads, just tell me!  ;)

Thanks,
dangerdoc
“We build but to tear down. Most of our work and resource is squandered. Our onward march is marked by devastation. Everywhere there is an appalling loss of time, effort and life. A cheerless view, but true.” - Nikola Tesla

CodeBunny

Threading is almost never needed, though there are certain situations in which it may be used to improve performance. However, for most games, basic functionality can be more than supplied with the main thread.

One of the things about threading is that although you free up extra processors to handle your game logic, it often takes a significant amount of processing power / back-end structure to sync everything between threads.

If you need more detail, consider the following example: You have a game world that you are updating in one thread, and rendering in another. Usually, this is so you can update at a slower pace than you render (e.g., 10 times a second instead of 60), allowing for much more complex update logic.

However, you run into problems. You don't want to have the objects you are rendering suddenly change while they are being updated, but that will inevitable happen when they aren't synced. So, let's say you put into place some sort of locks on your system, where you will store the updated data but not apply it until you are finished rendering. Now, your update/render cycle looks something like this (r is render, U is update):

...r U r r r r r r U r r r...

Problem! Your updates are slower than you renders, so the rendered data is not changing, even though it is being displayed multiple times. The only solution to this is to have some form of interpolation between frames - storing object rotational/locational velocity and rendering their path, etc. However, this is that much more extra data to manage.

Ultimately, the solution most people go with is to build "frame" objects during update - a list of objects detailing what to render, and that has built-in visual interpolation functionality. They then pass these objects to the render thread, and then continue building the next one.

dangerdoc

Thanks CodeBunny!
Unfortunately, I do not know much about how threads share data with each other from different classes... If I use threads, how do I interchange objects between them? So, basically, the frame objects just decide which objects to render, using interpolation? So, I render, get some entities updated, render, update more entities, etc. and continue? How do you know how much to update each frame? I am not quite sure what data the "frame" objects contain. Could you explain the frame objects?

Thank you!
dangerdoc
“We build but to tear down. Most of our work and resource is squandered. Our onward march is marked by devastation. Everywhere there is an appalling loss of time, effort and life. A cheerless view, but true.” - Nikola Tesla

CodeBunny

My basic point was to warn you away from threads; if you don't need them, don't engage in the headaches they create.

That said, threads automatically share memory in Java. Think of normal method calls, you can just be calling multiple methods at once and you have to set everything up so that it works when calls occur out of optimal order.

This is kind of a really complicated issue, and I'm no expert - I've had it explained to me and I've thought about it, but I've never implemented it myself.

dangerdoc

All right, thanks for all the help. This really clears things up.

Thanks,
dangerdoc
“We build but to tear down. Most of our work and resource is squandered. Our onward march is marked by devastation. Everywhere there is an appalling loss of time, effort and life. A cheerless view, but true.” - Nikola Tesla