Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
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  
  Is Alien Flux single-threaded?  (Read 3196 times)
0 Members and 1 Guest are viewing this topic.
Offline 20thCenturyBoy

Senior Member


Medals: 3


So much to learn, so little time.


« Posted 2004-06-02 02:54:29 »

Some people (e.g. on the Gage http://java.dnsalias.com front page) say that multiple threads are not necessary in the typical action Java game. However lots of books and articles seem to use threads for various systems (animation, sound etc). What is the "best" advice for smooth gaming? As an aside, is Alien Flux single or multi-threaded?

20thCB

"I have never done unit testing and I don’t find it a very useful concept" - Jonathan Blow
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #1 - Posted 2004-06-02 03:31:31 »

IIRC, AlienFlux has a singel-threaded main loop.

Think of this: why have an animation thread when you need to synchronize every frame anyway?

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline 20thCenturyBoy

Senior Member


Medals: 3


So much to learn, so little time.


« Reply #2 - Posted 2004-06-02 03:46:28 »

Quote
Think of this: why have an animation thread when you need to synchronize every frame anyway?  

I don't know, I'm a newbie, maybe you could explain further?  Tongue

"I have never done unit testing and I don’t find it a very useful concept" - Jonathan Blow
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 390
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2004-06-02 06:25:51 »

Alien Flux is single threaded, as are all my trivial single player games going to be.

Main loop does something like this:

while (!finished) {
readInput();
think();
render();
waitForFrame();
}

Cas Smiley

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #4 - Posted 2004-06-02 06:49:30 »

Whenever a frame has to be rendered, you have to have everything right in place. Logic has to be done, motions performed, animations animated. If done multithreaded, you would just have to make sure that each thread reached the ready-to-render state. So they have to be synchronized at one certain point. That means MT does not give you any advantage any more.

MT typically comes into play when dealing with the network (my domain Smiley ). Network message arrive any time and you don't want to be your ping values being dependant on framerate. So there's typically one thread receiving network messages.

Again, most information received from the network cannot be evaluated right in place but have to be synchronized with the gameloop again (many 3D engines get REALLY pissed off when modifying transforms while they are rendering Smiley ).

General: MT is always difficult. Avoid if you can. In games, you can.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #5 - Posted 2004-06-02 07:01:53 »

Quote

General: MT is always difficult. Avoid if you can. In games, you can.


! That sounds very wrong to me. MT isn't difficult at all, really. And there's no reason to avoid it in general programming.

The situation with games dev is that you have specific reasons for wanting to avoid non-deterministic timing behaviours, and at the same time you derive no advantage from OS-provided multi threading because it's quite easy for you to write your own real-time thread scheduler that is at least as effective as the OS.

In a perfect world, all games would be MT IMHO. A couple of things would be needed though, including:
- an OS switch "please use an RT scheduler on my thread group"
- Sun fixing (ie preferably removing) their "innate" multi-threading.

The latter is a particular problem on windows, where the "secret" AWT threads not only screw up your programming but in games also make it extremely difficult to guarantee stuff happens at even approximately the right time.

I've seen people do MT in java whilst swearing blind they weren't, and without using the Thread or Runnable anywhere in source; they had inadvertently found out how to hijack the innate AWT thread, and were simultaneously using their main thread. It was fascinating, but also no surprise that they had lots of very weird bugs no-one could tell them how to fix.

If you had a really good OS (they do exist, but you can't generally buy them as consumer OS's) then you could go MT no problem. The reality of games programming today is that there are outstanding problems with the timing of threads especially in java (read Sun's API docs on threading - you will note they make statement like "this method offers no guarantees that anything will happen at any particular time or frequency").

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 390
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2004-06-02 07:33:07 »

Threads are still the wrong tools. You actually want parallel tasks, which is a very different kettle of fish.

Cas Smiley

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #7 - Posted 2004-06-02 09:53:17 »

Quote
MT isn't difficult at all, really.


Oh yes, it is. As soon as you have to handle synchronized/wait/notify, it gets weird and needs are VERY thorough understanding of what is going on!

Sporadic deadlocks are bastards!!




HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #8 - Posted 2004-06-02 10:20:43 »

But...in most cases you don't ever have to go near wait and notify.

For instance, I've been doing MT java coding heavily for the last 6 years, and it's literally been years since I last used wait + notify. Synchronized is a different matter entirely, but is actually a very simple concept once you understand it (I have ongoing debates with a friend who believes that some people just aren't mentally capable of grasping the concept without huge difficulty - he reckons it's like "being good at Maths": some people just can't visualize it properly. I'm open-minded but not convinced yet Smiley).

The only time I can remember really making good use of wait/notify was as the core for a MUD server, where it had thread-per-client and all client threads waited on the server ticking clock. Each tick, it simple called notifyAll as a convenient way (in just a few lines of code) of approximately synchronizing all clients to the same "fair" clock-tick.

All the producer/consumer examples that are common on uni courses and java websites for instance are a gross deception - these are rarely used in real life (there isn't much software that uses multi-threaded pipelines these days - and even then there are alternative algorithms to achieve the same features). They're great for teaching people a practical use for wait/notify, but ... I can't remember seeing one in a real life system (apart from the odd academic distributed system, and occasional academic/research OS).

What about you - do you see a lot of wait/notify "in the wild"? I've always assumed some industries use them heavily, but then again perhaps they aren't using java for that level of their systems?

malloc will be first against the wall when the revolution comes...
Offline 20thCenturyBoy

Senior Member


Medals: 3


So much to learn, so little time.


« Reply #9 - Posted 2004-06-02 11:08:26 »

Quote

General: MT is always difficult. Avoid if you can. In games, you can.

Hurrah! One less thing to worry about  Grin

"I have never done unit testing and I don’t find it a very useful concept" - Jonathan Blow
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #10 - Posted 2004-06-02 11:11:50 »

blah3 , I was with you until you mentioned no wait or notify.  I find that free-running threads that never block are often a problem.  I can only assume that you aren't explicitly using wait, but are relying on blocking I/O operations?

Edit:  never mind  - I'm being brain dead... synchronized of course is another form of blocking that can be effective without wait/notify.

Multi-threading can make some thing much easier in some games though.  Fast Action "twitch" games are usually not as suited though.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #11 - Posted 2004-06-02 11:47:05 »

Quote

Edit:  never mind  - I'm being brain dead... synchronized of course is another form of blocking that can be effective without wait/notify.


Cheesy *I* should have put it like that and made myself less obscure.

Synchronized is either a "crude" form of blocking or a "simplified, higher-level" form - depending upon whom you talk to Wink. Personally, I'm in the latter group, whereas most (all?) of my lecturers were in the former...

Personally I find that for the vast majority of real cases you don't need the extra control offered by wait/notify, and that synchronized blocks achieve all you need. Although at first I found the quite unconvential keyword a bit daunting (partly that was the fault of said lecturers - who badmouthed it a lot) over time I've come to realise it is a truly excellent programming-language feature - a bit of gifted design work by the original architects. If you've done much C multi-threading [1], my guess is that it's like going from malloc to automatic transparent GC - lots of boilerplate code you used to write just disappears, and 99% of the time you don't miss it Smiley

[1] - I haven't done multi-threading in C for many years, and even then not much. I'm sure there are good high-level libs for this by now, but I recall lots of relatively low-level fiddling compared to e.g. synchronized in java...

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 390
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2004-06-02 13:03:30 »

I wish synchronized was extended with a nanosecond timeout and could throw a RuntimeException if it didnt get a lock in time :/

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #13 - Posted 2004-06-02 13:08:58 »

Doing a multi-threaded app is easy, its debugging it thats the hard part. Shocked

[ 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 #14 - Posted 2004-06-02 13:22:33 »

Quote
I wish synchronized was extended with a nanosecond timeout and could throw a RuntimeException if it didnt get a lock in time :/

Cas Smiley


This is what I mean about it being nice and simple but at the cost of a lot of power.

I see where you're coming from on that, and I would definitely move a JDC vote to an RFE for this post-structs Smiley.

But it would be quite a complex change. You'd either have to add an extra code-block to the syntax, as well as the extra args, or else add some new API to the core libraries - and ask for developers to update all legacy code that depends upon code-analysis of the existence/location of the synchronized keyword. (I would guess, going on past examples, that the latter would be enough to cause Sun to refuse it - they seem particularly keen not to upset large users of java with big chunks of legacy code by adding non-forwards-compatible changes).

In fact, I can't see how you could do it sensibly with an API, since java doesn't support closures etc, so you can't embed "the code I want you to run" into a variable to pass to the API; you'd have to do a Runnable-esque approach which IMHO is prohibitively ugly, and only works at a class level.

So...it would need to be a syntax change, something like:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
public void something()
{
  synchronized( this )
  {
    //...do something
 }
  timeout( 10000 )
  {
    System.out.println( "I waited 10000 nanoseconds but couldn't get the lock" );
   }
}


Nice to wish for, but I'd say there isn't a snowball's chance in hell we'd ever get it Wink. Perhaps in whatever language comes next, after Java and C#? Looking at the timeline C - C++ - Java, we're due for another leap forward sometime in the next 1-3 years Grin...although mayble it'll be another skunkworks project most people don't hear about for the first couple of years.

malloc will be first against the wall when the revolution comes...
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #15 - Posted 2004-06-04 14:45:31 »

Quote
I would definitely move a JDC vote to an RFE for this post-structs Smiley.


/me waits for hell to freeze over...

Hellomynameis Charlie Dobbie.
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.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (45 views)
2014-09-23 14:38:19

radar3301 (27 views)
2014-09-21 23:33:17

BurntPizza (63 views)
2014-09-21 02:42:18

BurntPizza (33 views)
2014-09-21 01:30:30

moogie (41 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!