| PCE.emu 1.3.2 (unofficial Android, iOS, WebOS, & PS3 port of Mednafen) [message #1811] |
Tue, 31 August 2010 06:45  |
|
Hi everyone. This is a port of Mednafen's PC Engine emulation to Android, and my first ever emulator port. I've only tested on a Droid/Milestone for now but hopefully it will run on other devices. I'm planning to have regular updates with more features/optimizations and other emulator ports in the future.
Hope you'll enjoy it 
Update: Version 1.2.0: supports homebrew PS3 consoles (runs HuCards only).
Update: Version 1.3.0: PS3 port supports bin+cue format CDs.
Update: supports jailbroken iPhones, iPods, & iPads, now available on Cydia.
Update: supports Palm Pre phones running at least WebOS 1.4.5, now available on the App Catalog.
http://explusalpha.com/home/pce-emu
[Updated on: Tue, 30 November 2010 14:12]
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1812 is a reply to message #1811 ] |
Thu, 02 September 2010 10:39  |
|
Have you looked at the experimental "pce_fast" code in 0.9.12-WIP? It's designed for CPU-constrained systems, and there are still optimizations that can be done(sound code and CDROM code).
Versus 0.8.x however, it includes optimizations that are somewhat unsafe, and may cause problems with certain SuperGrafx and PCE CD games(one such optimization is more for x86, and can be recoded without much of a performance penalty if any for running on a RISC CPU like ARM).
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1813 is a reply to message #1812 ] |
Fri, 03 September 2010 03:49 |
|
|
Thanks for the tip. I'll try out 0.9.12-WIP and see how it compares speed-wise. There's still more optimizations that can be done on the Android side as well involving sending the pixels to the screen faster for devices with slower GPUs. I need to run some tests on different texture formats like RGB565 and paletted ones to compare their speed. It looks like Mednafen only supports RGBA8 at the moment? Are there any plans to add other formats in the future?
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1814 is a reply to message #1811 ] |
Fri, 03 September 2010 06:02 |
|
Remember to use "-force_module pce_fast" if you're using a compiled version the stock code. The "pce" module itself is slower than in 0.8.x, which is the opposite of what you want. 
And FYI, to avoid confusion, the "int Rshift, Gshift, Bshift;" in EmulateSpecStruct in git.h should be removed, they're unused(it's all MDFN_Surface now~). Also, the pitch in MDFNGameInfo is in bytes, while the pitch in MDFN_Surface is in pixels(converting the pitch in MDFNGameInfo to pixels is on my TODO list, for code clarity).
Mednafen 0.9.x supports another colorspace, YCbCr, which can be converted easily to a chroma-subsampled format on the driver side to be handled by overlay hardware on the video card, but I doubt this would be of much use on the Android.
I've contemplated implementing a 16bpp(and 8bpp even, of which some incomplete code exists) internal rendering mode, but it would require a ton of code changes, and would add to code complexity. That's not to say I won't ever implement it in a partial manner(only for a select few emulated systems), though...
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1821 is a reply to message #1812 ] |
Sun, 05 September 2010 18:11 |
|
Did some initial testing of pce_fast and noticed a decent speed up for hucard games at lower clock speeds. Haven't compiled the CD code yet but hopefully it should also get a increase
A tweak that greatly boosts the speed on OpenGL ES devices is drawing the entire screen in contiguous memory since you don't have GL_UNPACK_ROW_LENGTH to handle the pitch and more pixel data can fit in the CPU's small cache. I noticed the PCE code treats the screen as one big 1024x256 image which requires a call to glTexSubImage2D per line to fill a 256 wide texture, dropping the frame rate to single digits no matter how fast the CPU is. I simply set all the pitch calculations in vdc.cpp from 1024 to DisplayRect->w, allowing the whole screen to upload in one call. This seems to break games that use multiple horizontal resolutions in one frame and will need a work-around for those cases. I haven't extensively checked all the PCE emulation code, but do you know of any other issues that might be caused by this change and perhaps a cleaner way to implement it so such a large memory buffer isn't needed in the first place?
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1827 is a reply to message #1811 ] |
Tue, 07 September 2010 12:22 |
|
There are issues with the pce_fast code such that a game that sets its horizontal display width to larger than what's visible could cause corruption at the end of the preceding line(and the next line, but that'll be drawn over when the next line is drawn, so it's not much of an issue as long as you have padding at the end of the surface), if you're going with pitch == width.
Altering the type(struct) of LineWidths to include a pixel offset into the MDFN_Surface(for the start of each line), and then packing each line in the framebuffer with its pitch == width, would probably be a cleaner way(so that there could be multiple pitches in the surface). I could implement this for the next WIP, but I'll have to think about it. (Though you could something similar now, you'd just have to iterate through to calculate the surface offset for any line)
[Updated on: Tue, 07 September 2010 12:28]
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1829 is a reply to message #1827 ] |
Wed, 08 September 2010 20:51 |
|
A couple of notes from compiling 0.9.12-wip with GCC 4.4 from the Android NDK:
- The various -finline-limit and --param flags that are added by the configure script may do more harm than good. At -O2 they don't have a significant effect, but when used at -O3 there's a size increase of over 100K in the subset of files I'm compiling with no difference in performance. Might be best to make them optional in the future.
- A number of identifiers in huc6280.cpp (_X, _P, etc) conflict with those found in the Android C library headers and should be renamed since they violate C rules about reserved identifiers. There may be more variables affected in files I haven't compiled yet.
- Not directly PCE related, but the 68k cpu emulator will fail to compile because gen68k is compiled with the cross-compiler (the prefix passed to configure with --host). It should use the system's GCC since the program needs to be executed as part of the build process.
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1831 is a reply to message #1811 ] |
Mon, 13 September 2010 10:52 |
|
In the meantime until 0.9.13, some bugs that you might want to fix in your copy:
HuCClose() in huc.cpp add:
if(HuCROM)
{
MDFN_free(HuCROM);
HuCROM = NULL;
}
in Load(const char *name, MDFNFILE *fp) in pce.cpp change:
to
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1840 is a reply to message #1831 ] |
Fri, 24 September 2010 15:21 |
|
|
Thanks for the fixes, I did some texture format testing and there's definitely a nice speed up when uploading 16-bit textures on my Droid so I'll be implementing some form of 32-bit to 16-bit conversion to help with the gpu bottleneck. Surprisingly, ran the same tests on an iPhone 3G and it's able to upload any of the required formats (even 512x256 32-bit) at 60fps no problem, but the cpu is a bit too slow to run PCE games full speed :\
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1844 is a reply to message #1811 ] |
Tue, 28 September 2010 20:54 |
|
Out of curiosity, have you implemented/tried an auto-frameskip mechanism that skips the frame(espec->skip = true, and don't blit the frame to the display device) if the sound buffer fill level drops below a certain threshold?
I've gone ahead and implemented 16bpp rendering for pce_fast, which will be 0.9.13's code. It won't ever be used in the stock Mednafen builds, though, due to not wanting to obfuscate code elsewhere to support 16bpp and 32bpp. The additional code and conditionals may cause a detrimental effect on performance, though it should be solvable by altering code paths(perhaps so far as to create two VDC_RunFrame() functions) and/or using PGO(just something to keep in mind once I release the code).
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1845 is a reply to message #1844 ] |
Wed, 29 September 2010 07:52 |
|
I have a basic sync to video system implemented but am currently overhauling it into 2 methods. First one is to always try to have the audio running at full speed and drop frames as needed, pretty much the auto-frame you described. The second is to always have every frame displayed and adjust the rate of the audio to match. This would be useful if your refresh rate is close but not exactly the same as the emulated system and avoids judder in the video. What's the cleanest method to change the speed of the audio at runtime? Should I resample it after Mednafen decodes it or look into the lower level code like Blip_Buffer? As for the 16-bit rendering, I'd make it a compile-time switch since any platform that needs it probably won't be using the 32-bit code at all.
Also, compiled pce_fast on a big-endian PPC system and found an issue where the tile maps are drawn reversed in the X direction. In the DrawBG function, the following code dereferences a 64-bit int pointer which is cast from an 8-bit int one:
*target64 = (CG_Base[(bat & 0xFFF) * 8] & cg_mask) | color_or;
...
*target64 = CG_Base[(bat & 0xFFF) * 8] | color_or;
Wrapping the right-hand side in a conditional byte-swap macro fixes the problem.
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1847 is a reply to message #1811 ] |
Wed, 29 September 2010 16:24 |
|
Thanks. I haven't had access to a big-endian machine for quite a while, so I haven't been able to test for oversights like that.
Replacing:
*tc |= (uint64)raw_pixel << ((7 - x) * 8);
with
#ifdef MSB_FIRST
*tc |= (uint64)raw_pixel << ((x) * 8);
#else
*tc |= (uint64)raw_pixel << ((7 - x) * 8);
#endif
in FixTileCache(...) is the proper/fast way to fix it(I think, I haven't tested it :b).
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1848 is a reply to message #1811 ] |
Wed, 29 September 2010 17:15 |
|
I don't know if Blip_Buffer can handle a rate change without introducing a click...also, its output rate granularity is somewhat limited, and might not be fine enough for dynamic frame rate control.
If you want to try something really low-level, you could do(in pce.cpp):
static const uint32 TimestampScale = 0.95 * (1 << 11);
psg->Write(((HuCPU.timestamp / pce_overclocked) * TimestampScale) >> 11, A, V);
psg->EndFrame(((HuCPU.timestamp / pce_overclocked) * TimestampScale) >> 11);
if(espec->SoundBuf)
{
for(int y = 0; y < 2; y++)
{
sbuf[y].end_frame(((HuCPU.timestamp / pce_overclocked) * TimestampScale) >> 11);
espec->SoundBufSize = sbuf[y].read_samples(espec->SoundBuf + y, espec->SoundBufMaxSize, 1);
}
}
etc. (basically, scale all the timestamp values you pass to psg->whatever.
That would preserve the pitch of tonal sounds and noise for HuCard games, though digital streaming playback pitch would still be affected(that can't be avoided without a lot of buffering).
For CD-ROM...it's complicated. You could just scale the timestamps passed to PCECD_*(), but that could conceivably cause random compatibility issues on some PCE CD games.
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1850 is a reply to message #1847 ] |
Thu, 30 September 2010 14:59 |
|
|
Confirmed your FixTileCache fix works in big-endian.
|
|
| Re: PCE.emu 1.0.0 (unofficial Android port of Mednafen) [message #1866 is a reply to message #1844 ] |
Fri, 22 October 2010 15:24 |
|
Did some more tinkering around the Android source code and found a method to directly access video ram and bind it as an opengl texture, used by google's surface compositor but not available through the public api. It needs a combination of 4 opengl extensions and loading some system libraries at runtime but it seems to work on my Droid, raising the GPU cap to about 55fps for a 256x232 RGBA8 texture. Tested it using RGB565 and was able to get 60fps with some bandwidth to spare so this will be great once it's hooked up to your 16-bit rendering implementation
Another idea I had to optimize using this method is to set the mapped video ram directly as mednafen's video buffer to eliminate the extra memory copy. But ideally the code should be able to handle drawing to a buffer with a minimized pitch since using a 1024 pixel wide texture would still waste bandwidth even if partially updated. I'll have to do some more testing with it once you release 0.9.13.
|
|
| Re: PCE.emu 1.2.0 (unofficial Android & PS3 port of Mednafen) [message #1873 is a reply to message #1871 ] |
Sat, 30 October 2010 16:30 |
|
|
Thanks, I'll probably put in some form of aspect ratio controls in the next update for all ports.
|
|
Members 
Search 
Help 
Register 
Login 
Home 
]