The biggest problem with a Sonic game on the Super NES is that unless you want to keep everything except the Bonus/Special Stages in Mode 6, and put a Super FX and/or SA-1 chip on the cartridge PCB to handle extra graphical functions, Sonic, Tales. and the rest of the cast will look rather zoomed in. The Sega Mega Drive/Genesis featured a 320×224 as its main resolution mode. The Super NES had either 256×240 with hardware parallax scrolling, or 512×480 in 30Hz, with only one scrolling field and 64 total colors (four different CLUTs of sixteen colors. each), which looked terrible on.a broadcast television quality CRT if you didn't know what you were doing. At least the Commander X16 features a 320×240 resolution mode.
@@benbreeck3363 Discussing the technical aspects of video games is something I struggle with, I will say that someone already made a proof of concept demo that didn’t do it your way. IIRC the demo does not require enhancement chips, and it doesn’t sacrifice much except performance in certain parts and resolution.
Can't wait to see what you come up with! You must be aware of the Sonic Physics Guide at Sonic Retro, right? It's an invaluable resource for projects like this.
Absolutely true, all of the Sonic Retro guides are invaluable when working on this. Also I won't be afraid to ask for help if I run into problems. Thank you!
If you haven't already done so, your best bet is to review the docs on Sonic Retro compiled by Taxman (Christian Whitehead, the lead dev of Sonic Mania and the modern ports of the classic Sonic games), Nemesis (the dev who made the Exodus emulator), and others. Even if the architectures used on the original Genesis versions of the games were the combo of Motorola 68000 and Zilog Z80, the way they documented the workings of the original trilogy on that site should be usable even on other processors like the 6502/65C02.
Sonic 1 use huge hierarchical meta tile covering 256 px to achieve big level at low memory footprint, later game capped at 128 px, with paging you should have no problem even on 8 bits or without 512ko. Sonic use sub pixel for physics, and a one byte lut heightmap for ground slope variation per tile type, with 3 feelers to get ground data, one slightly ahead and behind, and the center one. Sonic physics is largely documented on many fan site leading to exact replucation of the gameplay in fangame
There would be improvements with 3 hotspots for ground detection, but the original game only uses 2. I know Yoshi's Island (SNES) uses 3 where the middle actually improves the visuals. I might be limited to 1 just like Super Mario since the CPU isn't very fast. We'll see, it is hard to time these things until everything is implemented
@@doslogo on 8 bit I wouldn't use 3 feeler because I wouldn't use a heightmap lut, but a slope lut with less variations, basically branching logic on type of slope. And I would do tile collision on position hashed bitfield first (a nibble being 4 tile in square patten, organized in chunks) which bypass the need for feeler entirely (you get more context with less compute), the slope lut taking care of sub tile collision. There is probably an optimisation, if there is a clever way to differentiate full collision tile with partial collision tile or slope tile. Slope resolution being something like: grounded = if y < inTilePos.x >> slope //0 for 45, 1 for halving, permute x and y for rotation and flipping, I only have two type of slope, should be more than enough
@@timmygilbert4102 Good advice! Most of my luts are pointers to other luts in different banks, so I don't have to bitshifts. The 65C02 really likes to eat cycles on such basic operations as bitshifts, causing me headache
Actually, you can use the 65C02's bit shift instructions for multiplication. It's even faster than trying to use MUL on a Motorola 68000, or any X86 processor before the Pentium outside of the NEC V series, which featured hardware multiplication and division. But it's still tedious to write out the operation in anywhere from seven to twenty-one instructions.
Other CPUs can multiply by 2 by adding the same value with itself, but the 65C02 must do such a thing with a memory location rather than a register, and the same goes for ROL and ROR to multiply 16 bit numbers (and moving that carry bit). It is very limiting, but at least it works
Would Sonic games from the Game Gear and Master System be a better close of reference since they are running on 8bit hardware? How I think about it, if you can get those core fundamentals down that Sonic games usually have, you can get scale up and add features the Genesis versions would have.
0:22 is the Commodore 64 port of the first Sonic game for Master System, and I have only good memories from this game. The port is crazy good! It is a good benchmark in direction, story and music. But it is not working the same as the Genesis games. Truth be told, Super Mario Bros. 3 (NES) is probably much better as a reference to get the basics right
Eventually, there is an NES version of Sonic 1, originally made by Hummer Team in 1994, as "Somari." Later, me and some rom hackers are making a definite version of Sonic 1 for the NES with all levels, which also includes Scrap Brain Zone as well, even though Hummer Team didn't implement it to the original bootleg. (Note: The version I'm working on provides FM soundtrack, similar to the Sega Genesis/Mega Drive using a third-party sound expansion called the Expansion Port Sound Module, aka EPSM, which utilities an sunsoft 5b chip for psg and a YMF288 chip for fm synthesis)
512 kB is definitely the best option, since that's what the CX16's base model has. It is accessed though a narrow window of 8 kB, giving me 64 banks to read and write to. Going to be a lot of bank-switching, but it will work 👍
If you put it on a cartridge, or at least make a ROM for someone else to make a cartridge for it, the CPU could directly access 3.5 megabytes or 28 megabits, enough for Sonic 3D Blast.. If you put it on a CMD-4000 double sided, extended density floppy, which should plug right into the Commander X16's floppy drive port, You are looking at 3,200KB. If you do both at the same time, Sonic 3 and Knuckles should be quite possible. You could even add more characters like certain fan games. Just be prepared to do a LOT of garbage collection and background loading on Commander X16 with a stock RAM capacity.
Size won't be a problem right now. The Commander X16 can't process data that fast, so the more data won't change the visual outcome of the game. Like, how many animation frames can be used is limited by the speed the graphics data can be uploaded to VRAM, and that speed is just not fast compared to game consoles of the past (they had DMA). There are some design choices of the CX16 system that directly work against me (interrupt code is locked in ROM, wasting cycles, not that bad though), but I'm focusing on what can be done and not what can't be done
Very interesting that you're using what seems to be a recreated spritesheet of the TTS Prototype version of Sonic's sprites. If so, you might wanna credit the sheet creator, unless those are placeholders That aside, I have very good faith that this'll go well! As Sonic 1 SMS was ported to the C64, I think "dreams can come true" (ha-ha, very clever I know) and you'll pull something off!
I will definitely give credits to anyone that helps out with game resources. At this current stage, everything will be placeholders, even so, if not made by myself, I will give visible credits in-game
Well this is an exciting development!
It has been a few crazy weeks, but it has been exciting the entire time! Thanks!
I don't know it it's AN exciting development, but it's exciting development.
I like Sonic fan games on weird platforms, your project makes me feel a little better after the Sonic 1 SNES port I really wanted was canceled.
There was that bootleg game...
@ a far cry from an accurate port made by passionate fans
The biggest problem with a Sonic game on the Super NES is that unless you want to keep everything except the Bonus/Special Stages in Mode 6, and put a Super FX and/or SA-1 chip on the cartridge PCB to handle extra graphical functions, Sonic, Tales. and the rest of the cast will look rather zoomed in. The Sega Mega Drive/Genesis featured a 320×224 as its main resolution mode. The Super NES had either 256×240 with hardware parallax scrolling, or 512×480 in 30Hz, with only one scrolling field and 64 total colors (four different CLUTs of sixteen colors. each), which looked terrible on.a broadcast television quality CRT if you didn't know what you were doing.
At least the Commander X16 features a 320×240 resolution mode.
@@benbreeck3363 Discussing the technical aspects of video games is something I struggle with, I will say that someone already made a proof of concept demo that didn’t do it your way. IIRC the demo does not require enhancement chips, and it doesn’t sacrifice much except performance in certain parts and resolution.
Can't wait to see what you come up with!
You must be aware of the Sonic Physics Guide at Sonic Retro, right?
It's an invaluable resource for projects like this.
Absolutely true, all of the Sonic Retro guides are invaluable when working on this. Also I won't be afraid to ask for help if I run into problems. Thank you!
If you haven't already done so, your best bet is to review the docs on Sonic Retro compiled by Taxman (Christian Whitehead, the lead dev of Sonic Mania and the modern ports of the classic Sonic games), Nemesis (the dev who made the Exodus emulator), and others. Even if the architectures used on the original Genesis versions of the games were the combo of Motorola 68000 and Zilog Z80, the way they documented the workings of the original trilogy on that site should be usable even on other processors like the 6502/65C02.
I guess David did actually predicted that one huh, it's nice to have a Sonic game ported to the CX16!
Sonic 1 use huge hierarchical meta tile covering 256 px to achieve big level at low memory footprint, later game capped at 128 px, with paging you should have no problem even on 8 bits or without 512ko. Sonic use sub pixel for physics, and a one byte lut heightmap for ground slope variation per tile type, with 3 feelers to get ground data, one slightly ahead and behind, and the center one. Sonic physics is largely documented on many fan site leading to exact replucation of the gameplay in fangame
There would be improvements with 3 hotspots for ground detection, but the original game only uses 2. I know Yoshi's Island (SNES) uses 3 where the middle actually improves the visuals. I might be limited to 1 just like Super Mario since the CPU isn't very fast. We'll see, it is hard to time these things until everything is implemented
@@doslogo on 8 bit I wouldn't use 3 feeler because I wouldn't use a heightmap lut, but a slope lut with less variations, basically branching logic on type of slope. And I would do tile collision on position hashed bitfield first (a nibble being 4 tile in square patten, organized in chunks) which bypass the need for feeler entirely (you get more context with less compute), the slope lut taking care of sub tile collision. There is probably an optimisation, if there is a clever way to differentiate full collision tile with partial collision tile or slope tile. Slope resolution being something like:
grounded = if y < inTilePos.x >> slope //0 for 45, 1 for halving, permute x and y for rotation and flipping, I only have two type of slope, should be more than enough
@@timmygilbert4102 Good advice! Most of my luts are pointers to other luts in different banks, so I don't have to bitshifts. The 65C02 really likes to eat cycles on such basic operations as bitshifts, causing me headache
@doslogo yeah okay, it's more of a reference, the main idea was to show a quick slope computation, using the fact that y
@@doslogo The CPU isn't very fast? It's an 8mhz 65c02 right? You're already faster than the SNES.
already peak by the tokyo toy show sonic sprite recreations being used
you can do division and multiplication, it's just that have to do them yourself
Actually, you can use the 65C02's bit shift instructions for multiplication. It's even faster than trying to use MUL on a Motorola 68000, or any X86 processor before the Pentium outside of the NEC V series, which featured hardware multiplication and division. But it's still tedious to write out the operation in anywhere from seven to twenty-one instructions.
@@benbreeck3363 u sent the comment twice by accident
Other CPUs can multiply by 2 by adding the same value with itself, but the 65C02 must do such a thing with a memory location rather than a register, and the same goes for ROL and ROR to multiply 16 bit numbers (and moving that carry bit). It is very limiting, but at least it works
doslogo you can just bitshift left once to multiply by two
n bitshifts will multiply the number by 2^n
Would Sonic games from the Game Gear and Master System be a better close of reference since they are running on 8bit hardware? How I think about it, if you can get those core fundamentals down that Sonic games usually have, you can get scale up and add features the Genesis versions would have.
0:22 is the Commodore 64 port of the first Sonic game for Master System, and I have only good memories from this game. The port is crazy good! It is a good benchmark in direction, story and music. But it is not working the same as the Genesis games. Truth be told, Super Mario Bros. 3 (NES) is probably much better as a reference to get the basics right
Wikid Awesome Brotha!
Keep it Up!
What an ambitious project! But, um, well... have you ever read the story of Icarus?
Once I fly into the sun, I'll make sure it gets entertaining for the TH-cam 👌🔥
For when someone is going to try to port Sonic 1 to the Commodore Amiga and have it use the Scorpion Engine of Erik Hogan?
Eventually, there is an NES version of Sonic 1, originally made by Hummer Team in 1994, as "Somari." Later, me and some rom hackers are making a definite version of Sonic 1 for the NES with all levels, which also includes Scrap Brain Zone as well, even though Hummer Team didn't implement it to the original bootleg.
(Note: The version I'm working on provides FM soundtrack, similar to the Sega Genesis/Mega Drive using a third-party sound expansion called the Expansion Port Sound Module, aka EPSM, which utilities an sunsoft 5b chip for psg and a YMF288 chip for fm synthesis)
That's pretty cool, has you posted anything about it somewhere?
@retrodeveloper9156 Not yet, it's not available to the public at the moment. Rest assured, if the game get it's final update, I'll let you know!
@@InnovateSphereStudios Alright!
Wish you luck with the FM programming!
CX16's memory ought to be enough, original Sonic 1 on the Megadrive was a 512kb cart and the sequel 1MB.
512 kB is definitely the best option, since that's what the CX16's base model has. It is accessed though a narrow window of 8 kB, giving me 64 banks to read and write to. Going to be a lot of bank-switching, but it will work 👍
If you put it on a cartridge, or at least make a ROM for someone else to make a cartridge for it, the CPU could directly access 3.5 megabytes or 28 megabits, enough for Sonic 3D Blast.. If you put it on a CMD-4000 double sided, extended density floppy, which should plug right into the Commander X16's floppy drive port, You are looking at 3,200KB. If you do both at the same time, Sonic 3 and Knuckles should be quite possible. You could even add more characters like certain fan games. Just be prepared to do a LOT of garbage collection and background loading on Commander X16 with a stock RAM capacity.
Size won't be a problem right now. The Commander X16 can't process data that fast, so the more data won't change the visual outcome of the game. Like, how many animation frames can be used is limited by the speed the graphics data can be uploaded to VRAM, and that speed is just not fast compared to game consoles of the past (they had DMA). There are some design choices of the CX16 system that directly work against me (interrupt code is locked in ROM, wasting cycles, not that bad though), but I'm focusing on what can be done and not what can't be done
this is underrated
i thought this was some decently popular channel like 10k subs or 20k subs but no it's a really passionate cool guy
The music should be able to be done pretty easily via the YM2151 and PCM/PSG on the VERA
Very interesting that you're using what seems to be a recreated spritesheet of the TTS Prototype version of Sonic's sprites. If so, you might wanna credit the sheet creator, unless those are placeholders
That aside, I have very good faith that this'll go well! As Sonic 1 SMS was ported to the C64, I think "dreams can come true" (ha-ha, very clever I know) and you'll pull something off!
I will definitely give credits to anyone that helps out with game resources. At this current stage, everything will be placeholders, even so, if not made by myself, I will give visible credits in-game
[Becomes 333rd sub]
Thank you!
nice volume levels. i could almost hear something