[demo] SNES Sonic

A place where you can keep others updated about your SNES-related projects through screenshots, videos or information in general.

Moderator: Moderators

TiagoSC
Posts: 25
Joined: Sun Feb 26, 2017 3:44 pm

Re: [demo] SNES Sonic

Post by TiagoSC »

Ray01 wrote: Tue Aug 30, 2022 12:19 am This 2D Sonic engine for PS1 and Saturn is really stunning!
Is it open source?

The fellows from the (recently very much growing) 3DO community might be interested.
Thanks! These ports are open source:

Sonic1 for PC
https://github.com/cuckydev/SoniCPort

Sonic1 for Sega Saturn
https://github.com/Ced2911/sonic-c-saturn

Sonic Mania
https://github.com/Rubberduckycooly/Son ... ompilation
User avatar
Individualised
Posts: 309
Joined: Mon Sep 05, 2022 6:46 am

Re: [demo] SNES Sonic

Post by Individualised »

There's also PS1 Sonic from the same developer as the Windows and Saturn ports: https://github.com/cuckydev/PSXSoniCPort This one seems to have been more active recently so I thought I'd post it.
SNES AYE
Posts: 201
Joined: Mon Nov 07, 2022 11:28 am

Re: [demo] SNES Sonic

Post by SNES AYE »

TiagoSC wrote: Sat Aug 06, 2022 7:43 am I'm not porting the complete Sonic to the SNES because the snes sprite limits really complicate porting 1:1, as I use 8x8/16x16 sprites to maximize the 512 sprite tiles, it would be difficult to make the large objects of the next stages.
What large objects made from sprites are you referring to that would have caused an issue in that level, and what issue specifically (would it be avoiding hitting the max sprites per scanline before flicker limit maybe)?
User avatar
Individualised
Posts: 309
Joined: Mon Sep 05, 2022 6:46 am

Re: [demo] SNES Sonic

Post by Individualised »

SNES AYE wrote: Sun Feb 12, 2023 3:59 pm
TiagoSC wrote: Sat Aug 06, 2022 7:43 am I'm not porting the complete Sonic to the SNES because the snes sprite limits really complicate porting 1:1, as I use 8x8/16x16 sprites to maximize the 512 sprite tiles, it would be difficult to make the large objects of the next stages.
What large objects made from sprites are you referring to that would have caused an issue in that level, and what issue specifically (would it be avoiding hitting the max sprites per scanline before flicker limit maybe)?
Unlike the Mega Drive which allows all of its sprite sizes to be used at once the SNES only lets you choose 2 of its sprite sizes at once which are used for all sprites on screen. This complicates things when porting games from Mega Drive and can cause sprite limit issues even though the SNES can technically push more sprites than the Mega Drive. This is pretty much the main drawback of the SNES PPU compared to the Mega Drive VDP, along with the lower resolution. Otherwise the SNES PPU can theoretically render everything from Sonic perfectly.

I'm not anywhere near done with even learning NES development yet, but once I do and eventually move on to SNES development I'd like to try and port games from other 16-bit platforms, using the original code rather than a remake, in order to test and improve my skill. Maybe if no one else gets there first I'd have a go at trying to port over Sonic 1. I'm of the opinion that it can be done and match closely with the original game. But of course we're talking about the far future here.
SNES AYE
Posts: 201
Joined: Mon Nov 07, 2022 11:28 am

Re: [demo] SNES Sonic

Post by SNES AYE »

Individualised wrote: Sun Feb 12, 2023 4:06 pm
SNES AYE wrote: Sun Feb 12, 2023 3:59 pm
TiagoSC wrote: Sat Aug 06, 2022 7:43 am I'm not porting the complete Sonic to the SNES because the snes sprite limits really complicate porting 1:1, as I use 8x8/16x16 sprites to maximize the 512 sprite tiles, it would be difficult to make the large objects of the next stages.
What large objects made from sprites are you referring to that would have caused an issue in that level, and what issue specifically (would it be avoiding hitting the max sprites per scanline before flicker limit maybe)?
Unlike the Mega Drive which allows all of its sprite sizes to be used at once the SNES only lets you choose 2 of its sprite sizes at once which are used for all sprites on screen. This complicates things when porting games from Mega Drive and can cause sprite limit issues even though the SNES can technically push more sprites than the Mega Drive. This is pretty much the main drawback of the SNES PPU compared to the Mega Drive VDP, along with the lower resolution.
Still, I wonder where that specifically crops up in Sonic on the second level for example. With the HUD using BG3, saving even just a few sprites there, and going with the 16x16 sprite tiles, I'm not sure exactly where it wouldn't be possible to display certain objects in the second level due to running out of sprites, be it going over the max on-screen or max per scanline. Not that I've counted. Same goes for checking how far he's went with the dynamic VRAM usage for swapping sprite tiles on the fly if that's causing some issues too. But I'm not running any code or checking in a debugger, just asking if there's an example he can quickly point me to so I can see where he found it was going to be an issue. Just curious really.

Edit: Hey, I'd love to see your attempt at porting Sonic 1 to SNES. And there's a great base to start from with the magic the TiagoSC has done. :D
User avatar
Individualised
Posts: 309
Joined: Mon Sep 05, 2022 6:46 am

Re: [demo] SNES Sonic

Post by Individualised »

SNES AYE wrote: Sun Feb 12, 2023 4:25 pm
Individualised wrote: Sun Feb 12, 2023 4:06 pm
SNES AYE wrote: Sun Feb 12, 2023 3:59 pm
What large objects made from sprites are you referring to that would have caused an issue in that level, and what issue specifically (would it be avoiding hitting the max sprites per scanline before flicker limit maybe)?
Unlike the Mega Drive which allows all of its sprite sizes to be used at once the SNES only lets you choose 2 of its sprite sizes at once which are used for all sprites on screen. This complicates things when porting games from Mega Drive and can cause sprite limit issues even though the SNES can technically push more sprites than the Mega Drive. This is pretty much the main drawback of the SNES PPU compared to the Mega Drive VDP, along with the lower resolution.
Still, I wonder where that specifically crops up in Sonic on the second level for example. With the HUD using BG3, saving even just a few sprites there, and going with the 16x16 sprite tiles, I'm not sure exactly where it wouldn't be possible to display certain objects in the second level due to running out of sprites, be it going over the max on-screen or max per scanline. Not that I've counted. Same goes for checking how far he's went with the dynamic VRAM usage for swapping sprite tiles on the fly if that's causing some issues too. But I'm not running any code or checking in a debugger, just asking if there's an example he can quickly point me to so I can see where he found it was going to be an issue. Just curious really.

Edit: Hey, I'd love to see your attempt at porting Sonic 1 to SNES. And there's a great base to start from with the magic the TiagoSC has done. :D
Since TiagoSC's demo isn't a straight port it's likely something to do with their specific engine. As for Marble Zone in particular it has a lot of large, sprite-based moving marble/glass columns which would heavily contribute to the number of sprites used.

Don't expect Sonic SNES from me for a long while (or any SNES homebrew for that matter) :P. If I were to do it though I'd try to make it as straight of a port as possible so I wouldn't be using BG3 for the HUD, as the sprite based HUD in the original is actually technically a special level object - I wouldn't want to mess with game logic than more than is necessary. Plus, if I'm not mistaken in my memory (I sure hope it's not sprite based otherwise I've made a fool of myself...) offset per tile is used by Sonic 1 in Final Zone, so Mode 2, which doesn't have BG3 (and is actually the closest to the Mega Drive's standard mode, so it's perfect for porting MD games) could not be used. Though I suppose Mode 1 (same as Mode 2 but with BG3 and no offset per tile) could be enabled for other levels, but I'd rather use it for special effects, like true transparent waterfalls in GHZ.

As I implied before, the main issue with porting Sonic to SNES is not to do with the "front-end" stuff (so the graphics and sound) as that can all be easily replicated on the SNES, Sonic does not do anything special with the Mega Drive VDP that cannot be reproduced by the SNES. It's the back-end stuff, the main game logic, as Sonic uses a lot of mathematical functions which are not available or do not perform as well on SNES. This was an issue for TiagoSC's game as mentioned by them. Super Mario World on Megadrive would have the opposite problem, game logic would be easy to port from 65816 to 68000 but the game uses a lot of advanced graphical effects that the Megadrive VDP cannot reproduce in hardware, so a lot of stuff would have to be done in software (which fortunately the Mega Drive is powerful enough to do a lot of special effects in software - the question is can it handle doing it at the same time as the ported game logic? Heavy optimisations to the game logic may be required) or compromised in some other way.
SNES AYE
Posts: 201
Joined: Mon Nov 07, 2022 11:28 am

Re: [demo] SNES Sonic

Post by SNES AYE »

Individualised wrote: Sun Feb 12, 2023 4:51 pm
SNES AYE wrote: Sun Feb 12, 2023 4:25 pm
Individualised wrote: Sun Feb 12, 2023 4:06 pm
Unlike the Mega Drive which allows all of its sprite sizes to be used at once the SNES only lets you choose 2 of its sprite sizes at once which are used for all sprites on screen. This complicates things when porting games from Mega Drive and can cause sprite limit issues even though the SNES can technically push more sprites than the Mega Drive. This is pretty much the main drawback of the SNES PPU compared to the Mega Drive VDP, along with the lower resolution.
Still, I wonder where that specifically crops up in Sonic on the second level for example. With the HUD using BG3, saving even just a few sprites there, and going with the 16x16 sprite tiles, I'm not sure exactly where it wouldn't be possible to display certain objects in the second level due to running out of sprites, be it going over the max on-screen or max per scanline. Not that I've counted. Same goes for checking how far he's went with the dynamic VRAM usage for swapping sprite tiles on the fly if that's causing some issues too. But I'm not running any code or checking in a debugger, just asking if there's an example he can quickly point me to so I can see where he found it was going to be an issue. Just curious really.

Edit: Hey, I'd love to see your attempt at porting Sonic 1 to SNES. And there's a great base to start from with the magic the TiagoSC has done. :D
Since TiagoSC's demo isn't a straight port it's likely something to do with their specific engine. As for Marble Zone in particular it has a lot of large, sprite-based moving marble/glass columns which would heavily contribute to the number of sprites used.

Don't expect Sonic SNES from me for a long while (or any SNES homebrew for that matter) :P. If I were to do it though I'd try to make it as straight of a port as possible so I wouldn't be using BG3 for the HUD, as the sprite based HUD in the original is actually technically a special level object - I wouldn't want to mess with game logic than more than is necessary. Plus, if I'm not mistaken in my memory (I sure hope it's not sprite based otherwise I've made a fool of myself...) offset per tile is used by Sonic 1 in Final Zone, so Mode 2, which doesn't have BG3 (and is actually the closest to the Mega Drive's standard mode, so it's perfect for porting MD games) could not be used. Though I suppose Mode 1 (same as Mode 2 but with BG3 and no offset per tile) could be enabled for other levels, but I'd rather use it for special effects, like true transparent waterfalls in GHZ.

As I implied before, the main issue with porting Sonic to SNES is not to do with the "front-end" stuff (so the graphics and sound) as that can all be easily replicated on the SNES, Sonic does not do anything special with the Mega Drive VDP that cannot be reproduced by the SNES. It's the back-end stuff, the main game logic, as Sonic uses a lot of mathematical functions which are not available or do not perform as well on SNES. This was an issue for TiagoSC's game as mentioned by them. Super Mario World on Megadrive would have the opposite problem, game logic would be easy to port from 65816 to 68000 but the game uses a lot of advanced graphical effects that the Megadrive VDP cannot reproduce in hardware, so a lot of stuff would have to be done in software (which fortunately the Mega Drive is powerful enough to do a lot of special effects in software - the question is can it handle doing it at the same time as the ported game logic? Heavy optimisations to the game logic may be required) or compromised in some other way.
From a quick scan through the Marble Zone level (first part at least), I wonder if those pillars are maybe the only place where there would be a genuine issue with potentially running out of sprites and having to find some way to work around that. If so, I think it would have been worth making the rest of the level anyway and then figuring out how to solve that one remaining puzzle down the line.

At a glance, it looks like it would certainly be possible to at least get two of the pillars in there without too much fuss, which is a start. And, I know it would be amazing to get a perfect 1:1 port, but it's not like that's the only option or it's not worth bothering. I've seen plenty of great Genesis ports that compromise in various ways but are still pretty stunning ultimately and leave fans very satisfied. The recent Final Fight port being a perfect example, where even on the first level, the background B skyscraper tiles had to be pushed down the screen and augmented with some choice sprites to accommodate the HUD requiring the use of a large chunk of background A. So, if it really isn't possible to get all three pillars on-screen on SNES, I think a few small concensions well-executed like that would be acceptable in a SNES version of Sonic. That could be in the form of maybe spacing the pillars slightly further apart in that particular section, so there's only ever two on-screen at once for example, or possibly using background tiles for the middle chunks of the pillars (Edit: I actually think that would work, and potentially be a really simple solution*), or something along those lines. I'd take either of those. And it doesn't look like there's too much going on in that section of the level, so I'd imagine a solution like that would be pretty easy going on the SNES' CPU.

Anyway, if you do ever give it a go yourself, that could be at least one approach to overcoming that particular problem--years into the future. :)

*There's no actual animation or visible movement going on in that section of the pillar anyway, other than the simple overlaid reflection effect that could just be baked into the pillar on SNES, or actually still use sprites if there's now enough spare with big chunks of the pillars not using them, or maybe even use a combination of masks and the colour window for a more convincing reflection effect:
PillarBGTiles.png
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: [demo] SNES Sonic

Post by 93143 »

It seems to me that you could use Mode 2 for this.

I believe you can control which row of the BG3 tilemap is used for column scroll by adjusting BG3VOFS, which is accessible to HDMA. Instances where the foreground is seen behind a large moving object (such as the lava behind those partly transparent columns) look like they could mostly be handled by using HDMA to repurpose BG2. The HUD would have to be sprites at least part of the time...

Of course, since column scroll doesn't apply to the first column on the left, you'd have to control that with HDMA to the actual BG1VOFS value.
TiagoSC
Posts: 25
Joined: Sun Feb 26, 2017 3:44 pm

Re: [demo] SNES Sonic

Post by TiagoSC »

SNES AYE wrote: Sun Feb 12, 2023 3:59 pm
TiagoSC wrote: Sat Aug 06, 2022 7:43 am I'm not porting the complete Sonic to the SNES because the snes sprite limits really complicate porting 1:1, as I use 8x8/16x16 sprites to maximize the 512 sprite tiles, it would be difficult to make the large objects of the next stages.
What large objects made from sprites are you referring to that would have caused an issue in that level, and what issue specifically (would it be avoiding hitting the max sprites per scanline before flicker limit maybe)?
The problem is the limitation of 2 sprite sizes and only 512 tiles in the vram, the Megadrive/Genesis sprite engine is, in my opinion, its best advantage over the SNES, let's see:

Bridge spikes in MD are made with sprites
Image

On the SNES, I had to use tile animation in the background (there was no space to put the sprite tiles)
sprite layer:
Image
bg layer:
Image

In MD, sprites can access all 2048 tiles in the vram (1792 usable), and they are in linear format of 8x8 pixels and can be loaded with a single dma, can use 16 different sizes on the same screen (mix of 8, 16, 24, 32 on both axis)
Sonic sprite on MD vram:
Image

On SNES, sprites can access 512 tiles from the vram (on 2 pages of 256 tiles each), they are in 2D format needing to use more than 1 dma for sprites larger than 8x8, you can use 2 different sizes on the same screen choosing from 8, 16, 32 and 64 pixels
Sonic sprite on SNES vram:
Image

All sprites tiles on SNES vram:
Image

Sprites tiles on MD vram (can access all vram):
Image

SNES all vram:
Image

In snes I used 8x8/16x16 to be able to put as many individual tiles as possible in the 512 tiles, but that makes using more sprites on the screen, there are parts that go over 100 sprites at the same time:
Image

About the large objects in MD, there are several:
Image
Image
Image
Image
Image
TiagoSC
Posts: 25
Joined: Sun Feb 26, 2017 3:44 pm

Re: [demo] SNES Sonic

Post by TiagoSC »

SNES AYE wrote: Sun Feb 12, 2023 3:59 pm
TiagoSC wrote: Sat Aug 06, 2022 7:43 am I'm not porting the complete Sonic to the SNES because the snes sprite limits really complicate porting 1:1, as I use 8x8/16x16 sprites to maximize the 512 sprite tiles, it would be difficult to make the large objects of the next stages.
What large objects made from sprites are you referring to that would have caused an issue in that level, and what issue specifically (would it be avoiding hitting the max sprites per scanline before flicker limit maybe)?
Just to see how the MD engine has the advantage, even in H32 mode (maximum 64 sprites):

[moderator: attached images from links to post]
On SNES mmx (70 sprites used out-of 128)
SNES-MMX.png
On MD mmx (28 sprites used out-of 64, in this H32 mode)
MD-MMX.png
On snes, for a game with many particles you will have an advantage for the 128 total sprites, or in a game like Sparkster that uses 16x16/32x32 sprites, you can get more and bigger sprites than the MD, but the limit is to fit all the art in the 512 tiles

snes Sparkster
Sparkster-J-000.png
Sparkster-J-000.png (31.61 KiB) Viewed 7989 times
sprite tiles on vram:
Sparkster-VRAM-sprites.png
Sparkster-VRAM-sprites.png (18.57 KiB) Viewed 7989 times
SNES AYE
Posts: 201
Joined: Mon Nov 07, 2022 11:28 am

Re: [demo] SNES Sonic

Post by SNES AYE »

Yeah, I'm starting to see how certain sections in the Sonic levels really would have been a pain to get working on SNES, at least if trying to replicate them 100% anyway, like the big moving block platforms in the following level:

https://info.sonicretro.org/images/d/d5 ... p_Syz1.png

At the same time, these Sonic maps are huge, and there's so much there that's just the two main background layers that could have been completed probably pretty easily once you had the main engine up and working already anyway, I assume. And even that would have been great to see speaking personally, whether you ever figured out a way to do the rest of the originally sprite-based level elements like those big moving platforms or not.

And, having seen your recent excellent work on the likes of the PlayStation port, I guess it would have also been fascinating to see what else you could have done to fully take advantage of some of the SNES' own unique capabilities and actually do stuff there that wasn't even in the original Genesis version, like adding that extra semi-transparent water effect you've got in the PlayStation version into the SNES version too. It looks like that would have been possible by using the part of the third SNES background layer that's currently empty in-between the score and other GUI elements.

Ultimately, I guess I just wanted to see and play more of your rather awesome SNES port of Sonic at the end of the day, and I was sad when I found out you'd stopped working on it. :-(
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: [demo] SNES Sonic

Post by 93143 »

SNES AYE wrote: Sat Apr 08, 2023 3:41 pm Yeah, I'm starting to see how certain sections in the Sonic levels really would have been a pain to get working on SNES, at least if trying to replicate them 100% anyway, like the big moving block platforms in the following level:

https://info.sonicretro.org/images/d/d5 ... p_Syz1.png
That looks perfect for Mode 2 with HDMA control of the scroll table offset. You wouldn't even need patch sprites for those weird flashy horizontal bars, since the moving blocks are exactly 32x32 with no holes and can therefore never share tiles with anything behind them - horizontal overlaps always happen on tile boundaries, and vertical overlaps can be handled by switching scroll table rows with HDMA.

This technique might also allow a substantial reduction in the number of sprites needed for the collapsing cliffs in Green Hill Zone.

Unless I'm wrong about what BG3VOFS does in Mode 2... perhaps I should test it to make sure when I have time. It seems I was right; we're good.
TiagoSC wrote: Sat Apr 08, 2023 9:10 am About the large objects in MD, there are several:
The first three seem feasible with Mode 2+HDMA, if I'm right about that. The shine on the green things might need some patch sprites or tile animation.

The last one, the sliding bridge, looks like it could be done in Mode 1 using BG3 with a few subpalettes and a bit of CGRAM HDMA. (Or you could just use 54 16x16 sprites and bet on the action not getting hectic right then.)

The second-last one, the squish bar obstacle, looks like there's no parallax backdrop visible on the relevant scanlines, and if that's the case it should be trivial in Mode 1 without even needing sprites for the HUD.
Last edited by 93143 on Mon Apr 10, 2023 11:20 pm, edited 1 time in total.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: [demo] SNES Sonic

Post by lidnariq »

93143 wrote: Mon Apr 10, 2023 4:00 am Unless I'm wrong about what BG3VOFS does in Mode 2... perhaps I should test it to make sure when I have time.
It does let you choose what row of data contains the OPT data - I used it in my modes 0-6 demo to handle the different contents needed for displaying modes 0/1/2/4/6.
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: [demo] SNES Sonic

Post by 93143 »

lidnariq wrote: Mon Apr 10, 2023 11:22 amIt does let you choose what row of data contains the OPT data - I used it in my modes 0-6 demo to handle the different contents needed for displaying modes 0/1/2/4/6.
Excellent! So it should be possible to apply in these cases.

Funny - I haven't really thought much about offset-per-tile because my game ideas don't tend to use it, but it seems to be quite a bit more capable than I imagined.
SNES AYE
Posts: 201
Joined: Mon Nov 07, 2022 11:28 am

Re: [demo] SNES Sonic

Post by SNES AYE »

Interesting. I'd always figured you have to offset the entire column when using offset per tile in Mode 2 (and modes 4 and 6 also), so this is good to know. Being able to choose what rows of tiles the vertical offset actually gets applied to down the screen definitely makes it a lot more versatile than I previously thought.
Post Reply