Porting to Saturn

[iamsiincere]

Hello

I'm very much a noob when it comes to programming but I'm a massive Saturn fan. I was advised to come on here and seek out someone (XL2) for advise on a question I have.

I've always been curious about either using the available tools to reverse engineer games to be able to access things like music files or background sprites (like a stage on SFZ3) or being able to port a game to Saturn that can realistically be ported.

I'm curious of where I would start to learn. I don't have a background in programming but I'm good with tech and picking up things.

 

[Ponut]

Hello.

I will start by dropping a pretty hard line that trying to port a 3D game is probably one of the hardest things you could try to do without significant experience on programming for either the original or target platform. Porting a 2D game can be a lot simpler. In either case, you need access to the source code.

To start learning, you can try the JoEngine SDK. It's simple in that it unpacks with a samples folder that you can execute one batch file to compile them, see what they do, and mess with them to learn how they work. If you really just want to get started, don't waste any time and go here: Jo Sega Saturn Engine, Sega Saturn SDK for homebrews
It's very important to note that JoEngine is not an engine. It is not an IDE either. You will be working with text. No trustworthy GUI toolchains exist. It is a wrapper for SGL functions; SGL is an official SEGA library.

More advanced users should trend toward using Yaul, found at GitHub - yaul-org/libyaul: An open source SEGA Saturn development kit
I'm pointing you there because yaul.org doesn't introduce you to it.

As for reverse engineering games, this is a separate discipline. It involves searching through binary files looking for data structures that resemble hardware-compatible formats or other standardized formats. Failing that it's looking at the RAM of a game running and following the breadcrumbs that lead to the stored data for a particular on-screen asset, which often times are compressed in unfamiliar ways.

 

[iamsiincere]

Hello.

I will start by dropping a pretty hard line that trying to port a 3D game is probably one of the hardest things you could try to do without significant experience on programming for either the original or target platform. Porting a 2D game can be a lot simpler. In either case, you need access to the source code.

To start learning, you can try the JoEngine SDK. It's simple in that it unpacks with a samples folder that you can execute one batch file to compile them, see what they do, and mess with them to learn how they work. If you really just want to get started, don't waste any time and go here: Jo Sega Saturn Engine, Sega Saturn SDK for homebrews
It's very important to note that JoEngine is not an engine. It is not an IDE either. You will be working with text. No trustworthy GUI toolchains exist. It is a wrapper for SGL functions; SGL is an official SEGA library.

More advanced users should trend toward using Yaul, found at GitHub - yaul-org/libyaul: An open source SEGA Saturn development kit
I'm pointing you there because yaul.org doesn't introduce you to it.

As for reverse engineering games, this is a separate discipline. It involves searching through binary files looking for data structures that resemble hardware-compatible formats or other standardized formats. Failing that it's looking at the RAM of a game running and following the breadcrumbs that lead to the stored data for a particular on-screen asset, which often times are compressed in unfamiliar ways.

Thank you a huge chunk for helping me understand my request. I'm aware that it might be a huge task to undertake but I just needed to get some gauge on if I should even think to tackle this. As of, I'm not thinking of porting 3D, specifically 2D. I have a few questions for you and obviously, answer what you feel like answer and I'm ok if you don't know the answer to any of them or if you just don't want to answer.

1. If you have access to a rom or an iso for a given game, is that the first step of getting the original source code? Or would you have to get that somewhere else? (If you know where to TRY and find any, please do share)
2. At the moment, I care about image files and audio files (when it comes to strictly accessing files from a game). As long as you can uncompress the file, is the only barrier a program that can properly display/play said file? For example, I know some games had ogg files for audio and something like foobar can easily play it as well as certain Saturn audio files.
3. From the IT perspective, I know an IDE is a sort of hard drive. In the context of your response, what does that stand for?
4. Reverse engineering, I assume, starts the same way as porting a game? By finding the original source code? Or is that as simple as obtaining the rom/iso?

 

[Ponut]

Well by your answers I'm glad you are asking questions

1. Source code is generally a closely guarded proprietary secret for commercial releases. In some cases, the source code for a release of a game may be lost to time due to the sequel to the game being immediately developed from the same code base without strict versioning to save the state of the code which built a particular release/game. Source code is human-readable and human-written code that is fed through a compiler, usually C or C++. You can't extract it from a release because the release only has compiled code. Even in cases where a game was written in Assembly (*very* rare after 1994), the game as released has the assembled code, not the source assembly code.
You can ATTEMPT to reconstruct functional source code from a game's executable binary (often executable(s)). An "executable binary", in Windows, is what you know as a ".EXE" file. The primary tool for doing this is called Ghidra. Using Ghidra isn't really a learning experience because often Ghidra's output does not compile back into a working executable without extensive massaging and research, particularly in cases when a game has multiple interlocking executables.

2.

is the only barrier a program that can properly display/play said file

Sometimes games store data in customized "libraries". Think of them like zip files, but different. These aren't anti-piracy measures, they are simply made by developers to integrate methods of finding and loading files faster than the host file system can. Or to store files in ways that are more dense than allowed by the host file system. For instance, on a CD, data is stored in 2KB sectors. If you have a bunch of files that are smaller than 2KB, they will all end up taking 2KB of space on the disc, and reading them sequentially will be slow since the CD must adjust itself every time it wants to read the next file (read, stop, seek, read, stop, seek) whereas if it was in a "library" file, the library would describe the files and where they are rather than the files descirbing themselves in the file system, such that reading them sequentially would not span sectors. They could then be read all at once.
If you want examples, Dynamix developed two games at around the same time with very similar engines: TRIBES and StarSiege. Both TRIBES and StarSiege use slightly different versions of a properitary package format called ".vol". It just stands for "volume", like volume of files.
Many Blizzard games store their data in packages called ".MPQ". They used the .MPQ standard all the way up to the initial release of StarCraft 2, with scalable additions in each release. In that case you would be lucky trying to reverse engineer it because it is such a long-running standard.
BattleZone '98 (original) has a completely proprietary file stack format called ".lzf". This shares a name with a common compression schema, but these files are more than just compressed.

Within or without these libraries, you will find data formats which might be completely custom to a specific game.
For instance, Grandia (on Saturn) has a unique video format.

Anyway, my main point is not all the graphics/audio you want will be in a standard format and they may be contained within file packages unique to that specific game. ROMHacking is very much about figuring out those formats and the packages they are in.

For audio and sound though, you may be able to use emulators like SSF/Kronos to just extract the data from the game as it is running, allowing the emulator to convert it for you.

3. IDE, in the programming sense, stands for "Integrated Development Environment". Unreal and Unity are IDEs as well as game engines. CodeBlocks is another example of an IDE, but it isn't a game engine.

4. Ghidra is pretty much the answer to this.

 

[iamsiincere]

Well by your answers I'm glad you are asking questions

1. Source code is generally a closely guarded proprietary secret for commercial releases. In some cases, the source code for a release of a game may be lost to time due to the sequel to the game being immediately developed from the same code base without strict versioning to save the state of the code which built a particular release/game. Source code is human-readable and human-written code that is fed through a compiler, usually C or C++. You can't extract it from a release because the release only has compiled code. Even in cases where a game was written in Assembly (*very* rare after 1994), the game as released has the assembled code, not the source assembly code.
You can ATTEMPT to reconstruct functional source code from a game's executable binary (often executable(s)). An "executable binary", in Windows, is what you know as a ".EXE" file. The primary tool for doing this is called Ghidra. Using Ghidra isn't really a learning experience because often Ghidra's output does not compile back into a working executable without extensive massaging and research, particularly in cases when a game has multiple interlocking executables.

2.


Sometimes games store data in customized "libraries". Think of them like zip files, but different. These aren't anti-piracy measures, they are simply made by developers to integrate methods of finding and loading files faster than the host file system can. Or to store files in ways that are more dense than allowed by the host file system. For instance, on a CD, data is stored in 2KB sectors. If you have a bunch of files that are smaller than 2KB, they will all end up taking 2KB of space on the disc, and reading them sequentially will be slow since the CD must adjust itself every time it wants to read the next file (read, stop, seek, read, stop, seek) whereas if it was in a "library" file, the library would describe the files and where they are rather than the files descirbing themselves in the file system, such that reading them sequentially would not span sectors. They could then be read all at once.
If you want examples, Dynamix developed two games at around the same time with very similar engines: TRIBES and StarSiege. Both TRIBES and StarSiege use slightly different versions of a properitary package format called ".vol". It just stands for "volume", like volume of files.
Many Blizzard games store their data in packages called ".MPQ". They used the .MPQ standard all the way up to the initial release of StarCraft 2, with scalable additions in each release. In that case you would be lucky trying to reverse engineer it because it is such a long-running standard.
BattleZone '98 (original) has a completely proprietary file stack format called ".lzf". This shares a name with a common compression schema, but these files are more than just compressed.

Within or without these libraries, you will find data formats which might be completely custom to a specific game.
For instance, Grandia (on Saturn) has a unique video format.

Anyway, my main point is not all the graphics/audio you want will be in a standard format and they may be contained within file packages unique to that specific game. ROMHacking is very much about figuring out those formats and the packages they are in.

For audio and sound though, you may be able to use emulators like SSF/Kronos to just extract the data from the game as it is running, allowing the emulator to convert it for you.

3. IDE, in the programming sense, stands for "Integrated Development Environment". Unreal and Unity are IDEs as well as game engines. CodeBlocks is another example of an IDE, but it isn't a game engine.

4. Ghidra is pretty much the answer to this.

Interesting. I might be stuck then. My biggest goal since the MiSTer Project got Neo Geo was to port Street Fighter 3 (any version) to the Sega Saturn. I been hoping to eventually get to that point, even if I had to start with a more simple game.