Sonic Advance 1 Android Port Decompile

Wasn't Advance 1 based on the S3K source code? I thought I remember hearing something to that effect somewhere here on Retro. If that's the case, wouldn't it be better to make it a hack of S3K? The colors could be handled by redrawing the graphics to use dithering just like the old titles, the goal being to make it look relatively close to the original GBA game when viewed in NTSC composite.

Another thing to consider is that the gamma should be lowered on the source GBA colors because GBA games in general had heightened gamma levels to compensate for the non-backlit screen. It'd be good to use Nintendo's 1st party games as a reference, specifically to compare the colors from the Super Mario Advance series to the colors used in the Super Mario Allstars version of those same color palettes and perform the reverse amount of gamma correction on the Sonic Advance color palettes.

 

IIRC you could change the color palette in SAdv3 on the title screen based on what you were playing it on (GBA, SP, and GB player)

 

Most of the references to debug variables are removed in this version, but there's this. Located in the aptly named SonicDebug class there's a
showCollisionRect variable, which if set to true does what's pictured above, drawing collision boundaries between most in-game objects. The source code of this version is legit (if not a 1:1 port, a very close code conversion), so I suspect this exists in the original GBA version as well, but my patience ran out for today; getting this thing to compile, run and debug today took an inordinate amount of time.

Edit: On a second thought, this particular variable is never changed on this code base, so, even if the final GBA version code is very similar, when originally compiled into ARM chances are the compiler did its optimizing thing and automatically removed the code pertaining to it.

The SonicDebug class itself is conspicuously empty, housing only the variable showCollisionRect and that's literally it. It doesn't take a lot of imagination to conclude that this class had a lot more going on during development. My guess is that the debug mode in this game was pulled from the commercial release because it did a lot more than what we understand as debug mode in the classic Sega Genesis/Megadrive games. Makes the prospect of finding a development prototype build of the GBA version all that more interesting.

There are other variables that suggest that more debug modes were a thing during development (see GameEngine.Def.DEBUG_FLAG or GameEngine.Def.DEBUG_MODE) but it's all variables that are defined and then never used, i.e. the code was pulled from their commercial release(s).

There's probably more tidbits lying around this code, even if the full blown debug mode remains elusive. I'm done for today, but I'll see if I can dig more stuff in the next few days. More people should be looking at this, though, I'm surprised no one seems to care much.

 

Were you able to successfully get the decompiled code to run in Android Studio? I've never been able to do so myself, using either evilhamwizard's decompilation in the OP or my own attempts to decompile the original APK. Nothing seems to produce 100% syntactically correct Java.

Curious to know if a working version of this is something you are actively working on.

 

Ehh, doesn't the GBA have a 32-bit colour palette, as well as scaling and rotating sprites? The 32x would be a better suitor, no? I know at least in SAdv2 there are rotating sprites along the huge loops.

 

The Advance trilogy all features smooth rotation of the character sprites (and some other objects and enemies). I've seen a couple of Genesis games also utilize software rotation on sprites (Mega Turrican for instance, though that might be too taxing on the CPU). Some people would argue the rotation looks a bit too jagged due to the GBA's low resolution anyways. I think it's a pretty cool effect, but it isn't an important effect for the gameplay by any means. A couple of the final bosses rely heavily on rotation however and some Treasure-like tricks would likely need to be employed to compensate.

The GBA had a "bitmap" mode that is stated to be theoretically capable of up to 32,768 onscreen colors. But I believe it's VERY limited and couldn't be achieved ingame, it's likely only for still shots for things like cutscenes. "Character Mode" on GBA is more in-line with what could be potentially possible ingame. It supports up to 511 simultaneous onscreen colors. Though that's also higher than i've generally seen out of GBA games. There may be a few games that came close to that, but most of the library seems to hover closer in line with the SNES' color capabilities (which is 256 max onscreen colors).

Still, adapting Sonic Advance's palette to Genesis would likely require some alterations to the level art. Character sprites actually use the same amount of colors as Sonic 1 (both with a palette of about 15 colors). But the level art and backgrounds use more colors than i've seen in any of the Genesis games. Sonic 3's Launch Base seems to have one of the larger color palettes in the trilogy, but some levels in Advance still have twice the amount of colors or more. There are probably some talented artists in the Sonic community that could work some magic and reduce the colors while still maintaining the aesthetic (god knows the likes of Megamix is gorgeous). But it would be a challenge.

 

The GBA, in its usual operating mode, has 32 palettes (16 background and 16 sprite) of 16 colors each, with 15-bit color values. The Mega Drive has 4 palettes of 16 colors each, with 9-bit color values. The 32X has a 256-color palette with 15-bit color values, in addition to the capabilities of the MD, but with the limitation that all 32X graphics must be entirely above or entirely below the MD's graphics.

 

Sort of. When you start Android Studio, choose "profile or debug" APK and load the original (2011) apk. That'll get you Java byte code, but Android Studio will give you the option to "attach java sources", you can then select a folder that contains the AndroChef decompiled Java sources (the files posted by evilhamwizard) and it should work. Then to actually run it you need to asign the project the proper SDK version (download the Android 2.3.3 SDK under Tools -> SDK Manager and assign it to the project via File -> Project Structure, where it should read "Android API 4 Platform") AND you need to create a virtual device running said SDK version (Tools -> AVD Manager -> Create Virtual Device -> Nexus S -> x86 Images/Gingerbread (Google APIs) -> Landscape orientation). That should let you debug it via Run -> Debug.

This does not compile, sadly, but it's a start to fiddle with it. I'm sure it's possible to build a compilable version with these sources, it's just that Android is not my strength.

Forget it. First of, I don't think a port of the Java VM to the motorola 68k exists, but even if you could somehow compile it, it'd run like ass; it's already a challenge to get good performance out of compiled C on that CPU, let alone Java. Second, the amount of work required to rework all graphical assets in this game to make it work, even if you were to target the 32x, would be titanic, and I frankly don't think that people like Sonic Advance that much to devote so much of their lives to a project like that.

Simply put, it'd be easier to make an entirely new game from scratch. Or, at very least, if not from scratch you'd be better off building on top of the classic megadrive Naka engine than trying to port this.

Porting it to PC and modern platforms on the other hand is feasible. It would still involve a significant amount of work, but at a glance I would say the code is compartmentalized well enough that I can see it.