Viability of Porting Sonic Mania

[TrekkiesUnite118]

So this has been discussed in the discord and the people doing the Dreamcast port have mentioned they keep getting people asking about a Saturn port in comments. So I figured this might not be a bad thread to have to discuss the possibility of porting Mania to the Saturn as well as pointing out key issues and concerns with the game that would need to be addressed. At the very least it can be a go to resource to point people to when they ask about if it can be done.

Briefly looking over the source code and the assets, these are the issues that have jumped out at me:

• All the assets would need to be reworked to be in a Saturn Friendly format.
  • All the games tilesets, sprite sheets, etc. are paletted GIF files.
  • The sprite sheets are based around having texture coordinates which we don't have on Saturn. So they'd need to be remade with Saturn's lack of texture coordinates in mind.
  • The sprites are not in Saturn friendly sizes. Saturn sprites need to have their texture width be divisible by 8. Many of the sprite frames in Sonic Mania do not adhere to this. So they would need to be properly resized to these limits.
    • This would also require reworking the binary files with these sprite sheets to have the new updated sizes.
  • Some sprites appear to be more than 16 colors per frame. While we can do 8bpp and 15-bit RGB on Saturn this would probably eat into our already limited RAM. So sprites and possibly tiles would need to be reworked to 4bpp. This could be done either by color reduction or splitting them into smaller pieces that use different palettes.
  • Certain graphical effects and transparencies may be difficult or not possible.
  • Music is in Ogg format. As far as I'm aware even Dreamcast struggles to decode this so this would most likely need to go for an ADPCM based format.
  • FMVs use the Theora codec and would need to be re-encoded to something Saturn actually has a chance at decoding.
• The game's rendering code seems to be entirely based around software rendering.
  • As far as I can tell the other ports all work by simply creating a new RenderDevice using SDL, Direct X, Vulkan, etc. to display the updated frame buffer that the software renderer draws.
  • The software rendering itself looks to start in the Scene and Object code and is then handed off to the different drawing classes in Graphics. Eventually these hand the final frame off to the RenderDevice if I'm following things correclty.
  • In order to do a Saturn port this would need to be completely reworked to use VDP2 background layers and VDP1 sprites.

So far these are the issues that have jumped out at me. If others have ones they'd like to add or correct me on feel free to do so. I'll expand on this if anything else jumps out at me.

Overall I wouldn't say it's impossible, but it would require a lot of work and most likely more than just one person is capable of realistically doing in their free time.

 

[Malenko]

I would be more than happy to rework the sprites, I am assuming that centering the sprites on a chroma-keyed background with a size divisible by 8 would do? (ie sprite is 38x30 I center it on a pink 40x32 tile). Reworking them down to a 4bpp wouldn't be difficult for me either.

 

[Knight0fDragon]

I would be more than happy to rework the sprites, I am assuming that centering the sprites on a chroma-keyed background with a size divisible by 8 would do? (ie sprite is 38x30 I center it on a pink 40x32 tile). Reworking them down to a 4bpp wouldn't be difficult for me either.

This is where learning python comes in handy. A GIMP plugin could do this for you easily.

Depending on space, it may make more sense to scale the sprite and then let the hardware fatten them back up. You are going to have to rely on hardware scaling anyway if you plan on keeping the games wide screen resolution.

 

[TrekkiesUnite118]

This is where learning python comes in handy. A GIMP plugin could do this for you easily.

Depending on space, it may make more sense to scale the sprite and then let the hardware fatten them back up. You are going to have to rely on hardware scaling anyway if you plan on keeping the games wide screen resolution.

The game actually natively supports 4:3 resolution and can be set to draw properly in that resolution. It does it properly without scaling and has the game scroll more when necessary. This is what the Wii Port does if it's set to 4:3.

 

[Knight0fDragon]

The game actually natively supports 4:3 resolution and can be set to draw properly in that resolution. It does it properly without scaling and has the game scroll more when necessary. This is what the Wii Port does if it's set to 4:3.

Wii is actually not capable of doing 16:9 either, so what you typically had to do was software render to a 16:9 buffer, then scale that down to 4:3. and let the TV hardware scale it back to 16:9. We definitely do not have the RAM in Saturn to do that.

 

[TrekkiesUnite118]

Wii is actually not capable of doing 16:9 either, so what you typically had to do was software render to a 16:9 buffer, then scale that down to 4:3. and let the TV hardware scale it back to 16:9. We definitely do not have the RAM in Saturn to do that.

Yes, what I'm saying is the Wii port of Mania will set the game to run in 4:3 aspect ratio if the Wii isn't set to 16:9. So the game actually renders correctly in 4:3 with everything aligned correctly without any scaling. The engine will crop the sides to 4:3 and render in a 320x240 frame buffer instead of the 426x240 frame buffer it uses in 16:9. It will then adjust the HUD elements to be in frame and scroll more when necessary.

So we shouldn't need to worry about that with the assets.

 

[Knight0fDragon]

I am just saying if you want to support the wide screen mode it may be beneficial to scale down the sprites instead of adding empty space to account for the 8Npx width limitation.

 

[TrekkiesUnite118]

I am just saying if you want to support the wide screen mode it may be beneficial to scale down the sprites instead of adding empty space to account for the 8Npx width limitation.

I think that would probably look pretty bad. The assets are all designed around the classic sonic games resolution. Maybe having a separate set of wide-screen sprites could work, but you also have the issue of VDP2 layers needing to be squished as well which could get pretty messy with tilemaps. And not all layers can be scaled either if i remember correctly.

Overall it would probably be best to just set it to 4:3 aspect ratio and not have a widescreen option. There's a reason why widescreen generally wasn't done on 2D games on Saturn.

 

[black_kawa]

Which effects couldnt be plausible on the console? Transparency i understand since is the achilles heel of the machine, but i dont remember much advanced 2d effects on mania. You are talking about sprite rotation?

 

[TrekkiesUnite118]

Which effects couldnt be plausible on the console? Transparency i understand since is the achilles heel of the machine, but i dont remember much advanced 2d effects on mania. You are talking about sprite rotation?

There's quite a bit of transparency effects last I checked. The bouncy/wavy chemical pools in Chemical Plant Zone also might be tricky to pull off on Saturn. Not only are they transparent but the way they animate might be an issue. I'm not sure if they're being done with a 3D mesh or if they're simply relying on software rendering to plot each pixel. Another is the color inversion effect that happens at the start of some levels. While palette swapping would be doable I'm not sure about how it's done spreading out in a circle when VDP2 layers and sprites are involved. Finally there may be points where there could be more background layers than we can actually do on Saturn.

The key word in that statement was "maybe". Until we really dig in and see how each effect works we wont know if it's possible or how challenging they would be to pull off. This is simply pointing out possible issues.

 

[vbt]

I would be more than happy to rework the sprites, I am assuming that centering the sprites on a chroma-keyed background with a size divisible by 8 would do? (ie sprite is 38x30 I center it on a pink 40x32 tile). Reworking them down to a 4bpp wouldn't be difficult for me either.

it's just rounding on the fly and you don't modify the assets

 

[TrekkiesUnite118]

it's just rounding on the fly and you don't modify the assets

The assets would need to be reworked anyways because they're gifs that rely on texture coordinates.

 

[TrekkiesUnite118]

So continuing to snoop around at the assets a couple other things I've noticed:

• Levels use a single tileset of 1024 16x16 tiles that are 8bpp. So uncompressed that would take up about 256KB of space, which is half of VDP2 VRAM. From what I can tell it looks like levels have a max of 4 scrolling layers. So that might be able to work on VDP2 with just converting the tiles and their shared palette over to a Saturn format and keeping them 8bpp. But I'm not entirely sure.
• Sprites are all 8bpp. These would most likely need to be completely redone and broken down into smaller pieces. For example the common sprite sheet has a ton of duplicate images that simply use different colors as well as having all the icons for each character in them. So it would probably make sense to break those into smaller pieces so we'd only need to load what we actually need. Individual character sprite sheets also have a lot of duplicate frames in them that could probably be replaced with mirroring or rotating the sprites when drawing them. Animations that are simple color changes could probably be redone to use different palettes instead.

The sprites appear to be what the real issue would be. At the very least we would need to convert these over to not rely on texture coordinates. That would also require modifying the binary data that is used to tell the game which frame of animation is where in the sprite sheet. If we decided to try and reduce the size by getting rid of duplicate frames and relying on mirroring, palette swaps, etc. we would need to modify the animation data to be able to express that. We would also most likely need to use compression to be able to fit everything in RAM and hope it's fast enough to decompress each animations frames on the fly.