Can Dink be “done right” on iPhone?

A few weeks ago I seriously looked into the possibility of putting our beloved RTsoft freeware RPG on the iPhone in style.

I basically came to the same conclusion as previous times, it’s just Not Worth It.  I might as well work on something new, I can’t use the GPL version with my gaming framework, etc.

I mean, have you SEEN the original Dink source?  It’s hippopotamus butt.  What was I thinking?   I decided not to do it.

But whatever.   I had some free time while I was waiting on another project and figured I’d give it a test-run to see if I could solve the “millions of 8 bit textures on a GL device with power of 2 limitations” issue without any art retouching.

Plus, there is something delicious about the challenge of refactoring 11 year old code.  I can’t believe I just said that, but there it is.

Step 1: Replacing DirectDraw

First I wrote a skimpy software replacement for DirectDraw and dummied out the audio and text stuff.

After it was working right,  I put it on  the iPhone and used glTexSubImage2D to put the final “fake” directdraw surface onto a GL texture every frame.

Got 4 FPS.  Not surprised.  Even updating a tiny GL texture piece seems to be horrible slow, I guess on the iPhone 3G it actually updates the whole surface or something.

Just for fun I tried a technique where you draw a ton of GL_POINTS with color information instead.  Slightly faster for the 640X480 I needed, but for smaller things it’s actually pretty zippy.  I need to remember that if I ever want to do a low-res iPhone game where I need direct screen manipulation.

Step 2: Mixing software and GL surfaces flexibly

So, here comes the next logical step – let’s stop doing everything in software and get with the GL already.  Fine.  But Dink is a memory hog.  Just for the background tile sheets it uses FORTY ONE 400X400 images.  In GL terms, that means 512X512X4X41 bytes, or 41 MB just for some background tiles.  (half that if we go with 16 bit surfaces)

Considering we haven’t even got to the real sprites yet we can see this isn’t going to fly on the iPhone.

Now, we could get funky and write a smart texture atlasing utility and such, but I think there is an easier way.  Plus, I like the idea of using the original media formats, could help with DMOD support later.

The solution?  We’ll keep our fake software DirectDraw around but enable it to create and maintain “shadow GL” textures of themselves when actually blitting to the screen.  We can give hints such as “don’t shadow GL any of the game tiles, just the final background that is built”.

The result? Even after re-enabling text and audio through my Win/iPhone framework I got 2400 FPS on Windows using OpenGL and >50 FPS on the iPhone using GL ES.  I’ve changed my mind, Dink is coming to iPhone!

Real-time scaling to 480X320 looks pretty good. FPS not bad either! Temporary GUI, this will improve.

Step 3: Get Justin on board

Justin Martin, the original Dink artist has agreed to partner up and handle spiffing up the GUI – We’d both love to see an eloquent mobile version of Dink available.

Step 4: The real work

But to do this right, I still need to add some very important features.

The challenging ones will be smooth and legal DMOD support on the iPhone and “save/restore anywhere” functionality.

I’ll also take this opportunity to fix/change a few things that have been bugging me about the original Dink, improve the audio, some balance issues, etc.

Special thanks to Dan Walma (redink) and the Dink Network for letting me use the V1.08 version as a base to start from – it includes some improvements and bugfixes over 1.07.  It’s still total ass though.  (Not their fault, .. mine)