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
Moderator: Moderators
Thanks! These ports are open source:
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.
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.Individualised wrote: ↑Sun Feb 12, 2023 4:06 pmUnlike 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.
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.SNES AYE wrote: ↑Sun Feb 12, 2023 4:25 pmStill, 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.Individualised wrote: ↑Sun Feb 12, 2023 4:06 pmUnlike 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.
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.
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.Individualised wrote: ↑Sun Feb 12, 2023 4:51 pmSince 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.SNES AYE wrote: ↑Sun Feb 12, 2023 4:25 pmStill, 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.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.
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.
Don't expect Sonic SNES from me for a long while (or any SNES homebrew for that matter) . 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.
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:
Just to see how the MD engine has the advantage, even in H32 mode (maximum 64 sprites):
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.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
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.
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.
Excellent! So it should be possible to apply in these cases.