Anyone wanna help me make a SNES → C code converter? (yeah, for real)

[93143]

many specialty uses of the hardware are to get it to do something it doesn't have the system resources to do

That's great and all, but this is starting to sound less like an automated tool to convert SNES programs into C and more like "just rewrite the game from scratch yourself". SNES ROMs contain no indications of intent; how would the converter figure out these high-level refactoring concepts?

[segaloco]

That's why I've asked ad nauseam what the use case here is. Whether this is the direction taken is highly dependent on what the end goal is, C that recreates the way the engine behaves, C that makes a reasonable estimation on some other piece of hardware, C that one can write for like they're writing for the SNES, C someone can write for like they're writing for OpenGL, there are an incredible number of variables that inform what the goal is. This discussion can't get more focused if the goal isn't more focused.

So yes, that is a tool to "rewrite the game" because "rewrite the game" vs "SNES asm to SNES C" vs "ahead-of-time compilation with core emulation" vs etc has not been settled yet.

[Myself086]

OP's goal is to convert SNES to PC and not the other way around.

We had a conversation going in Discord DM and I gave up when we were almost done using the reset vector.

[Oziphantom]

That's why I've asked ad nauseam what the use case here is. Whether this is the direction taken is highly dependent on what the end goal is, C that recreates the way the engine behaves, C that makes a reasonable estimation on some other piece of hardware, C that one can write for like they're writing for the SNES, C someone can write for like they're writing for OpenGL, there are an incredible number of variables that inform what the goal is. This discussion can't get more focused if the goal isn't more focused.

So yes, that is a tool to "rewrite the game" because "rewrite the game" vs "SNES asm to SNES C" vs "ahead-of-time compilation with core emulation" vs etc has not been settled yet.

I think it is fairly clear that the point of this exercise to do the "decomp" projects that are all the range on N64 games to the SNES. So you can make better versions of them. I.e MMX NTSC no slowdown and in widescreen.

Typically how the PS1/N64 decomps work is that you have a "runtime" that mimic the N64/PS1 hardware environment and makes the game run. So you would need to convert the SNES game to C and then provide a "SNES runtime" to handle all of the details. However this would still be a get you 80%~90% of the way there and then you have to modify the code to actually handle the edge cases and run the game properly. However this is done at the C level so its a lot easier to do. I.e rather than having an IRQ that does a split and enabled Mode 5 for the text boxes in SD3, you just remove the code and make the text box rendering code draw at 512 pixels directly, removing the hole IRQ system in the process.

[segaloco]

Well and that's what I'm getting at, the decision between emulating the behaviors of raster scanlines so you can transliterate the code directly to C vs. rewriting the algorithms to achieve the same abstract effect but in a way more native to the host rather than the original platform. One approach means just turning 65816 code into C and getting your pointers to the static variables representing "registers" in the peripheral cores in the right places. The other means rewriting whole subroutines to "do the same thing" but with, say, OpenGL textures and X11 pixmaps rather than replacing a buffer feeding a scanline generator at a precise moment in the raster generation. This becomes highly game-dependent since the more creative and complex a PPU/VDP-type operation is, the less likely the exact code is to map over some wholly different graphics interface like modern vertex/fragment systems.