SNES9xNext – Android Release

With VBANext rolling on in the background we took a small side step and got SNES9xNext repository going. To help mark this release I prepared a port of SNES9xNext for Android. This is particularily interesting since all current SNES ports on Android are of SNES9x 1.43. The SNES9x 1.43 branch is known for its raw speed so it is a chose candidate for running on slower CPUs. Since SNES9x 1.5X the team has gone towards improving audio by adding blargg’s audio core among other things. In turn the SNES9x 1.5X branch is quite a bit slower. Putting arguments aside which is better the plan here is to streamline being able to quickly deploy each version. Currently SNES9x 1.43 runs full speed with frameskip=0 on all games on most native Android 1.6 or higher devices. While SNES9x 1.52 requires a newer tablet basically. On my HTC Incredible S which has a 1Ghz ARM-7 CPU I get ~55fps on most games with frameskip = 0 and full speed with frameksip = 1.


Download SNES9xNext 1.52 Android

Please post feedback in the forums!

SD3

Shadowrun

Enjoy!
Halsafar

Android NDK r6 Released

This is a day late but none the less important to the mobile efforts.  Google released the sixth major version of its native development kit (NDK).  For those who are unaware this allows you to run C/C++ on Android devices and communicate to the Dalvik via the Java Native Interface (JNI).

This release brings us one very cool change for future tablet owners.  You can now build for x86 architecture!  Truly exciting for the next generation of tablets running on Intel chips. (http://gizmodo.com/5551822/intel-oak-trail-is-official-tablet-processors-with-windows-android-and-meego-support).

For developers this release brings a critical new piece of software for the debugging process.  Currently debugging the Java side of things is 100% solved and very easy to use.  However if you need to debug things in native land you are completely sol unless your phone manufacturer left gdb support available on it (or you can root your phone).  The NDK does come with ndk-gdb which is gdb as we all know it.  However some phones like mine (HTC Incredible S) are locked down in some nasty ways that as a side effect broke gdb.  So really all I have to go on is a stack trace which contains all hex addresses and no symbols, only which library the crash occured in.  There are ways to take the stack trace and a decompiled version of your library start to map things out.  This proved cumbersome at best.  Finally Google has released ndk-stack.  This analyzes the stack trace and spits out some meaningful information.

ndk-stack converts this classic stack dump:

I/DEBUG   ( 1272): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   ( 1272): Build fingerprint: 'sasktel_canada_wwe/htc_vivo/vivo/vivo:2.2.1/FRG83D/339842:user/release-keys'
I/DEBUG   ( 1272): pid: 17249, tid: 17273  >>> ca.halsafar.foo <<<
I/DEBUG   ( 1272): signal 11 (SIGSEGV), fault addr 00000000
I/DEBUG   ( 1272):  r0 00000000  r1 80d93b8c  r2 80d94b8c  r3 00008928
I/DEBUG   ( 1272):  r4 80d7d2b0  r5 000168d8  r6 80d94b8c  r7 80d93ab0
I/DEBUG   ( 1272):  r8 00008928  r9 44224f40  10 80d7d378  fp 49e94ed8
I/DEBUG   ( 1272):  ip 00000000  sp 49e94b28  lr 80d2a488  pc 80d516dc  cpsr a0000010
I/DEBUG   ( 1272):  d0  6843646565707361  d1  2f76654464696f6e
I/DEBUG   ( 1272):  d2  65747461626d6167  d3  2e2e2f2f696e6a65
I/DEBUG   ( 1272):  d4  626d616762696c2f  d5  6372732f65747461
I/DEBUG   ( 1272):  d6  2e79726f6d656d2f  d7  293935343a707063
I/DEBUG   ( 1272):  d8  4397000041f00000  d9  43e0000000000000
I/DEBUG   ( 1272):  d10 41dfffffffc00000  d11 c3e0000000000000
I/DEBUG   ( 1272):  d12 0000000000000000  d13 0000000000000000
I/DEBUG   ( 1272):  d14 0000000000000000  d15 0000000000000000
I/DEBUG   ( 1272):  d16 3fe40fd000000000  d17 3e23b592a81fa000
I/DEBUG   ( 1272):  d18 3fe0000000000000  d19 3fe00000013b592b
I/DEBUG   ( 1272):  d20 003f003f003f003f  d21 003f003f003f003f
I/DEBUG   ( 1272):  d22 0006000300070002  d23 0006000300070002
I/DEBUG   ( 1272):  d24 0101010101010101  d25 0000000000000000
I/DEBUG   ( 1272):  d26 0000000000000000  d27 0000000000000000
I/DEBUG   ( 1272):  d28 0000000000000000  d29 0000000000000000
I/DEBUG   ( 1272):  d30 001f001f001f001f  d31 001f001f001f001f
I/DEBUG   ( 1272):  scr 20000012
I/DEBUG   ( 1272):
I/DEBUG   ( 1272):          #00  pc 000516dc  /data/data/ca.halsafar.foo/lib/libfoo.so
I/DEBUG   ( 1272):          #01  pc 000171f4  /system/lib/libdvm.so
I/DEBUG   ( 1272):          #02  pc 00045a78  /system/lib/libdvm.so
I/DEBUG   ( 1272):          #03  pc 0004b25a  /system/lib/libdvm.so
I/DEBUG   ( 1272):          #04  pc 0001c160  /system/lib/libdvm.so
I/DEBUG   ( 1272):          #05  pc 00022ed4  /system/lib/libdvm.so
I/DEBUG   ( 1272):          #06  pc 00021d70  /system/lib/libdvm.so
I/DEBUG   ( 1272):          #07  pc 0005d860  /system/lib/libdvm.so
I/DEBUG   ( 1272):          #08  pc 0005da90  /system/lib/libdvm.so
I/DEBUG   ( 1272):          #09  pc 000507cc  /system/lib/libdvm.so
I/DEBUG   ( 1272):          #10  pc 00011014  /system/lib/libc.so
I/DEBUG   ( 1272):          #11  pc 00010b00  /system/lib/libc.so
I/DEBUG   ( 1272):
I/DEBUG   ( 1272): code around pc:
I/DEBUG   ( 1272): 80d516bc a0600002 b3a00000 e28550d8 e7840005
I/DEBUG   ( 1272): 80d516cc e28710dc e1a02006 e1a03008 e1a0000c
I/DEBUG   ( 1272): 80d516dc e59cc000 e1a0e00f e59cf00c e59f1054
I/DEBUG   ( 1272): 80d516ec e1a03080 e59f0050 e3a02b5a e282c0c8
I/DEBUG   ( 1272): 80d516fc e784300c e08f2000 e08f1001 e3a00003
I/DEBUG   ( 1272):
I/DEBUG   ( 1272): code around lr:
I/DEBUG   ( 1272): 80d2a468 e1a01082 ebffffb9 e1a06000 e5940000
I/DEBUG   ( 1272): 80d2a478 e3a01a05 e2813030 e7901003 eb0009e3
I/DEBUG   ( 1272): 80d2a488 e3560000 a04060c6 e5850000 e1a00006
I/DEBUG   ( 1272): 80d2a498 e8bd8070 e92d4010 e1a04000 e5900000
I/DEBUG   ( 1272): 80d2a4a8 e3500000 0a000002 eb0020df e5940000
I/DEBUG   ( 1272):
I/DEBUG   ( 1272): stack:
I/DEBUG   ( 1272):     49e94ae8  80d93ab0
I/DEBUG   ( 1272):     49e94aec  80d7d378  /data/data/ca.halsafar.foo/lib/libfoo.so
I/DEBUG   ( 1272):     49e94af0  44224f40
I/DEBUG   ( 1272):     49e94af4  80d7d378  /data/data/ca.halsafar.foo/lib/libfoo.so
I/DEBUG   ( 1272):     49e94af8  49e94ed8
I/DEBUG   ( 1272):     49e94afc  80d33d78  /data/data/ca.halsafar.foo/lib/libfoo.so
I/DEBUG   ( 1272):     49e94b00  0026a148  [heap]
I/DEBUG   ( 1272):     49e94b04  80d93b84
I/DEBUG   ( 1272):     49e94b08  80db9088
I/DEBUG   ( 1272):     49e94b0c  80d93b84
I/DEBUG   ( 1272):     49e94b10  ffffffff
I/DEBUG   ( 1272):     49e94b14  80d93ab0
I/DEBUG   ( 1272):     49e94b18  80d7d2b0  /data/data/ca.halsafar.foo/lib/libfoo.so
I/DEBUG   ( 1272):     49e94b1c  000168d8  [heap]
I/DEBUG   ( 1272):     49e94b20  df002777
I/DEBUG   ( 1272):     49e94b24  e3a070ad
I/DEBUG   ( 1272): #00 49e94b28  80d93b84
I/DEBUG   ( 1272):     49e94b2c  00000000
I/DEBUG   ( 1272):     49e94b30  00300298  [heap]
I/DEBUG   ( 1272):     49e94b34  49e94b70
I/DEBUG   ( 1272):     49e94b38  00000000
I/DEBUG   ( 1272):     49e94b3c  479790a0  /dev/ashmem/mspace/dalvik-heap/2 (deleted)
I/DEBUG   ( 1272):     49e94b40  44224f48
I/DEBUG   ( 1272):     49e94b44  49e94b50
I/DEBUG   ( 1272):     49e94b48  44224f2c
I/DEBUG   ( 1272):     49e94b4c  80a171f8  /system/lib/libdvm.so
I/DEBUG   ( 1272): #01 49e94b50  0027e3f0  [heap]
I/DEBUG   ( 1272):     49e94b54  41aaecec  /dev/ashmem/dalvik-LinearAlloc (deleted)
I/DEBUG   ( 1272):     49e94b58  479790a0  /dev/ashmem/mspace/dalvik-heap/2 (deleted)
I/DEBUG   ( 1272):     49e94b5c  44224f40
I/DEBUG   ( 1272):     49e94b60  80a173c0  /system/lib/libdvm.so
I/DEBUG   ( 1272):     49e94b64  0027e3f0  [heap]
I/DEBUG   ( 1272):     49e94b68  49e94b70
I/DEBUG   ( 1272):     49e94b6c  80a45a7b  /system/lib/libdvm.so

Into this:

Stack frame #00  pc 000516dc  /data/data/ca.halsafar.foo/lib/libfoo.so: Routine step in /home/halsafar/androidDev/foo/jni//Application.cpp:469
Stack frame #01  pc 000171f4  /system/lib/libdvm.so
Stack frame #02  pc 00045a78  /system/lib/libdvm.so
Stack frame #03  pc 0004b25a  /system/lib/libdvm.so
Stack frame #04  pc 0001c160  /system/lib/libdvm.so
Stack frame #05  pc 00022ed4  /system/lib/libdvm.so
Stack frame #06  pc 00021d70  /system/lib/libdvm.so
Stack frame #07  pc 0005d860  /system/lib/libdvm.so
Stack frame #08  pc 0005da90  /system/lib/libdvm.so
Stack frame #09  pc 000507cc  /system/lib/libdvm.so
Stack frame #10  pc 00011014  /system/lib/libc.so
Stack frame #11  pc 00010b00  /system/lib/libc.so

I have not posted any information on the mobile side so far. Consider this a first step into getting into the habit of posting. The plan is to bring all the Android ports inline with the the PS3 ones.

Halsafar

VBANext – Launch

As of today, VBA PS3 has evolved into VBANext. All future development will happen on this page :

https://code.google.com/p/vbanext/

In short, VBA PS3 is dead – long live VBANext. The same will happen to SNES9x PS3 shortly when it blossoms into SNES9x Next (new name for SNES9x Slim).

Platforms


Phoenix Wright: Ace Attorney (Japanese version – Gyakuten Saiban) on VBANext (PS3 version shown here) with the dot shader.

This new project will be a faster, slimmed-down version of VBA-M that is currently aimed at three platforms:

  • PlayStation3
  • Xbox 360 (WIP)
  • Mobile (WIP)

It will replace both VBA PS3 on PlayStation3 and Lantus’ VBA360 0.03 on Xbox 360. In addition to that, a port to mobile platforms is tentatively in the works.

A few screenshots (taken from the PS3 version) can be viewed here.

PlayStation3


Donkey Kong ’94 with Super Game Boy borders on VBANext (PS3 version shown here).

As for the PS3 port – a lot of progress has been made over the past few weeks. Super Game Boy border support is now in – when you select a game that is Super Game Boy-compatible from the ROM menu, it will display the border that would be visible on a real SNES with a Super Game Boy add-on cart.

It will perhaps be possible to add fourplayer gamepad support at a later date for Super Game Boy games as well – certain games like Wario Blast made use of the Super Gameboy’s access to the host hardware (SNES) to allow for multiplayer support with regular SNES pads. VBA-M supports this out of the box – so it would be a shame to let it go to waste.

On the display front – FBO mode will be added – this will allow for two shaders to be selected at once. All the features that are currently in SNES9x PS3 and other emulators will be added as well – for instance, border support (different from the Super Game Boy border support which is built into VBA-M) and possibly game aware shaders as well.

Mega Man V – another Super Game Boy-compatible game – shown running here on VBANext (PS3 version shown).

Xbox 360

Final Fantasy Tactics Advance running on VBANext (PS3 version shown) – now sans the FPS slowdown in the introduction screen.

The Xbox 360 port will require some cleaning up. I will use Lantus’ VBA360 0.03 sourcecode at first and then try to slim it down by removing dependencies such as libSDL. I’m confident performance will be even better now than it previously was on 360 – since VBA PS3 was based on Lantus’ core code changes after all – with the new slimline core, it is only bound to get better.

Sonic Advance 1/2 will work again with this updated Xbox 360 version because of the removal of the SFML network code (note – if a porter wishes to do so – he can reimplement this again by defining the switch ‘NO_SFML’ – the SFML network code’s only purpose is to allow Dolphin – the Gamecube/Wii emulator – and VBA-M interoperability – it has no other purpose and it actually breaks these two games from working).

I also got rid of a rather annoying display bug in Advance Wars 2 for the PS3 port (now evolved into VBANext) – so obviously that will be fixed on 360 as well, since it suffered from the same problem.

Mobile

A mobile port for Android is tentatively in the works. More progress on this one will be posted shortly.