• brian papa (unregistered)

    The real WTF is referencing the game "Rad Dudes" instead of "Bad Dudes."

  • MindChild (unregistered)

    You all are talking about threads and cores and what not. But Java uses "Green Threads", meaning the threads are done by the JVM, not the OS kernel... Translation, your java app is doomed to run on one proc, regardless the thread count.

    See: http://www.jguru.com/faq/view.jsp?EID=143462

  • slamb (unregistered) in reply to dolo54
    dolo54:
    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."

    No, this is what happens when people don't understand the theory they're trying to use. You might find a game very much like this one in the examples of a object-oriented design book, but you won't see anything about each sprite requiring its own threads. Object-oriented programming would suggest the caller be able to simply invoke Sprite.draw() and have the sprite handle the details for its exact type (encapsulation, polymorphism). It doesn't require the sprite to spawn its own thread for drawing.

    I see this a lot...people say "well, if you just follow the theory, you'll end up doing this ridiculous thing". No. The theory works; you just don't understand it.

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

    AYIEEEEEE!!!

    Its possible (at least I hope its possible) that this guy wasn't the one who thought up this little 'architecture' and left out of disgust, hoping to find a team of more capable developers. Remember, you can't blame everyone who worked on a project for crappy code. Some people just get caught in mess.

  • slamb (unregistered) in reply to MindChild
    MindChild:
    You all are talking about threads and cores and what not. But Java uses "Green Threads", meaning the threads are done by the JVM, not the OS kernel... Translation, your java app is doomed to run on one proc, regardless the thread count.

    See: http://www.jguru.com/faq/view.jsp?EID=143462

    That answer was true when it was written seven years ago. I'm not aware of any JVM still using green threads. Sun's Niagara hardware has a ridiculous number of cores, and they're serious about making use of all of them. You need multiple threads or multiple processes to do that.

    Which of course doesn't mean you should throw ridiculous numbers of threads at a problem like this WTF - none of this work is inherently CPU-intensive, all the time's going into context switching and serialization overhead, and they've surely got concurrency bugs because they obviously don't know what they're doing. But if you actually do have something inherently CPU-intensive and easily parallelizable, you'll have to bite the bullet and use threads or people will scream at you for not using their expensive hardware.

  • "Rad Dudes" (unregistered) in reply to brian papa

    Main application: 1 thread 1 animated Machine Man sprite: 2 threads. 4 animated Ghost sprites (blinking when eaten): 16 threads. n (at least 4) animated "Power" dots: n2 threads. m (at least 20) regular dots: m1 thread(s) 1 Bonus Item: 1 thread

    1+2+16+(42)+(201)+1 == 50? I make it 48. maybe it's 50 on an old pentium...

    Captcha: get your own!

  • Mr. Nice Guy (unregistered) in reply to Jim
    Jim:
    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

    Why bother with a "descent" engine when we can just use gravity... :-)

  • (cs) 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.

    Ah, so pedantic and literal. So like a Java developer.

    The fuck is that regardless of technical inaccuracies, you failed to get the point of the story, and read between the lines that, gee, since the class implemented Runnable, chances are they will be MAKING A THREAD WITH IT.

    Laugh with the author. Enjoy the fucking story.

    Sheesh, some people.

  • (cs) in reply to MindChild
    MindChild:
    You all are talking about threads and cores and what not. But Java uses "Green Threads", meaning the threads are done by the JVM, not the OS kernel... Translation, your java app is doomed to run on one proc, regardless the thread count.

    See: http://www.jguru.com/faq/view.jsp?EID=143462

    Yes, but no. The Java Language Specification only says, and I quote:

    Threads may be supported by having many hardware processors, by time-slicing a single hardware processor, or by time-slicing many hardware processors. ... These semantics do not prescribe how a multithreaded program should be executed. Rather, they describe the behaviors that multithreaded programs are allowed to exhibit. Any execution strategy that generates only allowed behaviors is an acceptable execution strategy.
    Green threads would provide little benefit on a SMP or multi-core system (Or on the dreaded Beowulf cluster). Java's specifications are all about providing a guarantee of how the system will behave, not about how the underlying JVM is implemented. Whatever gives the best performance on a given system is the recommended solution, which may, in fact, be kernel threads.
  • (cs) in reply to Mr. Nice Guy
    Mr. Nice Guy:
    Jim:
    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

    Why bother with a "descent" engine when we can just use gravity... :-)

    Isn't Descent a little out of date to use as an engine nowadays, anyway?

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

    I disagree.
  • (cs)

    To all those nerds who says "Java is not for games" ... yey, you guys ever noticed those little devices with tiny antenas and little pushbuttons ? You can speak into it and voices voices are coming out of it... yes, they're mobile phones, yes! And have you nerds ever noticed that people can actually play games on those ? And what do you think, in which language they're written ? Yes, it's J2ME, which is Java.

    Actually, It's a good idea to write you own funny little game in Java for mobile devices, if it's good and fancy enough - it has quite chance to get the attention and then the EA or Sony guys may come and want to buy it.

    And then the game will come to us for porting - undocumented, full of bugs, hardcoded hacks, and we'll have to spread it to bazillion types of the oldest shipwreck handhelds - because people just have them and there are millions of people with Nokia 3510i who just WANT to play the Latest EA game on it's 96x64display.

    So just go for it ! Java is the good language to write games nowadays ;)

  • Kiss me, I'm Polish (unregistered) in reply to operagost
    They were far to slow
    Nobody picked on this one yet. You should have written "too" instead of "to". Haha.

    But seriously: It's maybe not that funny, but I wrote a Breakout clone (I know, I know) in Turbo Pascal (I know, I know) in 1997. It checked if a brick was hit every time the ball moved. Every brick. The whole thing was slower than Eric Clapton's hand. But I was young and didnt't get paid for it.

  • NameNotFoundException (unregistered) in reply to someoneorother
    someoneorother:
    BTW can anyone control the damned lemmings in lemmings 1 ?

    Yes. The mouse support doesn't seem to work. In the start screen you can press F4 and 3 to select the keyboard input. To move the cursor press q/a for up/down and o/p for left/right; space to activate. Bit clumsy.

  • (cs) in reply to htg
    htg:
    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.
    A year or two before that I was also a Blitz Basic 2 whizz and for a java assignment at TAFE wrote a very playable Asteroids clone that looked quite similar to the original.

    It was pretty much the first java code I'd ever written and was so playable it was probably one of the reasons I never got my certificate.

    I found the code on a floppy a couple of years ago and marvelled at how bad it was. Ran great in netscape on a Pentium 100 though.

  • NameNotFoundException (unregistered) in reply to NameNotFoundException
    NameNotFoundException:
    The mouse support doesn't seem to work.

    Followup: Mouse support in JPC basically works if you run ctmouse.exe in A:. There seems to be an issue with the mouse synchronization in the applet, though. It's almost unusable.

  • Asd (unregistered)

    Just to add to the Java is not slow brigade: Jake2 is the Quake2 engine reimplemented in Java. In some cases it actually outperforms the original: http://bytonic.de/html/benchmarks.html (and they haven't tried it with Java 6 yet).

    And to add my voice to countering the FUD above: Java on Linux, Solaris, OSX, Windows etc. uses native threads.

    I have a shitty learn Java in 21 days book which actually uses the thread per sprite antipattern. When I was in University my graphics lecturer though it was great to use about 10 threads. Presumably that is where of lot of this kind of crap comes from

  • anonymous koder (unregistered)

    There are pretty good java games out there, like Lemmings and Prince of Persia.

    Performance is quite good on any average mobile phone.

  • Fuz (unregistered) in reply to MikeCD

    You understand incorrectly. You may get the odd magic number here any there, but they're never accepted. They are in fact the bane of many a games programmer's existence.

    Duplicated code is, however, sometimes a necessary evil. Usually if the compiler refuses to inline a particularly important function or if a generic algorithm just isn't as fast as a specialised one. However, such a decision should only be made after extensive profiling tells you that it's necessary, and only with the knowledge and approval of the lead programmer.

    And just to throw some fuel on the flamewar, I'd say that any game written in a language based around garbage collection is just asking for trouble. :-)

    Every game I've worked on (and I'm talking about console games here, which have to run in a fixed memory architecture, not on a PC with 'infinite' memory) pre-allocated all of its memory up-front to avoid problems with potential allocation failure due to fragmentation and degraded allocation performance over time, and we're talking about GC-less C/C++ here. Of course, you could always periodically compact (if that's even possible with your particular language implementation), but that's also an extra unnecessary performance drain.

    Java is completely heap-orientated; there's no way to avoid it. And that's just inappropriate for any game that's trying to take full advantage of a particular platform.

  • (cs) in reply to MindChild
    MindChild:
    You all are talking about threads and cores and what not. But Java uses "Green Threads", meaning the threads are done by the JVM, not the OS kernel... Translation, your java app is doomed to run on one proc, regardless the thread count.

    See: http://www.jguru.com/faq/view.jsp?EID=143462

    1. The JVM used to use green threads (that sucked), it hasn't for a long time
    2. Non-OS threads/processes don't necessarily suck, and don't mean your app is doomed to run on a single core: Erlang is based around the concept of Erlang processes which run inside the Erlang VM (they're not OS processes), but since R11B the Erlang runtime dynamically maps the Erlang processes to OS threads (and takes in account the number of cores of the system).
    AstorLights:
    To all those nerds who says "Java is not for games" ... yey, you guys ever noticed those little devices with tiny antenas and little pushbuttons ? You can speak into it and voices voices are coming out of it... yes, they're mobile phones, yes! And have you nerds ever noticed that people can actually play games on those ? And what do you think, in which language they're written ? Yes, it's J2ME, which is Java.
    Isn't that the main reason why mobile phone games suck donkey balls?
  • Fuz (unregistered) in reply to Fuz

    Argh, that was in response to MikeCD who said that magic numbers and code duplication was pretty much the accepted norm in games programming.

  • Anonymous Tart (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.

    (A lot of) Java developers live in their own little world. Implementing an interface in Java is not called inheritance for one reason - it was decided Java developers couldnt handle the responsibility of using multiple inheritance correctly, so they made it a fudge. Its still inheritance, but not as you know it.

    To utilise the Runnable interface requires a third party class to use the interface. This class is always Thread or a subclass thereof. This is effectively multiple inheritance through aggregation. The intent is clear to anyone with half a mind.

  • jdj (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.
    Huh? No, that does not mean that it "has the ability to create its own threads". It just means that it has a run() method which can be used as the main method for a separate thread.
  • (cs) in reply to Reed
    Reed:
    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.
    IIRC the default thread stack size is 256KB. Not exactly what I'd call "lightweight"...
  • Daiko Katana (unregistered) in reply to SuperousOxide

    Actually, when you know Java and know how to program Java, it's not that hard to create decent graphics in it.

    DK has released a Java conversion of Quake 2 a year ago, and there are several other projects working on similar conversions.

    Our group is writing a Java RPG at the moment, similar to Morrowind.

    Java has come a long way since the applet days :)

  • woohoo (unregistered) in reply to Anonymous Tart
    Anonymous Tart:
    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.

    (A lot of) Java developers live in their own little world. Implementing an interface in Java is not called inheritance for one reason - it was decided Java developers couldnt handle the responsibility of using multiple inheritance correctly, so they made it a fudge. Its still inheritance, but not as you know it.

    To utilise the Runnable interface requires a third party class to use the interface. This class is always Thread or a subclass thereof. This is effectively multiple inheritance through aggregation. The intent is clear to anyone with half a mind.

    some people might misunderstand your statment - using interfaces that way is not multiple inheritance in the sense of additive and transitive type inheritance. it is replacing (multiple) inheritance by composition/delegation.

  • woohoo (unregistered) in reply to iToad
    iToad:
    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).

    which is based on "Der Zauberlehrling" by J.W.von Goethe (1797) who based his ballad on a story written by the ancient writer Lucian ;o)

    see http://en.wikipedia.org/wiki/Der_Zauberlehrling

  • (cs) in reply to Reed
    Reed:
    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.
    Who let an NRA member onto this site? You're using exactly the same fractured logic here.

    "Threads don't kill performance. Performance kills performance."

    Doh ...

    Anyway, there's no conceivable reason to overcomplicate this game design with threading. Message-based systems, anyone? And Java's threading model is, hem hem, a little clunky. (To be fair, designing a threading model for a cross-platform language is quite a big ask.) See Allen Holub's book on the subject, if you reall do want to go down this particular path of broken glass on your hands and knees.

  • NameNotFoundException (unregistered) in reply to woohoo
    woohoo:
    iToad:
    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).

    which is based on "Der Zauberlehrling" by J.W.von Goethe (1797) who based his ballad on a story written by the ancient writer Lucian ;o)

    see http://en.wikipedia.org/wiki/Der_Zauberlehrling

    class LuciansPhilopseudes implements Runnable {
  public void run() {
    // do all the work
    // ...
  }
}

class GoethesZauberlehrling extends LuciansPhilopseudes {
  public Credit gainCredit() {
    return new Credit();
  }
}

/** Copyright Di**ey Corporation */
class TheSorcerersApprentice extends GoethesZauberlehrling {
  public long makeMoney() {
    return Long.MAX_VALUE;
  }
  public void extendCopyright() {
    // extensive lobby work here
    // ...
  }
}

    clear now?

  • (cs)

    ... and nobody seems to have picked up on The Real WTF (TM):

    We'd like to run a contest where people can compete with each other and send in their high-scores. Some players will have the current version, others will have the new version
    I'm sure that this is an admirably egalitarian aim. However, aside from the fact that, as Holub points out, the implementation of the Java threading model on different architectures immediately introduces massive performance discrepancies (and again, not Java's fault), I can just see the CEO's reaction to a new, slower piece of hardware coming out. (Electronic toaster, that sort of thing.) "Holy White Sox, Batprogrammer, we have to take all those Magic Numbers and multiply them by another huge, even more Magical Number to slow the game down!"

    I mean, really. Periodically on this site you see jokey comments to the effect that "I want to know who this guy is so that I can avoid working with him." Or "I want to know who the company is so that I can make money off them." Me? I'd far rather be given the names of the insane wealthy individuals who actually funded this horror. I have so much that they'd be interested in: a couple of bridges, an oil-field or two, a flying elephant ... I can even arrange phone conversations with Elvis, for the right amount of money.

  • ZzzKABOOM (unregistered) in reply to MindChild
    MindChild:
    You all are talking about threads and cores and what not. But Java uses "Green Threads", meaning the threads are done by the JVM, not the OS kernel... Translation, your java app is doomed to run on one proc, regardless the thread count.

    See: http://www.jguru.com/faq/view.jsp?EID=143462

    For one thing, as others have pointed out, this is no longer true of most Java runtime implementations.

    Another thing is that non-OS threads can potentially be extremely lightweight (as in multiple orders of magnitude). This enables the use of concurrency as a programming abstraction, rather than a means of achieving parallelism, which makes a solution of one-thread-per-UI-element a good approach. While most mainstream programming languages require (or are in practice implemented with) runtimes that don't make it possible for threads to be extremely lightweight, there are languages (Erlang, Oz, Concurrent ML, Alice) that do provide such threads.

  • Not A Robot (unregistered)

    Nah, you're all wrong!

    The real WTF here is not that the library code was crap (although it was), but that the developer failed to elicit or understand the client's true requirements (the client being management).

    The client wanted a game that ran just like the old game, but on multiple platforms. They had a good reason for retaining the crap performance.

    The developer gave them a game that ran far better than the old game, and on multiple platforms. Not what the client wanted at all.

    When will these developers learn !

  • Marcin (unregistered)

    I think there's a consensus emerging here about the real WTF - they should have used erlang.

  • woohoo (unregistered) in reply to Andrew
    Andrew:
    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.

    yes and no. interfaces do not replace multiple inheritance, only in the sense that they preserve the "is a" relationship. they do enforce "programming by contract", i.a. a publicly visible API for it's implementing class, but (opposed to "real" multiple inheritance) you can't declare state (fields) in an interface. that is, it is not necessarily so that interfaces always change an "is a" into a "has a" relationship. an interface (as type) can of course be used when using the concept of "replacing (multiple) inheritance with composition (or delegation)", but this holds true for any class as well.

  • foo (unregistered) in reply to MikeCD
    MikeCD:
    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.

    Game programmers only care if the output of the program looks nice. They don't care about the code itself.

  • an anonymous ex-game programmer (unregistered)

    i swear i worked with "bob" in the early 90's.

  • Diego (unregistered) in reply to dolo54
    dolo54:
    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."

    no. this is what happens when a code monkey WITHOUT THEORY wants to use all tools he/she can reach.

    doing a pacman game using "strict OOP architecture" does not force anyone to use one thread for sprite or one sprite for a dot.

    classes and objects are merely conceptual. in the Pacman case, we can use most of them as façades. you have to read the right books

  • Diego (unregistered) in reply to woohoo
    woohoo:
    Andrew:
    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.

    yes and no. interfaces do not replace multiple inheritance, only in the sense that they preserve the "is a" relationship. they do enforce "programming by contract", i.a. a publicly visible API for it's implementing class, but (opposed to "real" multiple inheritance) you can't declare state (fields) in an interface. that is, it is not necessarily so that interfaces always change an "is a" into a "has a" relationship. an interface (as type) can of course be used when using the concept of "replacing (multiple) inheritance with composition (or delegation)", but this holds true for any class as well.

    no. only true mixins DO enforce programming by contract. Java do not have that

    Java got a good rank in the market, but it is SLOW and full of idiosyncrasies

    captcha: stinky (a java programmer)

  • Alonzo Meatman (unregistered)

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

    In MUMPS, perhaps?

  • Reed (unregistered) in reply to real_aardvark
    real_aardvark:
    Reed:
    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.
    Who let an NRA member onto this site? You're using exactly the same fractured logic here.

    "Threads don't kill performance. Performance kills performance."

    Huh? Did you read the second half of my sentence?

  • - (unregistered)

    It's programmers like that who give Java a bad name. Java is not slow. It's often the developers who are "slow" ;-)

    Captcha: RIAA?? WTF??

  • dolo54 (unregistered) in reply to slamb

    yes you've said it better. I've run into too many situations where people say they want to follow strict OOP architecture and end up making a complete spaghetti monster due to their lack of understanding. I actually don't knock the theory, just the poor application of it. For instance abstraction just for the sake of abstraction. People have a tendency to follow the latest buzzwords instead of using a proper tool for a job.

  • (cs) in reply to Reed
    Reed:
    real_aardvark:
    Reed:
    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.
    Who let an NRA member onto this site? You're using exactly the same fractured logic here.

    "Threads don't kill performance. Performance kills performance."

    Huh? Did you read the second half of my sentence?

    Double-huh ... didn't it occur to you that the second half of your sentence is exactly what prompted my analogy?

    I'll expand. Let's assume a gun-nut says "Guns don't kill people. People kill people. This happens when they take a perfectly fine machine, point it in the wrong direction, don't think, and pull the trigger."

    (I'm not saying you believe that, by the way.)

    People generally, and I think legitimately, shorten this to "Guns don't kill people. People kill people."

    In like manner, your (perfectly fine) defence of threads can be viewed as a little optimistic. In the real world, threads pretty much always come with interdependencies and locks -- as you say. Consequently, careless and inappropriate use of threading kills performance: just as careless and inappropriate use of guns kills, um, people. The OP is a perfect example of this.

    Sorry if the analogy was offensive rather than jocular to you ...

  • Anonymous Tart (unregistered) in reply to woohoo
    woohoo:
    Anonymous Tart:
    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.

    (A lot of) Java developers live in their own little world. Implementing an interface in Java is not called inheritance for one reason - it was decided Java developers couldnt handle the responsibility of using multiple inheritance correctly, so they made it a fudge. Its still inheritance, but not as you know it.

    To utilise the Runnable interface requires a third party class to use the interface. This class is always Thread or a subclass thereof. This is effectively multiple inheritance through aggregation. The intent is clear to anyone with half a mind.

    some people might misunderstand your statment - using interfaces that way is not multiple inheritance in the sense of additive and transitive type inheritance. it is replacing (multiple) inheritance by composition/delegation.

    Yep. And ++i and i = 1 + i arent the same thing either, but they achieve the same goal. Mindnumbing pedantry on here today.

  • woohoo (unregistered) in reply to Anonymous Tart
    Anonymous Tart:
    woohoo:
    Anonymous Tart:
    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.

    (A lot of) Java developers live in their own little world. Implementing an interface in Java is not called inheritance for one reason - it was decided Java developers couldnt handle the responsibility of using multiple inheritance correctly, so they made it a fudge. Its still inheritance, but not as you know it.

    To utilise the Runnable interface requires a third party class to use the interface. This class is always Thread or a subclass thereof. This is effectively multiple inheritance through aggregation. The intent is clear to anyone with half a mind.

    some people might misunderstand your statment - using interfaces that way is not multiple inheritance in the sense of additive and transitive type inheritance. it is replacing (multiple) inheritance by composition/delegation.

    Yep. And ++i and i = 1 + i arent the same thing either, but they achieve the same goal. Mindnumbing pedantry on here today.

    q.e.d. ;o) you do know how many problems arise by using slack (i.e. unpedantic) nomenclature? pedantry and preciseness are not the same...

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

    Wouldn't those be "stitches"?

    Actually, if you want to get technical over this rather brillant (IMHO) joke, it would be "sutures". Stitches are for fabric. Sutures are for flesh.

  • My Name (unregistered) in reply to Soro

    My understanding of an interface in Java is that it is analogous to inheritance from abstract base classes in C++. Maybe it's not taught that way anymore, but I'm still not seeing how it isn't a form of inheritance. Sure, you're not deriving something, but it certainly has characteristics of inheritance.

  • (cs) in reply to mathew
    mathew:
    Every game I've worked on (and I'm talking about console games here, which have to run in a fixed memory architecture, not on a PC with 'infinite' memory) pre-allocated all of its memory up-front to avoid problems with potential allocation failure due to fragmentation and degraded allocation performance over time, and we're talking about GC-less C/C++ here. Of course, you could always periodically compact (if that's even possible with your particular language implementation), but that's also an extra unnecessary performance drain.

    Java is completely heap-orientated; there's no way to avoid it. And that's just inappropriate for any game that's trying to take full advantage of a particular platform.

    There is no way you'll bring your cars to any decent performance with gasoline. The cars I worked on (and I'm talking about planes here) required huge loads of kerosene fuel to be even useable....

  • Some Random Arcade Bum (unregistered) in reply to brian papa
    brian papa:
    The real WTF is referencing the game "Rad Dudes" instead of "Bad Dudes."

    You call this out, in an article that repeatedly refers to "Pac Man" as "Machine Man"? I would have thought that it goes without saying:

    This is WTF. ALL NAMES get changed in these stories to protect the innocently F'ed.

    (And I'm not one to blindly follow the fad, but I do find it amusing that the word "digdug" is important for me in making this post as an anon user.)

  • Another Pedantic Nerd (unregistered)

    Come, come, people, everyone has so far overlooked the most egregious error yet: "Machine Man" was not a "game from the 70's." It was from the 80's.

    I feel better now.

Leave a comment on “Sprite Threading”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article