[Delta]

Hitaxas, on 26 July 2014 - 08:15 PM, said:

Just curious... Since this was converted into a disassembled java, in theory would it be possible to recompile it into a normal .jar and run it from a pc maybe? That would be interesting, and further research could lead to a decent engine for java based fangames or "hacks".

If only it were that easy!

Basically, no, you won't magically get a PC version. The game would likely be calling into several Android-specific APIs since it's made for Android. That said, a good chunk of the code would probably be independent of the fact that it's running on Android (such as physics), so perhaps with a bit of effort it can be turned into a PC Java game. Not a trivial task, though, since you would need to rip out anything relating to the touchscreen, make sure it uses PC graphics APIs, reimplement key/button input if it doesn't have it already, and probably a bunch of small things that wouldn't be apparent at first.

But as a way to research implementing Sonic physics in a language like Java, it could perhaps be more useful.

On the main topic: Decompilers for Java (as well as .NET) are pretty common. The reason that they exist and work so well is due to the fact that Java apps/games compile down to the same cross-platform bytecode (like machine language except for a Java Virtual Machine), which is a well-understood and well-researched format. It's known how certain patterns of bytecode correspond to Java syntax.

This is why the modding community around, say, Minecraft (probably the most popular Java game right now) is so goddamn huge. It wasn't because the developers made a nice modding API for everyone to use. It's because Java is in an easily decompiled and deconstructed format, so it was relatively simple to reverse-engineer compared to a natively compiled application.

This post has been edited by Delta: 07 August 2014 - 07:36 PM

[Panko]

If the Java code could be magically converted into a format that is compatible for PC, it is very plausible that a Genesis port could be made. But that is just a theory.

If a port were to happen, there would have to be a lot of streamlining in order to get the game to run with full color (yes, the Genesis is capable of >64 colors, but it's difficult), and plenty of rewriting and debugging. A PC version would be good because users can then create their own hacks/fan-games without using an emulator or running from an unofficial engine.

The physics are an important part of it. Sonic the Hedgehog (Game Boy Advance) was based on the Sonic Advance engine, and it had quite a few issues dealing with momentum and underwater movement.

[MainMemory]

Panko, on 13 August 2014 - 04:19 PM, said:

If the Java code could be magically converted into a format that is compatible for PC, it is very plausible that a Genesis port could be made. But that is just a theory.

I don't follow. How does a PC port bring us any closer to a Genesis port? The code would still be Java, so you'd have to convert it to 68000 ASM either way, which is just as possible (read: extremely time consuming and difficult) with the Android version's decompiled code. You'd also have to reduce the colors from 32 palettes (16 plane palettes and 16 sprite palettes) to four palettes per level, remove all rotation and scaling effects, and possibly reduce the number of tiles.

[Panko]

The Genesis is capable of more than 32/64 colors on-screen. And, yes, it would be very time consuming.

Here is video proof of >64 colors:

[GerbilSoft]

Panko, on 14 August 2014 - 02:07 PM, said:

The Genesis is capable of more than 32/64 colors on-screen. And, yes, it would be very time consuming.

Here is video proof of >64 colors:

How about just a plain old screenshot?



The underwater segment uses a completely separate 64-color palette compared to the above-water segment.

Color limitations aren't the hardest part of porting Sonic Advance from Android to MD. The limiting factor is it's Java. Rewriting Java to 68000 assembly language (or any assembly language, for that matter) is very time-consuming. Even using C instead of assembly language (using one of the various C compilers available for MD) would still take a good long time, since a lot of Java functionality isn't available.

This post has been edited by GerbilSoft: 14 August 2014 - 02:24 PM
Reason for edit: +link

[Clownacy]

And here I was thinking that all high level languages were the same... Is it because interpreted languages (if that's even the word) are more flexable than compiled languages or something?

This post has been edited by Clownacy: 14 August 2014 - 02:37 PM

[GerbilSoft]

Clownacy, on 14 August 2014 - 02:25 PM, said:

EAnd here I was thinking that all high level languages were the same... Is it because interpreted languages (if that's even the work) are more flexable than compiled languages or something?

Java has all sorts of object-oriented stuff like polymorphism and reflection. Some of this is relatively easy to port to procedural languages like C, but reflection is extremely painful and time-consuming. (Reflection is basically querying an object to determine what methods and fields it has, which requires storing that data somewhere and providing a standard interface for querying it.)

I haven't actually looked at the Sonic Advance decompiled source to see if it uses reflection, but it probably does use polymorphism aka inherited classes, where one class is a 'base' class that provides a common interface, and other classes derive from it to add specific functionality. This can be replicated in C, but it's somewhat annoying to do so. (Look up how Microsoft's COM system works in C and you'll know what I mean.)

[Jeffery Mewtamer]

I would imagine a Java Virtual Machine would be too resorce intensive for the Genesis, even if you stripped out anything Advance doesn't use, but Are there no C++ to 68k machine code compilers? Not that a Java to C++ rewrite is easy per se, but the two do have similar syntax and have comparable levels of object orientedness.

[Shalpp]

evilhamwizard, on 25 July 2014 - 12:31 PM, said:

Puto, on 25 July 2014 - 12:26 PM, said:

So why does the MID directory have Sonic 4 Episode 1 music?

See bgm_49_boss_f1.mid for instance which is the EGG Station song.

The original used a bunch of Sonic 1/2 music for X-Zone boss fights. I'm guessing they replaced the music with stuff from Sonic 4 since they knew it was everybody's favorite soundtrack.

My guess is they didn't have the license to Nakamura's tracks like they did for the first Sonic Advance.

[Montblanc]

They already removed some of the old tracks back then when the game was re-released for the N-Gage.

[Sodaholic]

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.

This post has been edited by Sodaholic: 15 September 2014 - 09:59 PM

[Shalpp]

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)

[Overlord]

Indeed you can, and for some reason not only is this not mentioned in the manual (EU at least), but wasn't on Sonic Advance 3 either - added.