Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (575)
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  
  Threads and LWJGL  (Read 2430 times)
0 Members and 1 Guest are viewing this topic.
Offline Captain-Goatse

Junior Duke




I suck at teh 2D. XBOX IS BIG LOL!111


« Posted 2003-04-10 04:15:51 »

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.
Offline darcone

Junior Duke




Size matters


« Reply #1 - Posted 2003-04-10 06:20:15 »

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

Senior Newbie




Java games rock!


« Reply #2 - Posted 2003-04-10 07:51:42 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 403
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2003-04-10 10:07:41 »

Still struggling with hammer/nail metaphor eh? Roll Eyes

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 Smiley

Offline Captain-Goatse

Junior Duke




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #4 - Posted 2003-04-10 10:21:30 »

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...
Offline princec

JGO Kernel


Medals: 403
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2003-04-10 14:58:35 »

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 Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #6 - Posted 2003-04-10 15:22:30 »

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

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #7 - Posted 2003-06-05 22:06:33 »

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.

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


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 ar*e 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)?)

malloc will be first against the wall when the revolution comes...
Offline Captain-Goatse

Junior Duke




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #8 - Posted 2003-06-06 09:40:19 »

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.
Offline princec

JGO Kernel


Medals: 403
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2003-06-06 09:53:46 »

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 Smiley

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

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (35 views)
2014-10-17 03:59:02

Norakomi (25 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (26 views)
2014-10-15 16:18:58

TehJavaDev (50 views)
2014-10-14 00:39:48

TehJavaDev (50 views)
2014-10-14 00:35:47

TehJavaDev (40 views)
2014-10-14 00:32:37

BurntPizza (63 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (75 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org 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‑gaming.org
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!