Technical aspects of the Sonic games

Discussion in 'Engineering & Reverse Engineering' started by Fred, Mar 25, 2008.

Thread Status:
Not open for further replies.
  1. Fred


    Formerly known as 'Neo' Oldbie
    Sonic 3 Unlocked
    For a while now, I've had a few questions poking at my brain, with no answer available to calm them down. Questions about intricate aspects of the Megadrive Sonic titles, to whom which I had insufficient knowledge or no answer at all to solve. I haven't posted them before mainly just because I'm lazy, and because I keep forgetting them. Today, I remembered some, I'm near my computer, I have a cold, it's over 2 AM -- it's the perfect time. Without further ado:

    1. Sonic 2 Special Stages

    There's two particular aspects about the special stages in Sonic 2 that I could never quite understand:

    1) Why does it use the 256x244 display mode rather than the full 320x224 resolution? The only other things that use the mode in Sonic games are the Sonic CD title/special stage, with the intent of using the "Mode7" display mode for the clouds and level track, respectively. Sonic 2's special stage, however, doesn't use it, so I can't see any justification to it except that it requires less 8x8 tiles to be displayed in order to fill the screen. This is really the only explanation to make sense, but then again I think about Sonic 3's special stage, which is pretty busy itself, but manages to use the full 320x224 mode. Is the Sonic 3 special stage less intensive, or is the reason for using 256x224 in Sonic 2's a different one?

    2) Why are the graphics for the stage doubled up in scale? Are the graphics themselves stored in the ROM like that, or does the game blow them up via software scaling to be displayed on screen? If so, what's the reason for that? Saving ROM space, or is it a video memory limitation of sorts?

    In both cases, would it be technically possible to implement the Sonic 2 special stage in full 320x224 resolution with un-blown up graphics?

    2. 2P Versus mode oddities

    Again, these are actually two questions in one. Sonic 2's 2P mode works perfectly with the selectable stages (Emerald Hill, Casino Night and Mystic Cave), however, the same cannot be said about the remainder of the stages:

    1) Most stages do not display correctly. Most of them have weird artifacts floating across the entire stage, and in some the 2P scene is not drawn correctly and the camera doesn't scroll the level fluidly, but rather in "chunks" (which I assume is the visible area of the level as it's loaded to memory). What I'm wondering is why does this happen? Why does, say, Chemical Plant not draw correctly, but Casino Night does? And about the 2P scene not behaving correctly - does it have to do with special level settings such as vertical wrapping, etc? In any case, would the levels be fixable in order to work properly in 2P mode? And if so, would it be at the expense of removing features from a level?

    2) Levels with water do not load at all. This must be a condition set by the game itself, as water must seriously fuck up 2P mode. Why does water not work, could it be made to work without major alterations to the level itself, and if so, how?

    3. The Megadrive NTSC display border

    This isn't really a Sonic question, but it's Sonic-related. I've noticed that in Sonic 1 and 2, the little border on the top and bottom of the screen (covering the empty space left from displaying a 320x224 image in a 320x240 screen) seems to take the color of the first index in pallete line 1 (or something to the effect), whilst as in Sonic 3 (and Knuckles) this border is always black (save for the Sega screen and the level select, which is hangover from Sonic 2). It's obvious that the color the border displays can be conditioned by software, but how exactly? Can you directly tell the system which color to use, or does Sonic 3 go around this and arranges it so that the border is always black?

    I'll post more as they come back to me.
  2. The Taxman

    The Taxman

    Tech Member
    Retro Engine & Related Projects
    Ok, I'll have a crack at this:

    Re: Special Stages in Sonic 2
    1) The smaller resolution is chosen for speed reasons. Because the special stage isn't sidescrolling, to change a frame requires changing all the tile mappings for 1 layer. In normal gameplay the engine only has to append the tile mappings for the part of the level that is being revealed (the tile layers are first filled during the title card). So yeah, the more tiles you have to load and change the more overhead you have, and since the graphics are doubled in scale anyway it's not gonna make much of a difference using the smaller screen res.

    2)As far as I know, the graphics for the special stage are stored in the VRAM already doubled in width, and achieves double height via hsync raster effects. The graphics themselves may be stored in the ROM 1x size and loaded into VRAM 2x size for the width, but I can't can't confirm this since I haven't looked at the code. It'd make sense though, since they were trying to save as much space as possible.

    Why is Sonic 3 able to have 320x224 with no doubling? They used a different approach altogether. The globe tiles are all loaded into VRAM so nothing needs to be changed on the fly. The forwards motion is achieved by rotating the palette, whist rotating the globe is just changing the tile mappings.

    Re: 2 Player VS

    1) 2P VS mode uses 320x448 interlaced mode, which has a different tile mapping format. Only a few zones were perpared for this format (EHZ, CNZ, MCZ & the not quite done HTZ), so loading other zones creates artifacts.

    Now for the camera issues, this is because 2P mode uses line based (hsync) raster deformations to scroll the bottom half of the screen independently of the top. The unsupported levels don't have the code to do this so they don't scroll correctly, and you see tiles appear strangely, since it's loading the next parts of the level as if it's meant to scroll like the top half of the screen.

    2) I'm guessing they disabled water levels because it would require changing the palette up to 3 times instead of 1, which they either couldn't be bothered doing, or it would have caused problems.

    3) You're right, the first (transparent) colour of the MD palette is also the colour of the video border. Not ALWAYS but generally... whoops, my bad, The only reason why Sonic 3 has a black border is because they use black as the colour.

    Hope those answers are somewhat understandable! =P
  3. drx


    mfw Researcher
    It's because there is no code to handle three palette splits on the screen at one time. It *is* possible, and I have done tests before, but it gets REALLY slow after two splits.

    That is incorrect. There is a VDP register that you can use to choose which color in the palette to use for the border color. So, any color from the palette is choosable, but usually they chose the transparent colors, because they were redundant (well, mostly).
  4. Fred


    Formerly known as 'Neo' Oldbie
    Sonic 3 Unlocked
    Thanks for the answers so far, guys. You've helped a bunch.

    This doesn't answer one of my questions, though: is it possible to make all the other stages "work properly" (as far as resolving all drawing issues goes, anyway), save for the ones with water? And if so, would it be necessary to cut down something in the stages themselves?

    You say that "the unsupported levels don't have the code". Would the camera behave correctly if you just added the code to the remaining stages/made it global to all stages?
  5. Cooljerk


    NotEqual Tech, Inc - VR & Game Dev Oldbie
  6. Overlord


    Aros gartref, diogelu'r GIG, achub bywydau Moderator
    Berkshire, England
    Learning Cymraeg
    I always thought that S3&K used black for the border in that it gave a pseudo-widescreen effect, rather than just being a random colour - IE turning a technical limitation into something that looked more professional. =P
  7. Soldier


Thread Status:
Not open for further replies.