Slashdot Mirror

← Back to Stories (view on slashdot.org)

John Carmack's Cell Phone Adventures

Posted by Zonk on from the poking-tiny-space-marines dept.

Mr. Carmack has updated his blog with news of his latest interests. Apparently mobile gaming on cell phones has consumed a large portion of his time of late, and he has some witty commentary on programming for the emerging game platform. From the article: "I'm not a cell phone guy. I resisted getting one at all for years, and even now I rarely carry it. To a first approximation, I don't really like talking to most people, so I don't go out of my way to enable people to call me. However, a little while ago I misplaced the old phone I usually take to Armadillo, and my wife picked up a more modern one for me. It had a nice color screen and a bunch of bad java game demos on it. The bad java games did it."

14 of 109 comments (clear)

  1. Time consuming by kryogen1x · · Score: 4, Funny
    Apparently mobile gaming on cell phones has consumed a large portion of his time of late

    No kidding. When I play chess against the AI on my phone, the thing takes minutes to make a move. It usually takes 20 minutes to play a game that would take two humans to play in 5.

  2. 'I don't really like talking to most people' by arcanumas · · Score: 5, Insightful
    I don't really like talking to most people

    A true geek :)

    --
    Slashdot Sig. version 0.1alpha. Use at your own risk.
  3. Yes, but.. by Anonymous Coward · · Score: 5, Funny

    ..how long will it take him to color the entire screen black and call it Doom 3 for mobiles?

  4. That's gonna give the Java fanbois an aneurysm by Anonymous Coward · · Score: 5, Interesting

    The biggest problem is that Java is really slow. On a pure cpu / memory / display / communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advanced. With Java, on most phones you are left with about the CPU power of an original 4.77 mhz IBM PC, and lousy control over everything.

    Heh - that should put the "Java is just as fast as native code" myth to rest. It won't, as people will claim that Just In Time compilation should solve it, but...

    Even compiled to completely native code, Java semantic requirements like range checking on every array access hobble it. One of the phones (Motorola i730) has an option that does some load time compiling to improve performance, which does help a lot, but you have no idea what it is doing, and innocuous code changes can cause the compilable heuristic to fail.

    Which ends that myth too.

    Write-once-run-anywhere. Ha. Hahahahaha. We are only testing on four platforms right now, and not a single pair has the exact same quirks.

    And there goes that Java myth, too...

    Cell phones already have a very low latency digital data path - the circuit switched channel used for voice.

    Actually - he's wrong. That channel has a good half-second or so latency. Try this - call up your home phone, and pick both up. Don't worry about feedback - there's way too much latency. Talk into your cellphone and listen to it "echo" on your phone. Or call up your friend on their cellphone and talk to each other, and listen to the good second between when they say something and you hear it.

    It turns out that this latency isn't enough to prevent you from having a conversation, but there is quite a bit of latency on the voice connection of a cell phone.

    1. Re:That's gonna give the Java fanbois an aneurysm by dtfinch · · Score: 4, Insightful

      4mhz was good enough for the super nintendo.

    2. Re:That's gonna give the Java fanbois an aneurysm by jilles · · Score: 5, Insightful

      Not yet. The problem with j2me is that there are so many implementations (and some of them really suck) of it. Some have JIT, some don't. There are a lot of hardware/software combinations. And that makes testing really hard. Of course you have the same problem if you move to another language. Because of that, there is not a lot to choose from. Brew and J2ME are basically it. Brew is optimized for gaming and J2ME targets a wider variety of software applications. Brew is a traditional, proprietary solution whereas J2ME is much more open with free development kits, documentation, etc. As Carmack notes, it is much easier to get started with it.

      An additional problem is that the core J2ME specs don't cover much functionality. All the interesting stuff is in optional modules which may or may not be implemented on a J2ME phone. There's a whole range of J2ME specifications that may or may not be implemented.

      John Carmack reasons very simple from a game developer point of view. Basically anything that gets in the way of direct access to the hardware annoys him. This way of thinking about writing software is not really suitable for mobile development. The problem with writing software for mobile phones (and pdas) is that you need to target as much phones as possible because typically a phone will only be on the market for a short period of time (a few months) and there are a lot of different phones. So if you want marketshare, forget about native C, direct on hardware type solutions. You need to abstract from as much hardware (cpu, memory, screen size, network, storage, input) and software details (which j2me specs, native os, jit or no jit) as possible. That's what J2ME is all about.

      --

      Jilles
    3. Re:That's gonna give the Java fanbois an aneurysm by John+Carmack · · Score: 4, Informative

      I did try running that benchmark, but it won't load on the i730 (score one more for run-anywhere...).

      One of our test platforms is a fairly high end Sony Ericsson, which is 10x as fast as our Motorola base platform. For a 128x128 screen, the Motorola renders about 4 fps and the Sony renders about 40 fps. Compare with Wolfenstein-3D performance (the DoomRPG engine has some extra graphics features, but it is still in that general class) at that resolution on older systems. A 386-16 would go significantly faster.

      Note that the "As fast as a ..." comparisons from the benchmark are against purely interpreted java on the P3, which is about 1/10th the speed of a native implementation, and benchmarks that focus on expression and control operations will overestimate relative performance for applications that are array access heavy. Still, if a java app on that phone performed like a P3-100mhz, it would be pretty impressive.

      It is true that a good JIT (which the phones don't have) can make java code go nearly as fast as C/C++ code that is written in the same style. The "in the same style" part is often overlooked -- in lower level languages you often have options for implementation with pointers and CPU tailoring that would make the code look very different, but go significantly faster.

      I still generally like java, and maximizing performance is only important in a rather limited subset of software engineering.

      John Carmack

  5. Laugh if you want... by dhakbar · · Score: 5, Interesting

    ... but mobile phone gaming is an IMMENSE market. The key is in the subscription model. People will download a game and subscribe, play it once or twice, and forget about it. They never cancel, so they continue to pay $3/month for the game.

    I worked on a few cell phone games for SOE when I was working there, and all I have to say is that the sales figures make me want to be a cell phone gaming tycoon. It's not a pipe dream.

    1. Re:Laugh if you want... by Hast · · Score: 5, Insightful

      I remember a time when scamming your customers wasn't a common business strategy.

      Actually I don't, but wouldn't it be nice if people tried to do things in order to make a good job instead of just ripping people off? Ah well, I can always dream I guess.

    2. Re:Laugh if you want... by jbolden · · Score: 4, Insightful

      It was the case 15 years ago. Back then decent business wouldn't do business with companies that ripped off their customers. So the game companies that did this couldn't get near a Verizon or a Sprint, now Verizon and Sprint are both part of the scams. The media would have crucified Verizon or Sprint for letting this stuff go on, now the media is owned by the same guys. People would have refused to do business with companies that lack ethics, now they all lack ethics.

      I really wish they would dig Harry Truman up and make him president again. I'm tired of living in a 3rd world corruptocracy.

  6. It's outsourced. by AtariAmarok · · Score: 5, Funny

    They were too cheap to complete a chess program with good AI. You are not waiting for a slow computer. You are instead waiting for a rather frazzled guy in Mumbai whose job it is to play the computer opponent in anywhere from 10 to 50 phone chess games at any given time.

    --
    Don't blame Durga. I voted for Centauri.
    1. Re:It's outsourced. by dougmc · · Score: 5, Interesting
      You are not waiting for a slow computer. You are instead waiting for a rather frazzled guy in Mumbai whose job it is to play the computer opponent in anywhere from 10 to 50 phone chess games at any given time
      I know you're joking, but you could very well be giving the future of cell phone chess games too.

      Cell phone cpus are slow, and suck up the battery while they're working. But an entire chess board layout is very simple, and it wouldn't take much bandwidth to transmit your entire chess board layout to a remote computer which could then calculate the next move and transmit it back. (And that's assuming that the remote computer keeps no state information. If it kept track of the chess board itself, the bandwidth needed per move would just be a few bytes.)

      I could see a cell phone company buying Deep Blue or some similar big honking box and reprogramming it to play lots of games at once. Then release a chess application for cell phones that uses the data capability to allow you to play chess `against Deep Blue.'

      Sure, Deep Blue would not be playing 1000 simultaneous world-class chess games (though for an extra fee, you could get more cpu dedicated to you giving you a better opponnent), but it could probably beat most people. (The only reason to use Deep Blue itself is for the name recognition. A number of racks of PCs would work too, but it wouldn't have the obvious marketing potential.)

      This is one case where having a remote server do most of the work makes perfect sense. (Having a PC play chess with a remote server doing the work makes less sense, as a PC has much more cpu to work with, so it's not as needed.)

  7. Apples and Oranges by Dr.+Bent · · Score: 5, Insightful

    The Java platform that runs on most cell phones is J2ME, which is a completely different animal than J2SE, the one that's used on PCs.

    The differences are substantial. For example, some J2ME VM's don't garbage collect. Ever. That's because in some cases, it's not required.

    To say that the J2SE (or J2EE) plaforms suck because a particular J2ME implementation is slow is like saying that internal combustion engines suck because your go-kart can only go 15 mph.

  8. The best part is... by BW_Nuprin · · Score: 4, Insightful

    ...Carmack is way over-estimating performance of most phones. Only the highest-end Java phones support 200k jar sizes. The majority of consumer phones are limited to 64k - even many brand new phones have this limitation. On the other hand, he's not being 100% fair with his GBA comparison. Gameboy, GBC, and Gameboy Advance all have tile-based rendering that is easily capable of 60fps, while Java-based (and BREW-based) cell phones have only linear frame buffers that you don't get direct access to (usually). To aggravate things, many Samsung BREW phones have 250ms response rates.

    Carmack will also be disappointed when he begins experimenting with BREW. BREW doesn't support threading, globals, or even static variables. I'm not even going to get started on the bizarre latencies of the API.

    One of my jobs as a cellphone developer is to port Java games to BREW. Carmack's comments about how fast Java phones play like 4.77MHz IBMs is true, but the same is true for BREW phones as well. I've only managed to squeeze another 10% out of the performance on similar BREW phones. There are a lot of things limiting cellphone performance, but Java isn't one of the main culprits. Bad platform design and slow hardware are what kills it.