ZodTTD: Home Of Homebrew

As you may know I ported the open source project OpenTTD, based on Transport Tycoon Deluxe by Chris Sawyer, to Apple’s iPhone & iPod Touch then to the iPad. Both versions were placed on App Store. Both of them we’re pulled by request of Rubidium of the OpenTTD team. The latest blow, the removal of OpenTTD for iPad hurt the most. It was very fun, and was doing very well – Top 20 of all iPad games! I even had a short $500/day ad campaign pre-paid to AdMob to help support it’s movement up the rankings, made right before it was pulled.

Why was it pulled though? Simple answer is “no good reason”. Both were released for free. OpenTTD is GPL licensed, and I have the entire source code for the project place in my public GitHub source repository which I linked to within the iTunes product page to comply. I also made sure to place the license in the splash screen of the game to comply. The product page has a contact link, but I was never contacted before the two pull requests. Instead I found out by Apple that Rubidium had made the request. Odd thing is I was in their IRC channel (internet chat) the entire time and was never spoken to there either.

When OpenTTD for iPad was pulled, I contacted Rubidium again. He expressed his concerns about a lack of license and source, as to which I pointed him to both. I was very surprised by the negativity I was receiving by the OpenTTD team. I was trying very hard to comply with their requests, and being as polite as possible. When I finally asked Rubidium whether he has any intent to let Apple know they should stop the pull request, even if it means I must do some odd unrequired tasks they requested, he wouldn’t reply.

All in all it’s been very much an uphill battle to place this open source project up on Apple’s App Store even though it’s free and in compliance. Let it be known they have no intention to bring OpenTTD officially to App Store, as they have expressed that to me when explaining they lost their Mac OS X developer. When I spoke up and explained that I can bring my iPhoneOS version of OpenTTD to Mac OS X with ease they expressed no interest.

I love OpenTTD. I love Apple products. I want to see OpenTTD on the iPhone, iPod Touch, iPad, and Mac OS X.

So what will it take? Simply having Rubidium write to Apple to let them know this issue has been resolved and I can continue to update and release OpenTTD on the App Store.

How can you help? Easy!

Send the OpenTTD Team a donation of any amount directly via my ChipIn campaign here: http://openttd.chipin.com/openttd-for-ipad-and-iphone

No matter what the amount, whether $1 or $100, by sending a donation via my campaign it will signal to them very quickly that we want OpenTTD by way of a note and your full donation to their PayPal.

Can’t donate? S’ok! Please sign the petition here: http://www.petitiononline.com/ttd4all/petition.html

I made the first donation of a large $100 to start things off. I hope the OpenTTD team sees just how much we want their support, and how far we’ll go to see this project maintain their openness to new platforms.

Thanks so much,

ZodTTD

Hello all,

I missed you! Yes, it really has been over four months since we last spoke. But I’m back and ready to go!

So what have I been doing these past few months? Truthfully I’ve been trying to get outside more and enjoy the world. I spent nearly two years straight programming all day and night. It really ruined my social life. I took the time to find balance in my life. I didn’t post here for so long in hopes things calmed down. People were posting very nasty things, and I just couldn’t handle it at the time.

No worries though, as I have been working hard, in spurts, on many projects for not only the iPhone & iPod Touch, but the iPad as well! I made sure to fund comex with an iPad so he could work on the iPad jailbreak. I also have been keeping close tabs on geohot’s work. The good news is, we’re just in a waiting state. The jailbreaks are prepped to go. So whether it’s 3.1.3 on the iPod Touch 3rd Gen, 3.2 on the iPad, or 4.0 on the iPhone…it’s prepped.

This all has me very excited to bring my emulators on to the iPad. As you can see, I have released some videos of the iPhone versions of snes4iphone and n64iphone running on the iPad during the iPad’s release. They are available on my blip.tv video host here: http://zodttd.blip.tv. The WiiMote is already supported and tested to work on the jailbroken iPad as well! I’m working on iPad specific emulators that take advantage of the extra resolution to allow for better full screen controls that don’t get in the way of the action. I have friends such as westbaer ready to work on a general frontend/launcher for all my emulators. This can allow for easy updating of the user interface. I also want to add per game configurations.

I also am working on a few iPad specific App Store titles. I released OpenTTD for iPad which was a huge success, making the top 20 iPad games! But OpenTTD’s team sent a pull request to Apple and it was taken down nearly instantly. I will be making a post to see if I can get some support in getting it back up. Stay tuned for that.

In non-Apple related news, I have released Card Drop Deluxe on Intel’s AppUp store for netbooks. I am working on psx4pandora on the OpenPandora handheld. I might get a Nokia N900 to help support the port of my psx4all project’s port to that device. But most impressive of all is the 1300+ signatures received for me to support Android developments of VLC and some higher end emulators. It can be seen and supported here (http://www.petitiononline.com/ZodAndro) I’m working on getting a new Nexus One (as my previous one is on loan to a friend) so I can start developing on it.

As for this site, I plan to keep things very simple here. I will blog, and maintain a wiki for my projects. I really want to keep things friendly without the need to moderate much. So please be kind to others.

So I welcome you back with open arms and I’m glad to be back.

Thanks,

ZodTTD

P.S. Be sure to use the contact form to reach me directly. If you didn’t receive a response to your previous contacts I may not have received them. Please resend.

Yesterday I did my daily scan of Twitter and noticed an interesting question sent to at me. The person, TehMillhouse, asked if I could support the BTstack project.

Don’t know what the hell a BTstack project is? It basically implements a whole lot more of the Bluetooth stack than previously allowed by Apple. This is no easy task, so I was surprised to see a video of the author of BTstack already showing it off on YouTube by controlling an application wirelessly…with a WiiMote!

The author of BTstack and I spoke and I ran out to buy a WiiMote today. Moments later I had success! I was playing mame4iphone on my iPhone 3gs with a WiiMote. No wires! Here’s what it looked like:

So needless to say, I really want to get a PS3 controller next and implement that.
While I could use accelerometer data from the WiiMote, I chose to use button input. It fits emulators a lot better, and that is where the PS3 controller wins out. But using the WiiMote’s tiny dpad and oddly placed buttons is still much nicer than overlay touch controls. This should at least hold you over until the upcoming iControlPad release.

Once I refine this code a bit more, I will make some public releases of my work with WiiMote support included.

Thanks!
ZodTTD

For those in the Unites States, you may be eating up turkey with the family…But me, well I’m giving my thanks in a different way. I couldn’t stop playing with this framebuffer code for the iPhone I mentioned earlier. I now know of the two framebuffer addresses and how to retrieve them individually.

Why is this important? Well it’s all about my emulator’s performance in our case!

But are you willing to give up transparent overlays in landscape mode for this performance boost? Remember for this to work it will draw on top of every area I write to. So if you are in landscape mode, for performance reasons I can’t draw an opaque overlay on top of each frame I draw. And blending a semi-transparent overlay is out of question. What we are left with is possibly to center the emulator screen in the center, and have controls on the sides. Leaving the controls outside of the emulation screen could let things work.

Some quick benchmarks I ran show the average blit to a CoreSurface buffer to draw to the screen takes between 5 and 13ms per blit. It spikes constantly from that 5ms. If I simply have it write to a different buffer that is malloc’d, the blit takes less than 1ms. While this isn’t scientific, it indicates to me that the traditional way of writing to the screen via CoreSurface, while better than OpenGL ES (for this type of blit) and CoreGraphics, is still very slow. This is where getting a lower level access to the screen’s pixel data comes into play, and hence the framebuffers.

I noticed writing to the first framebuffer with CoreSurface ID 1 (more on this in a sec) is about the same speed as writing to a CoreSurface you can create on your own. The magic happens when you write to the second CoreSurface ID 2. The above test of 5ms – 13ms goes down to 2ms! Much better, considering you only have 16ms to deal with when running at 60 FPS.

So how do you access these framebuffers? Leaving behind the complex code mentioned earlier, here’s how. First add the CoreSurface framework to your project. Then:

extern void* CoreSurfaceBufferGetBaseAddress(CoreSurfaceBufferRef surface);
extern void* CoreSurfaceBufferLookup(long lookup);
...
void* framebufferID1 = CoreSurfaceBufferGetBaseAddress(CoreSurfaceBufferLookup(1));
void* framebufferID2 = CoreSurfaceBufferGetBaseAddress(CoreSurfaceBufferLookup(2));
...


Simple as that! You now have a pointer to each framebuffer. Simply write your ARGB pixel data straight to it!

Maybe psx4iphone could use this technique for an added performance increase?

Thanks,

ZodTTD

For those who have been long time followers, you probably saw how much I hoped to be able to write to the iPhone and iPod Touch’s video framebuffer. My reasoning was that I would not need to use the taxing call to “setNeedsDisplay” to render all the UIKit elements down to the framebuffer, increasing the performance of my emulators and ports. This basically would skip the middleman that is Apple, and get me closer to something like /dev/fb of NIX.

Recently I was speaking to crash-x and others in saurik‘s IRC about the framebuffer. It seems the devteam, in particular planetbeing, has been able to write to the framebuffer ever since redsn0w. Due to devteam’s strict privacy policy he was unable to make this public. At least that is what I hear was the case. This saddens me as it was Steven Troughton Smith and I’s work figuring out how to read the framebuffer for Veency’s use, that probably led to his discovery.

Either way, moments after crash-x and I dug into redsn0w, I had a working example for writing to the framebuffer. It’s not ideal for most people out there, and can’t be used for AppStore apps, but it’s the holy grail of blitting a fullscreen buffer of pixel data repeatedly. And this is exactly what emulators tend to do. What I found out however, is my emulators are set up to still require setNeedsDisplay to swap video buffers. This is not ideal for performance sake. Until setNeedsDisplay can be removed from the equation, I don’t see the following example of writing to the framebuffer too useful for a series of blits.

Here’s the code:

IOMobileFramebufferRef connect = NULL;
kern_return_t result;
CFMutableDictionaryRef dict;
CoreSurfaceBufferRef screenSurface = NULL;
unsigned char* screenbuffer;
// Probe possible framebuffers
io_service_t framebufferService = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("AppleH1CLCD"));
if (!framebufferService)
{
framebufferService = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("AppleM2CLCD"));;
}
if (!framebufferService)
{
NSLog(@"Nothing found to draw too!");
}
result = IOMobileFramebufferOpen(framebufferService, mach_task_self(), 0, &connect);
result = IOMobileFramebufferGetLayerDefaultSurface(connect, 0, &screenSurface);
CoreSurfaceBufferLock(screenSurface, 3);
// Add to a CALayer here if you want
//
// Get the framebuffer's address to be written to and store it in screenbuffer
screenbuffer = CoreSurfaceBufferGetBaseAddress(screenSurface);
CoreSurfaceBufferUnlock(screenSurface);
// write to screenbuffer like so
// draws a fully white screen
// The screen is 320x480 and seems each pixel is 4 bytes ARGB
memset(screenbuffer, 255, 320*480*4);

I’ll fiddle with this code some more to see if I can remove the need to setNeedsDisplay to swap buffers, and simply check if it will actually improve performance as well. Updates to come!

Thanks,
ZodTTD