wraggster
October 14th, 2008, 18:49
Normally when programming an emulator for a handheld you're given access to the memory used for what the screen displays. That memory is the framebuffer.
On a Linux driven handheld such as the GP2X or Pandora you can access it very easily programmatically. On the iPhone or iPod Touch, however, it's much more difficult. Apple has even removed CoreSurface from the public frameworks for use on AppStore. CoreSurface is what I tend to use for my applications on jailbroken iPod Touch and iPhones. Even CoreSurface doesn't allow you to display write to an area of memory and see it display on the screen instantly. It requires you to update all the surfaces of a view and it's subviews. That overhead is costly on a processor intensive application such as an emulator.
Writing directly to the framebuffer and avoiding the need for updating all layers of a screen via setNeedsDisplay gives a great performance increase. This will be shown soon.
Through working with the iPhoneDoom author with help from Saurik I have now been able to write to the framebuffer. Well, sort of. Conditions have to be right for it to work well, and factors such as colorspace conversion to ARGB get in the way of performance for some apps. It also may not be as low level as it gets for display processing. It seems there are still some layers above what I am referring to as a framebuffer. In actuality this is a surface Apple uses at one point to draw to the screen.
At first I tried to implement these "raw framebuffer writes" to vlc4iphone. It works well and allowed videos that didn't play before to run due to performance increases. But it will flicker when a UIButton, for instance, is touched and causes a setNeedsDisplay routine to be called. For some reason this leaves the surface to be drawn either under the view that was displayed last, or not at all. A quick fix for me was to hold down a button until it flickered the video back on. So until I figure out how to prevent this from occuring, or remove framework controls like UIButtons from being used on the Now Playing screen, vlc4iphone will have to wait to get this implemented.
Next I tried gpSPhone. Since the in-game screen has no such framework controls, it would work well. Except I would have to scale, rotate, and do colorspace conversion from RGB16 to ARGB each frame. This could possibly slow down things more so than speed it up. I will speak to the author of gpSP and see what can be done to help along in implementing this into gpSPhone.
So now that I know my best target is something that can handle ARGB (32bit color) and doesn't need to be scaled or rotated...I'm looking at snes4iphone at genesis4iphone as candidates.
Expect some more updates as things progress with this. It could help give many of my apps the performance increase they may need.
I plan on posting the code I am using to write to this surface next update on this subject.
http://www.zodttd.com/forums/showthread.php?t=4755
On a Linux driven handheld such as the GP2X or Pandora you can access it very easily programmatically. On the iPhone or iPod Touch, however, it's much more difficult. Apple has even removed CoreSurface from the public frameworks for use on AppStore. CoreSurface is what I tend to use for my applications on jailbroken iPod Touch and iPhones. Even CoreSurface doesn't allow you to display write to an area of memory and see it display on the screen instantly. It requires you to update all the surfaces of a view and it's subviews. That overhead is costly on a processor intensive application such as an emulator.
Writing directly to the framebuffer and avoiding the need for updating all layers of a screen via setNeedsDisplay gives a great performance increase. This will be shown soon.
Through working with the iPhoneDoom author with help from Saurik I have now been able to write to the framebuffer. Well, sort of. Conditions have to be right for it to work well, and factors such as colorspace conversion to ARGB get in the way of performance for some apps. It also may not be as low level as it gets for display processing. It seems there are still some layers above what I am referring to as a framebuffer. In actuality this is a surface Apple uses at one point to draw to the screen.
At first I tried to implement these "raw framebuffer writes" to vlc4iphone. It works well and allowed videos that didn't play before to run due to performance increases. But it will flicker when a UIButton, for instance, is touched and causes a setNeedsDisplay routine to be called. For some reason this leaves the surface to be drawn either under the view that was displayed last, or not at all. A quick fix for me was to hold down a button until it flickered the video back on. So until I figure out how to prevent this from occuring, or remove framework controls like UIButtons from being used on the Now Playing screen, vlc4iphone will have to wait to get this implemented.
Next I tried gpSPhone. Since the in-game screen has no such framework controls, it would work well. Except I would have to scale, rotate, and do colorspace conversion from RGB16 to ARGB each frame. This could possibly slow down things more so than speed it up. I will speak to the author of gpSP and see what can be done to help along in implementing this into gpSPhone.
So now that I know my best target is something that can handle ARGB (32bit color) and doesn't need to be scaled or rotated...I'm looking at snes4iphone at genesis4iphone as candidates.
Expect some more updates as things progress with this. It could help give many of my apps the performance increase they may need.
I plan on posting the code I am using to write to this surface next update on this subject.
http://www.zodttd.com/forums/showthread.php?t=4755