Sonic and Sega Retro Message Board: LOst - Viewing Profile - Sonic and Sega Retro Message Board

evilhamwizard, on 30 May 2015 - 09:32 PM, said:

Yes, it was a matter of reading disassemblies side by side. The Gamecube port of Sonic CD doesn't do any queueing, but it does have most labels matching Sonic 1's (such as order of variables mostly equals the original RAM addresses if lucky). Then the Sega Saturn C dev documents match the port in its syntax/naming and structure, so things started to get pretty clear at one point. But it was the port of a boss that made all the difference (I think it was one of the Tidal Tempest bosses), as it still had the queue table index matching the Sega CD one. After that, I think some of the labels from the earliest Sonic 2 ROM made much more sense.
So divdevwk IS the name of the RAM area $FFF680 ($60 in size), and that area (work) contains a queue list of the patterns to decompress into VRAM, mostly it is used for knowing where it left off last frame, so it could continue the work this frame. The system is not flawless as it contains bugs that are visible in Sonic 1 (such as overwriting patterns on some enemies and bosses if unlucky, like the Roller and Eggman's feets while jumping on the switch). Many Genesis games use the pattern compression, but I think only the Sonic games use this div dev queue (I could be wrong, also the name suggest div meaning it divides patterns into smaller pieces, or divides upload to VRAM over multiple frames). Also remember to not confuse this queueing with Sonic 3's LZ queueing/buffering of levels and art as that was new for Sonic 3 and was more effective (the name for that one is unknown, and so are the names of the all three compressions).

So with labels from Sonic CD, labels from S&K Collection, and very early Sonic 2 labels, as well as the Sega Saturn C devkit docs, names and the structure of the code got pretty clear.



As for music theories, I think most of them were blown away with the release of Masato Nakamura's Sonic the Hedgehog 1 & 2 Soundtrack album.





And to be a little bit on topic, I LOVE the early Sonic 1 art style. It is still pretty clear that Sonic 1's art style was kept from beginning of the development until the final release, and that is impressive.

Awesome find! This quality scan together with the discovery of the checkered ball in action (a few month back) are to live for!






As for the parallax scrolling techniques often talked about in this demo:
I did found a few references in Sonic 1's code labels that state there were once two layers of objects in the game. Just imagine it as two cameras moving at different speeds and creating and potentially destroying objects as they move over a grid of 128 pixels. By having two object layouts, it is possible to spawn background or foreground objects at a different scroll rate, such as the rocks and clouds in the foreground. A huge amount of RAM was allocated for this effect, and it was probably removed in favor of other effects. Having foreground and background objects in the game is still possible, but require special programming as can be seen by the trusses in Starlight Zone and Chemical Plant Zone, and the Death Egg background sprite in Lava Reef Zone Act 2, and then we have special foreground palm leaves in Angel Island.


Here are some of the Sonic 1 references (ported to C). The name of the second object layer was officially Z:

extern FIX16				scra_h_posiw;				// $FFF700: Scroll A horizontal.
extern FIX16				scra_v_posiw;				// $FFF704: Scroll A vertical.
extern FIX16				scrb_h_posiw;				// $FFF708: Scroll B horizontal.
extern FIX16				scrb_v_posiw;				// $FFF70C: Scroll B vertical.
extern FIX16				scrz_h_posiw;				// $FFF710: Scroll Z horizontal. << Object layer 2 scroll
extern FIX16				scrz_v_posiw;				// $FFF714: Scroll Z vertical. << Object layer 2 scroll
extern FIX16				scrc_h_posiw;				// $FFF718: Scroll C horizontal.
extern FIX16				scrc_v_posiw;				// $FFF71C: Scroll C vertical.

extern unsigned short int		scrflaga;				// $FFF754: Scroll A update flags.
extern unsigned short int		scrflagb;				// $FFF756: Scroll B update flags.
extern unsigned short int		scrflagz;				// $FFF758: Scroll Z update flags. << Object layer 2 scroll
extern unsigned short int		scrflagc;				// $FFF75A: Scroll C update flags.

extern ASETDATA const*			asetadr;				// $FFF770: Actset high address.
extern ASETDATA const*			asetadr2;				// $FFF774: Actset low address.
extern ASETDATA const*			asetadrz;				// $FFF770: Actset high address for scroll Z. << Object layer 2 scroll
extern ASETDATA const*			asetadrz2;				// $FFF774: Actset low address for scroll Z. << Object layer 2 scroll

extern signed short int			asetxposiz;				// $FFF78A: Last horizontal spawn meta grid for scroll Z. << Object layer 2 scroll
extern signed short int			asetyposiz;				// Last vertical spawn meta grid for scroll Z. << Object layer 2 scroll

extern signed short int			flagxposiz;				// Current horizontal spawn meta grid for scroll Z. << Object layer 2 scroll
extern signed short int			flagyposiz;				// Current vertical spawn meta grid for scroll Z. << Object layer 2 scroll

extern signed short int			flagxposi;				// Current horizontal spawn meta grid ($FFEF64 in Sonic 3).
extern signed short int			flagyposi;				// Current vertical spawn meta grid ($FFF7DA in Sonic 3).

extern FLAGWKCNT			flagwkcnt;				// $FFFC00: Spawn remember buffer index.
extern FLAGWKCNT			flagwkcntz;				// $FFF78C: Spawn remember buffer index for scroll Z. << Object layer 2 scroll

In the source file ACTSET, the spawn tables are initialized according to the active stage, and some of the Z scrolling stuff is indeed left initialized in Sonic 1:

void actsetchk ()
{
	unsigned int I;
	signed int x, y, xz, yz;

	enum
	{
		actsetinit, 
		actset
	};

	switch (actset_rno)
	{
	case actsetinit:
		++actset_rno;

		asetadr = asetadr2		= asettbl [(((stageno.zone << 1) + stageno.zone) + stageno.act) << 1];
		asetadrz = asetadrz2		= asettbl [((((stageno.zone << 1) + stageno.zone) + stageno.act) << 1) + 1]; // << Object layer 2 scroll

		flagwkcnt.flagworkcnt = flagwkcnt.flagworkcnt2 = 1;
		flagwkcntz.flagworkcnt = flagwkcntz.flagworkcnt2 = 1; // << Object layer 2 scroll

		for (I = 0; I < 0x200; I++)
		{
			flagwork [I] = 0x00;
		}

		if ((x = (signed int) scra_h_posiw.integer - STAGE_ACTSET) < 0)
		{
			x = 0;
		}
		
		x &= ~(STAGE_ACTSET - 1);

		while (x > asetadr->xposi)
		{
			if ((signed char) asetadr->actno < 0)
			{
				++flagwkcnt.flagworkcnt;
			}

			++asetadr;
		}

		... Continues initializing spawn boundaries ...

Sorry about the technical stuff above. The main thing is, Sonic 1 will always be special and I hope more discoveries will follow, being it graphics, music, or code.

Off topic: I did discover the name of the queued/buffered compressed art in the labels as well. The name is divdevwk. Remember this is not the name of the compression, but the name of the system for dividing the job of decoding a little bit of data per frame to have smooth loading of bosses etc.

I like the time limit. 10 minutes is perfect, as it allows for great exploration, that forces you to do it more than once, even in the larger zones from Sonic & Knuckles. It extends the gameplay value without forcing it. Think about it, average 30 second acts for Sonic 1, with 10 minutes to spare is simular to 18 days of a full year, where 18 days might be hard work, and the rest is for exploration and just having fun! But you still have a year, so you have to know what you are doing, and if there isn't time, you'll play the game the next year.

Time limits are part of the arcade style gaming. You must loose something if you fail that time, and in arcades you have to lose your paid money. What is better, than to lose lives instead of money?

However, some games take the Arcade too far in their home console port. Sonic was not derived from a Sonic arcade game, so that's why I think the time limit is okay. It is well balanced, compared to some arcade ports that become nearly impossible to beat because they stayed with an incompatible design.

Sonic CD's 3 minutes, is just to show off a cool attitude. I only saw it once while I played, and it was because I had to take a phone call at the time, and didn't pause the game. I wasn't too happy to be robbed of my life without any warning. At least he could have said "You want me out of here? Take the controls, or I'll kill myself"

ICEknight, on 28 March 2012 - 06:38 PM, said:

I planned lossless compression support, but we ran out of time for the AR. Also WAV with "sustain loops" lets you change music yourself (with custom loop point), which I think is pretty fitting when there was so many people wanting their music in S2HD from the start. The S2HD music thread at Sonic Retro was the most growing of them all. But basically, there was no time, and why accept lower quality when everything else was presented as the highest quality possible? If there was an issue with mp3 converted to wav (like converting jpeg to png), it is not my doing, as I only accept FLAC or WAV nowdays for my own private music.

The rest of the data is protected from public tampering with, including the application files.

I enjoyed the whole documentary from beginning to end. I really ROFLMAO at the music that was played when Naka's head was pasted to a baby (29:22). What's that music called?