[demo] SNES Sonic
Moderator: Moderators
Re: [demo] SNES Sonic
This port is incredible,even at this stage really .
I thought tiago was a megadrive fan and he wasn't very good(or even interested) at SNES coding,i was wrong.
I thought tiago was a megadrive fan and he wasn't very good(or even interested) at SNES coding,i was wrong.
Re: [demo] SNES Sonic
How many enemies appear onscreen at one time in the original game? Not just within 128 pixels, but actually onscreen and visible?
VBlank is about 6 KB long minus overhead. A few enemies made of a handful of 16x16 sprites each should easily fit with no special measures, even if they all animate on the same frame. I figure that if you combine rows of sprites so that you only need to do two DMA transfers per enemy, and you use a tight DMA control loop that only updates the DMA parameters that actually need refreshing between transfers, you should be able to do (for example) four enemies made of roughly four 16x16 sprites each in a little over a third of VBlank.
VBlank is about 6 KB long minus overhead. A few enemies made of a handful of 16x16 sprites each should easily fit with no special measures, even if they all animate on the same frame. I figure that if you combine rows of sprites so that you only need to do two DMA transfers per enemy, and you use a tight DMA control loop that only updates the DMA parameters that actually need refreshing between transfers, you should be able to do (for example) four enemies made of roughly four 16x16 sprites each in a little over a third of VBlank.
Re: [demo] SNES Sonic
Sonic 1 engine isn't optimal in the way it handles active objects, it just clips them horizontally (128 px off screen) while all the vertical area is still active. The problem is that Sonic levels can be quite large even on the vertical axis so that raise quite a lot the number of active objects at same time. Note that Sonic 3 engine is more optimized on that aspect.
@TiagoSC> Amazing work ! It's just impressive how well you actually replicated it, i know you don't plan to push further the demo but still i can't imagine how many hours you spent just to get to that point. Well done !
@TiagoSC> Amazing work ! It's just impressive how well you actually replicated it, i know you don't plan to push further the demo but still i can't imagine how many hours you spent just to get to that point. Well done !
Re: [demo] SNES Sonic
The missing animation frames are from enemies Crabmeat and Neutron,psycopathicteen wrote: ↑Sun Aug 09, 2020 10:51 am What animation frames are missing? They looked the same to me.
and some sprites that use backdrop tiles.
Last edited by TiagoSC on Tue Aug 11, 2020 4:55 pm, edited 1 time in total.
Re: [demo] SNES Sonic
Thanks!
I'm actually a multi-system fan! (from 8bit to psx/saturn).
I still want to try something on the PC-Engine,
that HuC6280 is a rocket!
Last edited by TiagoSC on Tue Aug 11, 2020 4:36 pm, edited 1 time in total.
Re: [demo] SNES Sonic
Oh, that's a pleasant surprise. I'm a multi-system fan too.
Also watch where you type those Ks. I know they mean lol in Portuguese, but in an English-language forum they mean something... bad...
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
Re: [demo] SNES Sonic
In the original Sonic I think it can happen to have 4 to 7 enemies at the same time.93143 wrote: ↑Mon Aug 10, 2020 11:34 pm How many enemies appear onscreen at one time in the original game? Not just within 128 pixels, but actually onscreen and visible?
VBlank is about 6 KB long minus overhead. A few enemies made of a handful of 16x16 sprites each should easily fit with no special measures, even if they all animate on the same frame. I figure that if you combine rows of sprites so that you only need to do two DMA transfers per enemy, and you use a tight DMA control loop that only updates the DMA parameters that actually need refreshing between transfers, you should be able to do (for example) four enemies made of roughly four 16x16 sprites each in a little over a third of VBlank.
In this demo there are 2 enemies that fly through the stage, they would have to be static tiles,
the others could have their tiles loaded when the camera gets close to them, MegaManX has a similar scheme,
but what makes this difficult in Sonic, is that the scroll is multi-directional all the time; I know that DonkeyKongCountry has a engine with static sprites + dynamic sprites in free slots, but the bad thing is the delay in the animation, sometimes it is noticeable, in the Coral Capers water level, when there are many sharks on the screen you notice some frames delayed, but the idea is very good!
Last edited by TiagoSC on Tue Aug 11, 2020 6:11 pm, edited 2 times in total.
Re: [demo] SNES Sonic
Thanks for the tip!
I'm not very good at grammar and I'm using a translator, but I can read English reasonably.
Re: [demo] SNES Sonic
Thank you Stef! I know that there are many programmers like you who can do much better than I did.Stef wrote: ↑Tue Aug 11, 2020 6:50 am Sonic 1 engine isn't optimal in the way it handles active objects, it just clips them horizontally (128 px off screen) while all the vertical area is still active. The problem is that Sonic levels can be quite large even on the vertical axis so that raise quite a lot the number of active objects at same time. Note that Sonic 3 engine is more optimized on that aspect.
@TiagoSC> Amazing work ! It's just impressive how well you actually replicated it, i know you don't plan to push further the demo but still i can't imagine how many hours you spent just to get to that point. Well done !
This engine was made at the same time as the MegaManx-Megadrive, even sharing code and tools.
There are still a lot of bugs to fix, and at the moment I'm finishing the sound driver.
I redid some things and the performance has now improved a lot, I can even drop 32 rings when Sonic is hurt, just like the original.
Re: [demo] SNES Sonic
Are you kidding ? Don't be that modest :p With your MD's Megaman X port and now this SNES Sonic demo you already proven that you're a very skilled developer !
I guess both engine share similarities, that shows the base engine is flexible enoughThis engine was made at the same time as the MegaManx-Megadrive, even sharing code and tools.
There are still a lot of bugs to fix, and at the moment I'm finishing the sound driver.
Something i was wondering is about the level encoding, did you keep the same method as Sonic 1 engine (if i remember correctly it's 256x256 RLE compressed block with 16x16 tiles) ? Hopefully the SNES support natively 16x16 tile which should make that part even easier than on MD but still i think it's something than can cost quite a bit of CPU time and i'm not sure the doubled RAM capacity on SNES is enough to store a whole map (as they can be huge).
Haha really well done ! I've to admit this is the first thing i've tested in your demo as i would had expected to see slowdowns here but i saw you limited the ring number to avoid that. It's really impressive you were able to bring back the original number of rings now !I redid some things and the performance has now improved a lot, I can even drop 32 rings when Sonic is hurt, just like the original.
Re: [demo] SNES Sonic
It's not RLE, it's Kosinski compression, based on LZSS.
I doubt it, considering that the attributes of each 8x8-pixel tile (palette and flipping) can be controlled individually in the Sonic engine.Hopefully the SNES support natively 16x16 tile which should make that part even easier than on MD
Sonic maps are kept entirely in RAM even on the MD, as they're not made of unique 256x256-pixel blocks, these are indexed by the plane maps and reused extensively.i'm not sure the doubled RAM capacity on SNES is enough to store a whole map (as they can be huge).
Re: [demo] SNES Sonic
Even worse for CPU but better for the compression
but that is just for metatile definition right ? so not needed anymore as soon your metatiles are "unpacked / decoded".I doubt it, considering that the attributes of each 8x8-pixel tile (palette and flipping) can be controlled individually in the Sonic engine.
I'm not sure about what you mean by "maps are kept entirely in RAM", the "compressed" version of course, the final unpacked / decoded version.. no way. Still i think i need to check on Sega retro how maps are exactly encoded, in my mind it was definitely not so trivial to decode the map live (i mean : one row + one map column per frame).Sonic maps are kept entirely in RAM even on the MD, as they're not made of unique 256x256-pixel blocks, these are indexed by the plane maps and reused extensively.
Re: [demo] SNES Sonic
There's no "final/decoded" version, what's in RAM is decoded on the fly. It's not as complex/slow as it sounds: use bits 8-15 of the coordinates to look up the index of a 256x256-pixel block in the level map, and then bits 4-7 to look up 16x16-pixel blocks within the 256x256. From there you can either lookup the individual tiles for VRAM updates or the collision information for physics. I've done much more complex map decoding on the fly on the NES.
I've never done any Genesis coding, but I've played with the RAM as the game was running in order to see the changes, and indeed changing the "compressed" data structures resulted in live changes to the level map.
-
- Posts: 1
- Joined: Wed Aug 12, 2020 1:26 pm
Re: [demo] SNES Sonic
Congratulations, you can make the updates available for us to test ?TiagoSC wrote: ↑Tue Aug 11, 2020 4:54 pmThank you Stef! I know that there are many programmers like you who can do much better than I did.Stef wrote: ↑Tue Aug 11, 2020 6:50 am Sonic 1 engine isn't optimal in the way it handles active objects, it just clips them horizontally (128 px off screen) while all the vertical area is still active. The problem is that Sonic levels can be quite large even on the vertical axis so that raise quite a lot the number of active objects at same time. Note that Sonic 3 engine is more optimized on that aspect.
@TiagoSC> Amazing work ! It's just impressive how well you actually replicated it, i know you don't plan to push further the demo but still i can't imagine how many hours you spent just to get to that point. Well done !
This engine was made at the same time as the MegaManx-Megadrive, even sharing code and tools.
There are still a lot of bugs to fix, and at the moment I'm finishing the sound driver.
I redid some things and the performance has now improved a lot, I can even drop 32 rings when Sonic is hurt, just like the original.
Re: [demo] SNES Sonic
tokumaru wrote: ↑Wed Aug 12, 2020 7:52 am There's no "final/decoded" version, what's in RAM is decoded on the fly. It's not as complex/slow as it sounds: use bits 8-15 of the coordinates to look up the index of a 256x256-pixel block in the level map, and then bits 4-7 to look up 16x16-pixel blocks within the 256x256. From there you can either lookup the individual tiles for VRAM updates or the collision information for physics. I've done much more complex map decoding on the fly on the NES.
I've never done any Genesis coding, but I've played with the RAM as the game was running in order to see the changes, and indeed changing the "compressed" data structures resulted in live changes to the level map.
Ok, well the format matches the one i had in mind but for some reason i over estimated the required decoding processing for it. When you need to update both a column and and row of data, you still need to update at min about 42/2 + 30/2 = 36 "16x16 tiles", convert them to 2x2 "8x8 tiles" so about 144 tiles to update in the tilemap (and properly arranged). And this at every frame when scrolling is at max speed (16 px per frame)...
Ok not that intensive but still, for me that is definitely not free :p