ZodTTD: Home Of Homebrew

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

I updated mame4iphone to version 1.5.0. It is now available on my Cydia Community Source repo allowing all people with Cydia, RockApp, or Icy to download it. I also updated the source which is available on my GitHub. I am not taking donations for mame4iphone, and want everyone to enjoy the 100% free release.

So what’s new in this release? While you should be able to notice more performance, I didn’t get to update things to the assembly CPU cores just yet. I did update it to the latest MAME4All v2.4 release by the talented Franxis. I also updated the iPhone/iPodTouch specific user interface to allow for even the entire romset to be loaded. This also fixed some bugs with some screen orientation plus scaling options to not render correctly.

There is a known issue where ROMs can not be switched mid-game. There is also no way to use save states due to the older version of MAME being used. Both of these issues occurred in v1.0.0 as well.

This should help ease the wait for my proper NeoGeo+CD emulator release, as a good amount of classic NeoGeo games are supported.

Give it a go, and hope you enjoy!
- ZodTTD

This has been a long time coming, but my schedule is just now starting to free up. I have updated psx4iphone to also support the 3.1.x series of firmwares. Included in psx4iphone v1.1.0 is a fix for a bug causing the non-scaled landscape screen to display properly.

Don’t expect too much difference in performance. This emulator will still require an iPhone 3gs or iPod Touch 3rd Gen to really shine. I will be working more on this emulator as I get more free time.

You can download psx4iphone from the ZodTTD Repo which is built-in to Cydia via the included community sources package. This means it is also available via RockApp, Icy, etc. Brief installation instructions are provided within the package info.

If you run into any issues with psx4iphone v1.1.0 feel free to ask for support via the comments. Just remember, don’t ask for ROMs/ISOs or where to get the BIOS.

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

Description:

Whats up guys? I’m guessing you will all enjoy this video!

Download Link:
http://www.multiupload.com/Y7V6JBBBS6

The Directory To SSH into is:
/private/var/mobile/Applications/XXXXXXX X-XXXX-XXXX-XXXX-XXXXXXXXXXXX/LiveFire.app/quake3cd-demo/baseq3

Other Quake 3 Map Sites:
http://lvlworld.com/
http://www.map-factory.org/quake-3

ZodTTD
http://www.zodttd.com/

The video is pretty much self explanatory. If you have any questions post them in the comments or @reply me on twitter.

Note: These are NOT PERFECT. Sometimes they will crash. Like i put in the video they will have a few bugs. But don’t complain to me about this, I’m aware of this.

Be sure to put on all these maps and spread the news! Lets make the biggest Eliminate Pro community out there!
Add me as a friend to play: jones1

Twitter: http://twitter.com/0ChrisJones0

Comment Rate Subscribe
That should be about it.

The video says it all. If you want to post, give credit to me for the maps.

I am NOT trying to advertise with this. I’m spreading the video to make a huge eliminate pro online community. Note that i did recommend this site in the video.  Thanks

Quick status report for psx4iphone and gpSPhone coming right at cha!

psx4iphone v1.0.0 currently does not work on any device with firmware greater than 3.0. I have a build that now works with newer firmwares and will be releasing it shortly. Hopefully tomorrow, but don’t hold me to it.

gpSPhone currently works with all 2.x and 3.x firmwares on all devices. But there’s a catch. DevTeam messed up a kernel patch in the latest 3.1.x jailbreaks (confirmed by saurik) that affects only the iPhone 3g. If you have an iPhone 3g and use 3.1.x jailbroken with pwnagetool, there’s a fix for gpSPhone (as well as the upcoming psx4iphone). Simply run blackra1n on your current iPhone 3g firmware. It won’t erase anything or do any harm. It will however fix the issue at hand, and allow gpSPhone and the next psx4iphone to run.

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

Many developers I speak to want their own heavily populated forum based in their community. I was no different. It’s really nice to have a following and to be able to tap into this group to get a sense of what is trending, where to take your apps next, and directly communicate with those who use your software daily. My core forum audience, maybe even you, skewed very young. By nature this requires constant moderation and tough decisions of how to handle all the crazy that goes on. But what really sucks is how hard it can be to get a forum to become inviting to new users when you’re membership is low. My reaction was to keep upgrading and changing the site. This ultimately confused users and with the growing anger on the forums it made it near impossible to get new members. It was time for them to go…

So I closed the forums. I’ll just blog, invite other friends to blog, and allow for the community to easily submit articles to the front page. But I was running on forum based software on my web-server. I needed to change from Simple Machines Forum (one of the many pieces of forum software I went through) to something specifically for the purpose of a community blog. WordPress is right up my alley.

Going to WordPress is a bit odd for me. I started my site with WordPress years back, and here I am going back to it. It’s come a long way though and I really enjoy it. It’s weakness is the need to bridge user accounts and posts to and from a (decent) forum software. Luckily with the forums out, this becomes less a concern.

What I bring to you today is as much information as you can take from me, my friends, and even you. Similar to what I originally had planned earlier, but without the hassle of using forum software to do a blog’s job.

Do you have some interesting homebrew news, Apple news, or something inbetween? Once registered, you can submit news to me straight from your dashboard for inclusion on the ZodTTD frontpage!

Enjoy your stay,

ZodTTD