• (cs)

    At the end of each level, in garbled speech: "I'M RAD!!"

  • scared to heck and back (unregistered)

    MEDICAL EQUIPMENT?

    AYIEEEEEE!!!

  • (cs)

    It's gonna take a LOT of threads to keep this patient alive!

  • (cs)
    For those who are not familiar with Java, the Sprite2D class was directly derived from the Runnable class. This means that it has the ability to create its own threads.
    No, it implements the Runnable interface, which means it has a no-argument run() method that is easily plugged into a thread. The Runnable interface does not endow a class with the ability to create threads.
  • (cs) in reply to Erick
    Erick:
    It's gonna take a LOT of threads to keep this patient alive!
    I imagine that memory leaks in this case would be quite a bad thing...
  • (cs)

    Ewch... that's ugly...

    While being on sprites though, does anyone know a decent, presumely non-WTF coded sprite library for java? (yes, there are still uses for java based games today...)

    Also, while the threads thing is obvious, what exactly is wrong with using a delegation-based sprite manager?

  • Luke Dawson (unregistered) in reply to Tukaro
    Tukaro:
    Erick:
    It's gonna take a LOT of threads to keep this patient alive!
    I imagine that memory leaks in this case would be quite a bad thing...

    And the term "blue screen of death" takes on a whole new meaning.

  • (cs) in reply to Erick
    Erick:
    It's gonna take a LOT of threads to keep this patient alive!

    Wouldn't those be "stitches"?

  • Lars (unregistered)
    Alex Papadimoulis:
    Although today we realize that Java wasn't quite the ideal platform for videogames, back in the 90's it was all the rage. If your game wasn't made in Java, it might as well have been with made out of wood and rolled with a stick.
    So well spoken. I think the intense sarcasm of this paragraph pretty much sums up the reasons why I still keep checking his page. Keep it coming, Alex :D :D :D
  • Soro (unregistered)
    For those who are not familiar with Java, the Sprite2D class was directly derived from the Runnable class. This means that it has the ability to create its own threads.

    Bullshit. Those familiar with Java know that

    (a) An interface implementation is not "deriving" a class. It is not inheritance.

    (b) Implementing the 

    Runnable
    interface (which is one single method called run()) does not give the Sprite2D class the ability to create its own threads.

    (c) Implementing 

    Runnable
    allows to execute (not create) instances of a class in a separate thread.

    (d) To create a thread you need - surprise, surprise - the 

    Thread
    class.

    The fuck was apparently not the original author.

  • (cs) in reply to scared to heck and back
    scared to heck and back:
    MEDICAL EQUIPMENT?

    AYIEEEEEE!!!

    I'm writing software for medical equipment. I need to know what Bob's last name is so I can avoid him...

  • (cs)

    Wait wait wait... this "Machine Man" game sounds suspiciously close to another popular game I used to play all the time. A game by the name of Q*Bert.

  • LKM (unregistered)

    50 threads just for Pacman? I think that would be the perfect game engine for the PS3, then. Finally, a game that uses all cores!

  • htg (unregistered)

    I wrote Tetris in Java back in 1998 during a summer internship during university - it took a couple of days, and ran on a 40MHz ARM7 based set top box from Acorn with a JVM that was as optimised as a Fiat Pinto in a Formula 1 race, and it was smooth and worked. I'd only done a few dozen hours of Java programming beforehand (although I was a Blitz Basic 2 whizz, lol). The code was probably quite shite to be honest, but must have looked like gleaming gold in comparison to multithreaded pacman.

    I suspect that many developers enter the complexity-zone between the time they're inexperienced newbies and reasonably good programmers. It seems that many don't escape but some of them somehow get enough money to have their own game company. I can just imagine the thought processes however, vaguely.

  • MikeCD (unregistered)
    the usual horrors of no documentation, a wide variety of magic numbers, and plenty of code duplication
    From what I understand, this is the accepted norm in game programming.
  • (cs)
    As for Bob, the original architect and designer of Machine Man and the game library, he left the games industry a while back and is now writing software for medical equipment.
    ...munching away pills...
  • namezero (unregistered)

    The real WTF here is unfortunately what happens very often in the software industry - using completely inappropriate tools for the job.

    Java is just not the language for an application that is supposed to run at real speed, including games.

    CAPTCHA: smile :)

  • nobody (unregistered)

    I wrote a Pac-Man clone (sort of) on an Apple ][ in FORTH. It ran too fast; I had to slow it down or all the "ghosts" would get you before you could hit a button.

  • (cs)

    I hate to be That "The Real WTF is..." Guy, but TRWTF is using a sprite object to represent each of the pellets in the maze. Assuming that Machine Man was supposed to play similarly to the popular arcade game, the pellets never change position in relation to each other or to the playfield.

  • OSE (unregistered) in reply to MikeCD

    You're not wrong. Let's just say that the guys who develop the interfaces to graphics and sound technology aren't noted for their communication skills, the ability to speak English, or their familiarity with accepted standards of documentation.

    I don't miss writing J2ME.

  • (cs) in reply to namezero
    namezero:
    The real WTF here is unfortunately what happens very often in the software industry - using completely inappropriate tools for the job.

    Java is just not the language for an application that is supposed to run at real speed, including games.

    Troll. I have a server application written in Java (almost entirely by myself) tending to over a thousand socket connections at all times, most of which are active to some degree, and it consumes at most 1% CPU in a single-core single-CPU i386 computer. Even under higher, artificial loads, the VM behaves very well.

    You can code with the VM or against the VM. The original developer was obviously coding against it, whereas the day's savior knew better.

  • dolo54 (unregistered)

    This is what happens when theory takes a priority over reality. Aka... "I want it to follow strict OOP architecture." as opposed to "I want it to work."

  • (cs) in reply to namezero
    namezero:
    The real WTF here is unfortunately what happens very often in the software industry - using completely inappropriate tools for the job.

    Java is just not the language for an application that is supposed to run at real speed, including games.

    CAPTCHA: smile :)

    If you want an easily deployable and simple game, java is a reasonable tool for this job. Pac Man does not require hardcore graphics-card crunching to implement, and a modern PC should be able to handle it easily.

    You probably don't want to be writing Doom in it, though.

  • my name is missing (unregistered)

    I hate to spoil your parade, but Java IS fast enough to write games with today, assuming you have a clue and use an opengl framework like jogl. After all much of the work is done in opengl which is native code. I had friends who wrote an F22 simulator for Lockheed in java based on the real plane systems and it ran with high FPS on cheap linux hardware.

    Of course in 1997 this wasn't possible at all.

    In any case using 50 threads in any language for Pacman is a wtf in any case.

  • my name is missing (unregistered)

    Gag, in any case I needed to edit my comment in any case.

  • Leonel (unregistered)
    The senior development team decided to build themselves their own set of cutting-edge libraries and a framework that would ...

    Now, this is why I love this site. That is just the kind of sentence that makes me shiver and gets my spine cold.

    This is not very different from watching scary movies, after all.

  • Ian Tester (unregistered) in reply to LKM
    LKM:
    50 threads just for Pacman? I think that would be the perfect game engine for the PS3, then. Finally, a game that uses all cores!
    The Cell in the PS3 only has one core. Do not mistake the SPE's for "cores". They're basically just vector co-processors. While they are quite flexible, the SPE's are really only good for processing chunks of data. Think of them being similar to shading units in modern GPU's.
  • Shinobu (unregistered)
    Java wasn't quite the ideal platform for videogames
    And then the article shows that actually the game was just programmed horribly. For the record, I've played a game full of Java code, and even some Python code, a 3D-game no less, that actually runs better and looks better than the usual Quake-derivatives. No gratuitous language bashing please, people might get the impression you're immature.
  • tieTYT (unregistered)

    that was a great article. Thanks

  • Stephen (unregistered)

    The multiple threads idea is very nice in theory, the limitation here is a matter of implementation. I bet that what the hero did was to copy-and-paste code from every thread into the main loop(or methods called from it), then removing the threads. After all, the game logic is designed in such a way as to provide the illusion that everything is happening at the same time, when in fact we know it is not.

    That too is the purpose of threads. With the added benefit that they can scale to multiple cores and the scheduler is (usually) already written. Wouldn't it be nice if we could use threads for every sprite, as the WTF guys did, but with much less overhead?

    Assuming you don't really care about multiprocessors and just want to have a better abstraction, there's the concept of "microthreads". While not "real" threads, they are very convenient :)

    For examples, see Stackless Python, and one major commercial game implemented with it, EVE Online. Every entity(players included) is a thread and they can even be serialized and relocated to other physical servers. Probably hundreds of thousands of "threads", with little overhead.

    So, in my opinion the pacman guys had a nice idea, but a poor implementation. A classic example of using the wrong tool for the job :)

  • (cs) in reply to Stephen
    Stephen:
    The multiple threads idea is very nice in theory, the limitation here is a matter of implementation. I bet that what the hero did was to copy-and-paste code from every thread into the main loop(or methods called from it), then removing the threads. After all, the game logic is designed in such a way as to provide the illusion that everything is happening at the same time, when in fact we know it is not.

    That too is the purpose of threads. With the added benefit that they can scale to multiple cores and the scheduler is (usually) already written. Wouldn't it be nice if we could use threads for every sprite, as the WTF guys did, but with much less overhead?

    Assuming you don't really care about multiprocessors and just want to have a better abstraction, there's the concept of "microthreads". While not "real" threads, they are very convenient :)

    For examples, see Stackless Python, and one major commercial game implemented with it, EVE Online. Every entity(players included) is a thread and they can even be serialized and relocated to other physical servers. Probably hundreds of thousands of "threads", with little overhead.

    So, in my opinion the pacman guys had a nice idea, but a poor implementation. A classic example of using the wrong tool for the job :)

    I tried to paint my house this weekend with a shovel. It did not go so well.

  • dolo54 (unregistered) in reply to Stephen

    I think one thread is plenty to handle 1 pacman and 3 scary ghosts. <quote>Assuming you don't really care about multiprocessors and just want to have a better abstraction...</quote> ummm when and why would you not care about performance and just want better abstraction??? That's the exact type of thinking that leads to http://worsethanfailure.com/Articles/The_Complicator's_Gloves.aspx

  • (cs) in reply to SuperousOxide
    SuperousOxide:
    If you want an easily deployable and simple game, java is a reasonable tool for this job. Pac Man does not require hardcore graphics-card crunching to implement, and a modern PC should be able to handle it easily.

    You probably don't want to be writing Doom in it, though.

    Oh really?

  • Reed (unregistered)

    Typical DBT pattern: Design before Thought.

    Next time, engage your brain before your typing fingers :)

  • (cs) in reply to darin
    darin:
    scared to heck and back:
    MEDICAL EQUIPMENT?

    AYIEEEEEE!!!

    I'm writing software for medical equipment. I need to know what Bob's last name is so I can avoid him...
    Actually, these entries are anonymized, so Bob was actually you all along. Now put down the thread and step away from the x-ray machine...

  • kibagami genjuro (unregistered)

    BAH!

  • Reed (unregistered)

    Anyway, it's not the threads that kill you (a thread is really a rather lightweight object in general), it's the interdependencies and locks.

  • Andrew (unregistered) in reply to Thuktun
    Thuktun:
    For those who are not familiar with Java, the Sprite2D class was directly derived from the Runnable class. This means that it has the ability to create its own threads.
    No, it implements the Runnable interface, which means it has a no-argument run() method that is easily plugged into a thread. The Runnable interface does not endow a class with the ability to create threads.

    Yes, the original article explained the Runnable interface wrong. However, a class that implements Runnable can create its own threads using the java.lang.Thread class.

    Sometimes, a class already extends another class, other than java.lang.Thread. In this case, it implements Runnable, and has a method to create a Thread object from itself.

    class MyClass extends MySuperClass implements Runnable { void run() {} // Have a thread do something... void start() { Thread myThread = new Thread(this); myThread.run(); } }

  • (cs) in reply to dolo54
    dolo54:
    I think one thread is plenty to handle 1 pacman and 3 scary ghosts. <quote>Assuming you don't really care about multiprocessors and just want to have a better abstraction...</quote> ummm when and why would you not care about performance and just want better abstraction??? That's the exact type of thinking that leads to http://worsethanfailure.com/Articles/The_Complicator's_Gloves.aspx

    Oh, he cares, he just doesn't really care.

    More seriously, in most situations, a certain level of performance is good enough - that's the whole point of high-level languages. But you probably knew that, and no one is seriously arguing that Machine Man v1 qualified.

  • someoneorother (unregistered)

    Not, of course, that I'm a great Java fan - but to give credit where credit is due these guys are doing quite impressively to be emulating a whole PC:

    JPC

    OTOH you wouldn't really want to use Java for high performance & low memory embeded system ... even C can't manage it all the time (ie spend 80% of time writing asm code)

  • Sven (unregistered)

    At least this game is ready for when Intel puts that 80-core CPU into production.

    And consider this: this game is probably better at using multi-core machines than Flight Simulator X. :P

    (Yeah, yeah, it probably won't actually work that well because of all the synchronization going on... sheesh, spoil my fun, why don't you)

  • iToad (unregistered)

    This reminds me of Mickey Mouse as The Sorcerer's Apprentice in the old Disney classic Fantasia.

    (The one with the spawning broomsticks with buckets of water).

  • someoneorother (unregistered) in reply to someoneorother

    I should have pointed out that one of the games they're demoing on JPC is pacmania ... surely that qualifies as a WTF - running Pacman on an PC emulated in Java (and I bet they got the threading right).

    BTW can anyone control the damned lemmings in lemmings 1 ?

  • mathew (unregistered)

    Ignoring the out-of-date crap about Java being too slow for games (maybe it was in 1997, but it isn't now, see Jake2, Puzzle Pirates etc)...

    If the sprite framework expected the sprite objects to draw themselves and handle their collision detection, then the real WTF is "WTF is this sprite framework for? What does it get me?"

  • Andrew (unregistered) in reply to Soro
    Soro:
    For those who are not familiar with Java, the Sprite2D class was directly derived from the Runnable class. This means that it has the ability to create its own threads.

    Bullshit. Those familiar with Java know that

    (a) An interface implementation is not "deriving" a class. It is not inheritance.

    (b) Implementing the 

    Runnable
    interface (which is one single method called run()) does not give the Sprite2D class the ability to create its own threads.

    (c) Implementing 

    Runnable
    allows to execute (not create) instances of a class in a separate thread.

    (d) To create a thread you need - surprise, surprise - the 

    Thread
    class.

    The fuck was apparently not the original author.

    Not understanding a concept is a bigger WTF than confusing the terminology. Read this.

    Java Interfaces replace "Multiple Inheritance" in other languages. The most well known is C++; see its I/O Streams library. Two parent classes shouldn't each give the same method to the child, a IS-A relationship for both parents. This is a great C++ compile-time error.

    Runnable and every other Java Interface changes Multiple Inheritance to a HAS-A for the second class. It (java.lang.Thread) is stored a as member field, and its Interface (java.lang.Runnable) is implemented. The other class is extended by the child class.

    Often, a class that implements java.lang.Runnable has a java.lang.Thread inside to actually run the thread.

  • (cs) in reply to Jake Vinson
    ...:
    public class Sprite2D implements Runnable, Cloneable

    For those who are not familiar with Java, the Sprite2D class was directly derived from the Runnable class.

    Does those include the author? Because Runnable is not a class and you can only implement an interface.

    Nice WTF though!

  • infidel (unregistered)

    Wonder who else caught the Samurai Showdown II reference...

  • Jim (unregistered)

    Often, ppl try to make a better engine while they dont achieve to make a descent engine

    I would say first make a descent engine, then make a better engine

  • (cs)

    There are certain antipatterns which are universal, committed by nearly every new Java programmer.

    One of them is trying to do everything with threads.

    I did it when I was first learning Java. Almost everyone does it.

  • (cs) in reply to my name is missing
    my name is missing:
    I hate to spoil your parade, but Java IS fast enough to write games with today, assuming you have a clue and use an opengl framework like jogl. After all much of the work is done in opengl which is native code. I had friends who wrote an F22 simulator for Lockheed in java based on the real plane systems and it ran with high FPS on cheap linux hardware.

    Of course in 1997 this wasn't possible at all.

    In any case using 50 threads in any language for Pacman is a wtf in any case.

    Bump that! I admit, I too write my games in Java and it does not perform slow at all (sophisticated and fast 3D Graphics, fast AI processing in the background etc. is all possible). Of course, back then that was an entirely different topic. :)

Leave a comment on “Sprite Threading”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article