Threads and LWJGL

OpenGL Development
#1

I know that a lot of you don’t like the idea of Rendering Thread after you had done stuff with AWT, but I have been doing some thinking and figured out that I could probably increase the OVERALL performance by implementing a rendering thread.

As far as I understand, Sun has put a lot of time into the threads and the VM can JIT optimize them pretty well. I know that to most of you this sounds like taking back a step, but the truth is, there is no point of letting the computer render over 100 fps(or insert your own preferance there). This would leave a lot room for the AI and physics to take place, which actually improve the game play a lot. I mean ragdoll physics, everybody loves ragdoll. Besides the real truth about FPS is that you can brag on interweb boards about your coooooool engine.

Now another point is that with LWJGL you don’t have the retard threads running(argh AWT-brainmelt-event-theincredibleCoffeeMachine thread) behind you slowing you down.

Since the static void main is one thread itself(the vm thread) and it could work as your rendering thread, you could put AI and game loop into another thread and then give that thread the time left by the rendering thread.

Now the rendering thread would be left with all the graphics wise important things, such as physics, camera, culling, lodding and finally rendering. This all comes from the fact that tight loops are simply not the best ways to do games, I mean they are great if you want to show off your FPS, but when you have complex game events running behind you it is an overkill and results in very uncontrollable performance.

You could this without rendering thread. Just an idea. Can you list any pros or cons that go with the idea? How about LWJGL, how thread (un)safe is it? I know for the fact that Cas (sarcasm)absolutely loves threads(sarcasm), so that is probaly the main reason why LWJGL rox with threads.

#2

I have my main game loop (with rendering) in a thread and then etworking in another one.

#3

I think Cas is right that LWJGL should not be thread-safe, because I actually don’t see a reason to have several threads feed OpenGL at the same time. But if you want to move other stuff like the game logic to threads, why not? Unless you are already in the optimizing stage, your main criterion should be whether your program works in a pro-thread way. That is, it has to do several unrelated jobs which need to synchronize seldom or never.

#4

Still struggling with hammer/nail metaphor eh? ::slight_smile:

LWJGL has nothing to do with threads, and threads don’t really have anything to do with games. It’s easier programming without threads. Much easier. Just accept it, and start thinking about how you do it.

There’s nothing stopping you using multiple threads. It just won’t be very fast, or smooth, or reliable.

Cas :slight_smile:

#5

I wasn’t exactly talkign about multiple threads, just one extra thread. Does anyone have thread source available? I need to stick with my lap top for awhile and this kicking rad 14k is just not going to handle the new JDK.

I just need to see what the thread class has eaten to figure out how suitable they are.

Edit: I’ve been so long away from the beloved threads that I had forgotten about the thread.sleep thing, which has very unaccurate precision.

Threads are suitable for game programming as in programming in general, perhaps not with Java, yet…

#6

It’s nowt to do with Java at all, it’s about operating system design, and hardware design. Thread’s aren’t designed to do what you want to do, which is accurate timeslicing of concurrent tasks which is hardware invariant. So you basically have to do it yourself, and it’s really a lot easier than it looks!

You can use threads to load resources in the background whilst still rendering; that’s a good choice for them. You don’t need them for IO any more because we’ve got NIO now which can be put directly in the game’s main loop.

Cas :slight_smile:

#7

  1. You’ll spend ages syncronising threads constantly if you’re doing rendering and game logic in separate threads, since the data they operate on overlaps quite a lot.

  2. What does it gain you, really? Other than added unpredictability and more painful debugging…

  3. Windows, and most variations of 'nix are not real time operating systems. While industrical flight sims may use separate threads for various tasks, they are running on real time operating systems. A notable fact is that the j3d team found Java’s threads unsuitable and wrote their own under-the-hood scheduling system.

  4. Use threads for networking and maybe for streaming data off of slow IO devices. Any other use is questionable.

  5. If you’re determined, try it. Theres nothing like experiencing these problems first hand…

#8

[quote]1. You’ll spend ages syncronising threads constantly if you’re doing rendering and game logic in separate threads, since the data they operate on overlaps quite a lot.

  1. What does it gain you, really? Other than added unpredictability and more painful debugging…

  2. Windows, and most variations of 'nix are not real time operating systems. While industrical flight sims may use separate threads for various tasks, they are running on real time operating systems. A notable fact is that the j3d team found Java’s threads unsuitable and wrote their own under-the-hood scheduling system.

  3. Use threads for networking and maybe for streaming data off of slow IO devices. Any other use is questionable.

  4. If you’re determined, try it. Theres nothing like experiencing these problems first hand…
    [/quote]
    OR…use threads within a framework of manually-controlled timeslicing. Make an alternative to the “runnable” interface that replaces a typical “run()” method with a “run( targetFPS, availableMilliseconds, or however your timeslicer works )”.

You can have many of the benefits in making your program simple to reason about (which, incidentally, is a very very good reason for them that people here seem to overlook a lot) whilst actually running a single-threaded system; I’m assuming this is what everyone does? …but the way people talk about it, they make it sound like they have a single monolithic class, and nothing that even vaguely looks like threading anywhere.

PS I’m still in agonizing pain w.r.t. the winXP Sun JVM thread scheduler chewing my are off and spitting it back at me, so I’m not exactly an expert in this kind of threading - forgive me if I;ve said something dumb above, and PLEASE let me know (I’m struggling to tame the beast that is the $%"£$&"£% XP scheduler…is it me, or is it even worse than NT? Surely some mistake (of mine)?)

#9

Threads are the only thing java does well at least in principle. Why not use it? Not using threads is just an ancient legacy from C where the idea of having a thread is very arkward. Also VM does hard work for you so why not?

As long as there is a general purpose for the thread use it, I’m streaming data to my renderer from the heighmap with C++ now and it works great. Only downside was that in C++ I had to “make” a thread wrapper myself to make it multiplatform.

For gods sake, use thread if you see advatange in it, but don’t thread if there is no reason to.

A+++ would thread again.

#10

I made the terrain renderer multithreaded (one to render, one to calculate), and that was relatively easy because the data was static. I had to double-buffer all the rendering data (indices, vertices etc). I got about 5-10% performance increase from another 700MHz. It wasn’t worth the effort.

There’s something else about threading the world which is that you have to double-buffer your world data. Consider a thread which runs the AI and a thread which is accepting updates from a multiplayer server.

The AI thread starts with monster 1, which groks all the positions of nearby entities to make a decision on what to do next. The multiplayer update thread, halfway through monster 1’s AI, suddenly kills the monster because some remote player has killed it. All of its calculations are invalid now but it’s going to carry on doing them anyway. This is just a trivial example of the kind of awkward shenanigans that happen with threaded AI.

The best use of threads is to load background resources - ie. doing what threads are meant to do, doing I/O and sleeping a lot.

Cas :slight_smile: