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.

 

[Tiviat]

Nahhh.....I'm pretty sure that the before ANY resolution drops or adjustments for ANY of those game's assets, you're just going to have to literally cut down the animation of everything first and foremost. Sonic's animations are utterly ridiculous in length and resolution, the stages animation and size are ginormous. In short,,before ANY sprite conversions of any kind, you're gonna have to put the ENTIRE game under the axe, just to make sure most it fits. Good luck with this though guys, I'm certain it'll look great. But it's gonna be a tight fit😉😉😉

 

[TrekkiesUnite118]

Nahhh.....I'm pretty sure that the before ANY resolution drops or adjustments for ANY of those game's assets, you're just going to have to literally cut down the animation of everything first and foremost. Sonic's animations are utterly ridiculous in length and resolution, the stages animation and size are ginormous. In short,,before ANY sprite conversions of any kind, you're gonna have to put the ENTIRE game under the axe, just to make sure most it fits. Good luck with this though guys, I'm certain it'll look great. But it's gonna be a tight fit😉😉😉

To be clear, this isn't an actual project yet. This is just talking about what would need to be done to make it a reality. Secondly you could probably get the animations to work with what was already suggested. Sonic's animations for example have a lot duplicate frames that are just mirrored, and only copying what you need over to VRAM you could make it work. The bigger issue is dealing with the lack of texture coordinates and the odd sizes for some of the sprites.

 

[nando]

To be clear, this isn't an actual project yet. This is just talking about what would need to be done to make it a reality. Secondly you could probably get the animations to work with what was already suggested. Sonic's animations for example have a lot duplicate frames that are just mirrored, and only copying what you need over to VRAM you could make it work. The bigger issue is dealing with the lack of texture coordinates and the odd sizes for some of the sprites.

I've been messing with the tile loader for jo engine - I think it wouldn't be that hard actually. you don't really need texture coordinates, but instead you load the tile sizes dynamically (which would have to be done for each tilemap). it also makes it easier for animations, and yeah we can just hardware flip the mirrored tiles. probably you'd want to do that at compile time too, and not on the hardware.

I'm busy working on the competition, but I might try a test of just like, Sonic or something next year. I already made a script to convert all of the images to a Saturn-friendly format / reduced color depth.

 

[TrekkiesUnite118]

I've been messing with the tile loader for jo engine - I think it wouldn't be that hard actually. you don't really need texture coordinates, but instead you load the tile sizes dynamically (which would have to be done for each tilemap). it also makes it easier for animations, and yeah we can just hardware flip the mirrored tiles. probably you'd want to do that at compile time too, and not on the hardware.

I'm busy working on the competition, but I might try a test of just like, Sonic or something next year. I already made a script to convert all of the images to a Saturn-friendly format / reduced color depth.

How would you get the individual sprite frames out of the sprite sheets without texture coordinates? They're not stored like your typical sprite sheet on the Saturn where each frame is it's own individual image concatenated together. It's one giant 512x512 image with all the frames stored in it:

At the very minimum we'd need to rework these to be in a format that can actually work on Saturn. You could possibly do software texture coordinates on the CPU to cut each frame out and send to VRAM, but that could add a lot of unnecessary overhead on the CPU.

 

[Tiviat]

To be clear, this isn't an actual project yet. This is just talking about what would need to be done to make it a reality. Secondly you could probably get the animations to work with what was already suggested. Sonic's animations for example have a lot duplicate frames that are just mirrored, and only copying what you need over to VRAM you could make it work. The bigger issue is dealing with the lack of texture coordinates and the odd sizes for some of the sprites.

I hear you loud and clear !! But just taking a head count over the general size of such a task is an important step nonetheless, as such an simple observation of the things that would have to work with is important with all porting decisions. i was basically saying that cutting a few corners here and there in the beginning would just encourage a little headroom if things get outta hand later on , if you decided to go through with making it a reality. But anyway, I'm sure that the Saturn is easily up for more than a good portion of that task anyway. Whenever I would hear that Capcom had decided to make home versions of their crossover fighters...it was pretty obvious that sprite size and animation were the first to be sacrificed for ports on lower end hardware.They even had to drop some animation and some resolution on the SF3 Arcade--->Dreamcast ports, which at first glance was BARELY noticeable, unless the screen zoomed in.

 

[Tiviat]

How would you get the individual sprite frames out of the sprite sheets without texture coordinates? They're not stored like your typical sprite sheet on the Saturn where each frame is it's own individual image concatenated together. It's one giant 512x512 image with all the frames stored in it:
View attachment 10402View attachment 10403

At the very minimum we'd need to rework these to be in a format that can actually work on Saturn. You could possibly do software texture coordinates on the CPU to cut each frame out and send to VRAM, but that could add a lot of unnecessary overhead on the CPU.

You might have to just delete that white background, and painstakingly pull out all of them individually, for starters

 

[TrekkiesUnite118]

I hear you loud and clear !! But just taking a head count over the general size of such a task is an important step nonetheless, as such an simple observation of the things that would have to work with is important with all porting decisions. i was basically saying that cutting a few corners here and there in the beginning would just encourage a little headroom if things get outta hand later on , if you decided to go through with making it a reality. But anyway, I'm sure that the Saturn is easily up for more than a good portion of that task anyway.

Cutting those corners would require just as much work as you'd still need to modify all the same files and make the same modifications to the overall engine itself.

Whenever I would hear that Capcom had decided to make home versions of their crossover fighters...it was pretty obvious that sprite size and animation were the first to be sacrificed for ports on lower end hardware.They even had to drop some animation and some resolution on the SF3 Arcade--->Dreamcast ports, which at first glance was BARELY noticeable, unless the screen zoomed in.

The Dreamcast and Saturn ports of the Marvel vs Capcom series have all the frames of animation at the same resolution as the arcade. What's different on Saturn is the overall resolution is 352x224 instead of 384x224 so you lose about 16 pixels on the edge of the screen resulting in characters going off screen a little sooner.

You might have to just delete that white background, and painstakingly pull out all of them individually, for starters

That's exactly what I already said.