Giving thanks…framebuffer style.
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
I would definitely use psx4iphone more if the performance was better in the Final Fantasy games, especially the overworld in 8 and 9. I would also love to play Mario RPG in snes4iphone and better performance in gpsPhone for Mother 3. I already bought gpsPhone but if I can play Mario RPG and Final Fantasy 7/8/9 at a decent speed, I would buy snes4iphone and psx4iphone (if you charged for it)!
Well psx could use this, but some of us are more concerned about 3.1.2 compatibility 1st
Mother series FTW!!
I just hope he won’t charge for psx4iphone…
Anyways, I see you’re making progress on using this new technique to show the screen. I don’t think the landscape overlays will be missed too much, as it’s easy to get used to the position of button hit boxes. In fact, it would probably be nice to finally see the whole screen without that Overlay that’s too opaque anyways…
!!!! Happy Turkey Day Zod !!!!
Sounds like its going pretty well so far…. Best of luck to ya
I'm all for faster running roms but at the cost of transparency I think not. Games with multiple layers would be completely unplayable (Like Zelda 3). Many idiots already complain that zelda doesn't work because they don't turn on transparency.
That being said, have you looked into the btstack project? (http://code.google.com/p/btstack/) The demo was connecting a wiimote via bluetooth to use with apps. I feel this is a severely desired missing feature.
True True
I hope he doesn't either. I have no money, or credit card =\\
I hope he doesn't either. I have no money, or credit card =\\
All right, let’s file this as an officially requested feature:
bluetooth WiiMote support. Please, zod, it would be absolutely awesome. The one big argument ‘against’ emulation on iPhones is fumbly controls, and this would instantly negate it.
Ryan: as far as I’ve gathered, this isn’t about transparency in-game, but only about the transparent overlays that are present in landscape mode. AFAIK, the in-game transparency is rendered into a frame by the snes, not on top of a screen, so rendering the screen directly through the frame buffer should preserve transparency. No worries.
Hehe he won't, the SNES app will be the only payed app
yeah all too true!
Just like gpsphone was the only paid app there was ever gonna be?
As much as I'd like performance, I really think that without the transparent overlay the experience would be unplayable.
Well I think that, although the overlaid controls are nice, they shouldn’t really be the priority. Performance should be. I don’t look at them too much anyway. Just every now and again if I fall off of them. Would it be possible to make this a preference in the app? Overlaid controls on and slower emulation or work without them for snappier gameplay?
Has anyone else tried the code? I just stuck it into a quick test project with a window, but it doesn't seem to draw to the framebuffer until the application closes.
I wrote a few lines to fill the buffer with blue and I placed them in applicationDidFinishLaunching(). The app launches fine and displays a plain white screen. When it quits, the dock section of my screen is blue (but I only had it fill the first 10 rows of pixels).
I'm fairly new to iPhone development so I might be missing something important.
ah thanks for the update
About the wiimote topic, that would be cool but once you said bluetooth support, i thought about the ps3 controller running the iphone. That would be a kickass dev project! Think about it, you could preset all controls for apple apps and jailbreak apps. Touching the screen and landscaping is a pain in my ass when it comes to gaming, especially the emulators and the new nazi zombie iphone game.
Any way to improve performance is great =D
Is there any chance this will be implemented in the other emulators, as they don't quite run optimally on older iPhones.
I think that they overlay controls are really difficult to see and I can’t really play using them so I’m all for having them removed.
However, like an above poster said, bluetooth Wiimote support would be AMAZING.
Also, unlike most people, I am not upset that you charge a couple of dollars for your emulators. I have no idea how many hours you put into these projects so it’s nice to be able to help you out a little bit.
Can someone tell me where wiimote support would come in handy please? xD
umm… on what emulator and which games?..
I agree.
I just want to see psx4iphone work first (3.1.2 support)
After that we need the framebuffer enhancement.
I would absolutely LOVE wiimote support
A wiimote with a classic controller could come in handy on pretty much all of zodttd's emulators, as it has enough buttons for most of them.
Umm… Playing Games…
If it had wiimote support, we could all go buy a wiimote and not have to wait for the iControlpad!
)
And since the stack has already been written (AND it's open source!), all Zod needs to do is implement it into his emulators.
I would totally go out and buy a wiimote just for that purpose. And, if we need the extra control, we could hook up a nunchuck and use the analog along with the extra buttons
I was told by someone that was in direct contact with the people working on the Bluetooth stack using the WiiMote, that it wasn't working correctly beyond what was able to be done in the video.
Can anyone confirm if WiiMote support has been implemented in anything? I have a feeling it's not so "plug and play".
hi Zottd. I finally reached the bottom of your comments list. And yes, thanks for providing the direct framebuffer info. I ripped out the code from Veency to get live access to the iPhone camera.
About my BTstack. The connection and the reporting of buttons and accelerometer of the WiiMote work flawless, I just could figure out the maths for converting the acceleromation readings into a OpenGL rotation matrix for pitch and roll. Knowledge about Quaternions would help. Support for the PS3 controller should be simliar (it's HID and it just sends you reports)
If you plan to add Bluetooth support to your emulators that would be great. Its one of the 3 top-most asked for comments I get. You can either join the BTstack mailing list or contact me directly.
Matthias
Awesome. I just wrote btstack-dev with a question about if I would run into any pitfalls. With BTStack in the news as of late, I too have been getting a lot of requests. Contacting you directly as well.
That’s great!!
I hope it’s not too much work to implement the controller!
Are you saying that a similar bluetooth stack is coming that will be compatible with PS3 controllers?
If so… then that just made my day
Will access to the iPhone's framebuffer allow speedups to your vlc port?
Also, is there a third framebuffer address?
I only know of 2 framebuffers (I believe the iPhone is double buffered).
I will see if I can speed up vlc4iphone using this technique, great idea!
Hey ZodTTD, I'm new here. I love your emulators. I run it on my iPhone 3G but it's very slow, also the sound.. I think this topic you wrote is about my problem, isn't it? But I don't know what to do :S Please help me out
Nicolas
Is this already implemented in all the games or do we put this in some where? If so can I talk to some one about on how to go about doing this?