Porting Lemmings In 36 Hours

An anonymous reader writes "Aaron Ardiri challenged himself to port his classic PalmOS version of Lemmings to the iPhone, Palm Pre, Mac, and Windows. The porting was done using his own dev environment, which creates native C versions of the game. He liveblogged the whole thing, and finished after only 36 hours with an iPhone version and a Palm Pre version awaiting submission, and free versions for Windows and Mac available on his site."

Copyright?

[PyroMosh]

Okay, so Lemmings isn't public domain. The owners may have turned a blind eye to DHTML Lemmings, and other small projects, but how do you expect to get approved for the Palm and Apple App Stores?

IIRC Psygnosis owns the rights to Lemmings. Also IIRC, Psygnosis is now owned by Sony. Unless Psygnosis was only the publisher for a third party I'm not aware of.

Good luck with that.

Re:iPhone bandwagon

[Anonymous Coward]

I had a bad habit of bragging about my N900 -- WVGA screen, CortexA8 overclocked to 1.1GHz, and a touch-optimized Firefox derivative, it can do anything a laptop can do.

The above link has cured me.

(On second thought... does anyone's laptop actually handle that monster gracefully, either?)

Re:Android please?

[lightversusdark]

After another 36 hours spent wrestling the Android audio APIs he will admit defeat.

The Game that Made DMA Design

[snap2grid]

One of my claims to fame is that I was working for DMA Design when they created the original Lemmings (Dundee, Scotland), released on Valentine's day 1992. I did some conversions of the Amiga graphics to the PC (EGA!) and Atari Lynx. In the victory screen, there's a pic of the developers including myself! Needless to say, a lot of what is written on the net isn't quite correct. Great to see that it's still well thought of and in fact it's even part of a museum exhibit in Dundee (McManus Galleries) (You *really* know you're old when your photo is in a museum!) You can find the history of Lemmings (and DMA) here. http://www.dmadesign.org/ [dmadesign.org] and some of my musings from that time here http://www.stevehammond.org/ [stevehammond.org]

Looking forward to the Android port

[Spacelem]

It would be great if I could play my favourite game on my phone!

I am older, I remember why C is called C

[SmallFurryCreature]

You know you are old when B is more then just a brief bit of history in the front of a C book.

To be fair I only knew it from a porting project. I am not THAT old... I am young enough to remember when C was new and exciting... no we did NOT ride dinosaurs to work.

Re:Nice accomplishment!

[GigaplexNZ]

Since when does C++ needs to be converted to C?

Since it started - it was just a preprocessor. It's now changed though to compile directly. You could in theory write a compiler that goes straight from Java to machine code if you were really keen. In fact, that has already been done [gnu.org]. It's not just the language syntax, the toolchain matters too.

Re:Nice accomplishment!

[robthebloke]

- you don't know what code the compiler will emit, especially if you're optimizing. Given the bajillion optimization flags most compilers have, and the fact that they change across versions (for example gcc 4.4 has the graphite framework, gcc 4.5 has link-time optimization), you're either very smart and brave to take a guess, or just ignorant. You can look at the output of course, but that's hardly "predicting", and we're lazy anyway.

Yes, but the more output you inspect, the more you get to know your compiler, and thus predicting the output becomes easier. (Actually you don't need to predict the output for 99.99% of cases, you only need to worry about C/C++ constructs that will cause performance problems. Once you've identified those sorts of bottlenecks [via a profiler of course!], avoiding them in future is fairly easy). I'm not sure about you, but personally I don't go and blindly enable every single new optimization flag with every time I get a new version of a compiler! I think the fact they change is largely moot to be honest

- you don't know the state of RAM, with regards to swap
- you don't know the state of the CPU cache
- you don't know what microcode the CPU has, or what it's actually doing under the hood

A touch pedantic imho (and not entirely accurate). Those are specific to programming on a modern CPU/modern OS, and apply to any language. If you want to know all of those things, don't use a modern CPU or os....

- at any given point in time, you don't know how long it will take to execute the next instruction (hint: scheduling, possibly powersave)

What does scheduling have to do with an instruction timing? It sounds like you are working on the assumption that a thread can be suspended mid-op? Anyhow, if an instruction executes, it executes in 'n' cycles, with a latency of 'p' and a throughput of 't'. Those are known values for all CPU's. If the CPU has been throttled back via speedstep, then it still takes 'n' cycles, with a latency of 'p' and the throughput remains the same. The only thing that changes is the time for a cycle, but do you really want to be measuring your code performance in seconds? Fine for us console developers i guess, but not so great for your average PC.

Also worth pointing out, that there is always a counter-example. If you want to measure your code in terms of ops, get an ATOM ;)

Re:Android please?

[lightversusdark]

Flamebait? Sheer fanboyism! Android bug 3434 [google.com] is a showstopper.
Audio is critical for telephony and the media functionality expected of a smart phone, and Android's basis in Linux is only highlighting the sorry state of Linux audio.
Hopefully this may spur Google to develop something along the lines of CoreAudio that could be used in Linux as well as just Android and rid us of the ALSA, Jack, OSS, etc. mess that represents the worst of Linux.

Re:Nice accomplishment!

[wood_dude]

With a good macro assembler you can quite easily create your own higher level language. I've done that several times. Porting a game in the old 8/16 bit days from 6502/6809/z80/68000 was just a set of assembler macros for each low level operation of your game creation langauge. Only a few specific time critical bits of code ever ended up in true native, mainly the blit code. Porting games even in assembler was quite quick, you just had to start out with the correct technique. All thoses guys that wrote piles and piles of hand crafted native assembler without useing the macros we're just crazy.