New Demo - Sonic Green Hill Zone simulation on X16

ZeroByte · Post by **ZeroByte** » Mon Oct 18, 2021 9:14 pm

I will be uploading the demo files to the forums in just a few minutes...

ZeroByte · Post by **ZeroByte** » Mon Oct 18, 2021 9:59 pm

It seems to have broken the "try it now" feature - lol. Maybe I need to type the PRG name in all-caps?

EDIT: Yeah, that makes it run. Still no sound though, even if I un-click the mute icon. Strange.

Tatwi · Post by **Tatwi** » Mon Oct 18, 2021 10:17 pm

I'm not getting any sound in this demo in Firefox or Google Chrome (Win10 Home 64bit). I check some other demos and sound is working on them.

REALLY COOL DEMO though!

ZeroByte · Post by **ZeroByte** » Mon Oct 18, 2021 10:24 pm

I wonder why... I told it to run the R38 version... maybe I'll try having it run R39 just to see... I just ran it from the ZIP again and it definitely works on R38. Strange.

desertfish · Post by **desertfish** » Mon Oct 18, 2021 11:10 pm

sound worked fine on the non-web based emulator with v39 roms for me. (indeed not on the browser emu)

ZeroByte · Post by **ZeroByte** » Tue Oct 19, 2021 1:52 am

Funny thing is, I actually built a pitch-corrected version of the music stream for R38 (which has the YM clocked at 4MHz instead of 3.5MHz) so the FM and PSG are in tune with each other... R38 runs on the real emulator as well.

Ed Minchau · Post by **Ed Minchau** » Tue Oct 19, 2021 3:35 am

It looks like a lot more than two layers in that parallax effect.

ZeroByte · Post by **ZeroByte** » Tue Oct 19, 2021 4:02 am

On 10/18/2021 at 10:35 PM, Ed Minchau said:

It looks like a lot more than two layers in that parallax effect.

The Background actually has 17 layers of scrolling. The clouds/tall mountains are the main BG scroll value. I created a table of 16 raster line values and the demo cycles through these, setting each one as the next line IRQ to trigger on.

When the main loop begins, it creates a table of scroll offsets based on the main BG's scroll value (which is 1/8 the FG scroll value). It divides BG scroll by 2 to create a "per line scroll amount" (delta). On each raster IRQ, the BG scroll is incremented by delta. After 16 iterations, the bottom row of water ripples will be scrolled at the same amount as the FG (this happens below the path, so you don't see it scrolling at the same speed as the FG though). All values (FG, BG, and per-rasterline) also keep a subpixel scroll amount, so the speed is very flexible - as low as 1/16 of a pixel per frame (FG scroll). This subpixel scroll amount is maintained through the creation of the 16 raster scroll values as well in order to keep it nice and smooth.

I did cheat for Sonic's Y coordinate though. The tile set is arranged very erratically. I'm convinced there must be meta-data in the tile numbers to indicate things like "vertical offset" that I'm just not seeing - and making a table of varying terrain heights from tile IDs was crazy, and required a linear search through the table, just to determine something as simple as how high Sonic is with the ground. So since the BG is fixed and repeating, I just fudged and made a "per column" table by hand and have the game cycle through that table with every 8px of scrolling performed. It works for this demo, but if I were to have more varied terrain or vertical scrolling for things like jumping or higher platforms, I'd have to do a lot more work to make Sonic properly collide with tiles. Not necessary here, so I took the path of least resistance. ?

Ender · Post by **Ender** » Tue Oct 19, 2021 4:31 am

On 10/19/2021 at 12:02 AM, ZeroByte said:

The Background actually has 17 layers of scrolling. The clouds/tall mountains are the main BG scroll value. I created a table of 16 raster line values and the demo cycles through these, setting each one as the next line IRQ to trigger on.

When the main loop begins, it creates a table of scroll offsets based on the main BG's scroll value (which is 1/8 the FG scroll value). It divides BG scroll by 2 to create a "per line scroll amount" (delta). On each raster IRQ, the BG scroll is incremented by delta. After 16 iterations, the bottom row of water ripples will be scrolled at the same amount as the FG (this happens below the path, so you don't see it scrolling at the same speed as the FG though). All values (FG, BG, and per-rasterline) also keep a subpixel scroll amount, so the speed is very flexible - as low as 1/16 of a pixel per frame (FG scroll). This subpixel scroll amount is maintained through the creation of the 16 raster scroll values as well in order to keep it nice and smooth.

I did cheat for Sonic's Y coordinate though. The tile set is arranged very erratically. I'm convinced there must be meta-data in the tile numbers to indicate things like "vertical offset" that I'm just not seeing - and making a table of varying terrain heights from tile IDs was crazy, and required a linear search through the table, just to determine something as simple as how high Sonic is with the ground. So since the BG is fixed and repeating, I just fudged and made a "per column" table by hand and have the game cycle through that table with every 8px of scrolling performed. It works for this demo, but if I were to have more varied terrain or vertical scrolling for things like jumping or higher platforms, I'd have to do a lot more work to make Sonic properly collide with tiles. Not necessary here, so I took the path of least resistance. ?

I thought I'd seen something about how collision detection in Sonic worked, and looked around some and came across this. Looks like it could be interesting to you: https://info.sonicretro.org/Sonic_Physics_Guide

In particular, https://info.sonicretro.org/SPG:Solid_Tiles and https://info.sonicretro.org/SPG:Slope_Physics

ZeroByte · Post by **ZeroByte** » Tue Oct 19, 2021 5:46 am

On 10/18/2021 at 11:31 PM, Ender said:

I thought I'd seen something about how collision detection in Sonic worked, and looked around some and came across this. Looks like it could be interesting to you: https://info.sonicretro.org/Sonic_Physics_Guide

In particular, https://info.sonicretro.org/SPG:Solid_Tiles and https://info.sonicretro.org/SPG:Slope_Physics

Interesting read. They don't get super explicit about the tile data itself, and from reading it a couple of times, it appears to me that there is another data structure not in VRAM which contains the so-called "solid tiles" of the map, and it's these solid tiles and not the graphical tiles which are used for collisions.

It makes sense because let me tell you what, there are a ba-ZILLION tiles in the set (I think just under 1000). Genesis's tilemap is close to VERA's - except it uses 11 bits for tile ID, has H-flip and V-Flip, but only 2-bit color palette choice. The final bit is a tile priority bit which makes the tile appear above sprites of the same layer, which is a bit that I really wish VERA had. The tiles are not grouped together in ways that make sense to me; definitely NOT like you see in pixel art tutorials with the tiles arranged as basic rectangles of the terrain type... No, they're scattered all over the place and only vaguely grouped as to whether they're sloped, have ground above and below, below only, etc.

I had originally planned to make my demo procedurally generate terrain and have Sonic run through it, but after several hours working with the tile set to get it converted and then playing around with them in Aseprite's tile mode, it was painfully obvious that it would take me weeks to even make a set of pre-defined terrain segments to lace together, so I figured "screw it" and just ripped the tilemap data of the start area and used that. (had to convert Genesis -> VERA format, which included a big->little endian swap)