Quote: "Gravity is pretty straightforward, as is movement (although, our super hero does have the ability to change directions and pick up speed in mid air...).
"
There is no global gravity as such. THe effect of gravity is defined on the characters only.
Quote: "The background movement is absolutely great. I'm just blown away by the design work involved there, not just backgrounds, but the whole game, top to bottom. There is so much art there it's not even funny. They must've worked for eons to put that game together"
The graphics processor in the genesis is known as the VDP, and it allows for some ancy effects in that regard. There are two main layers of tiles, those being a and b. You can perform raster effects on one layer without affecting the other whatsoever, and these raster effects are hardware supported, so they run lightning fast. They used these effects to create the background movement and 2 player splitscreen effect. The only limitation of these effects is that they have to be based on horizontal rows of pixels.
Quote: "Did thy use several maps that act as one (several background levels, then the foreground)?
For the editor, would they have mocked up some kind of grid-based editor to place the map pieces? "
Yes. Layer A and B are constructed out of rows of 128x128 pixel blocks, which are arranged in a fixed grid pattern.
Quote: "What about an editor to configure the settings for each piece? Some things you can jump through, others you cannot. Where that gets interesting is where Sonic CAN jump through a tree (so, it's as though it's not really there), and yet, a bonus box (speed, sheild, etc.) can sit on TOP of a tree (whereas Sonic can't). So there's obviously some pretty serious configuration going on there."
Each peice does not have an individual setting, but they did some very clever things with collision. I'll tell you about that later on.
Quote: "What about the animated pieces that only start when Sonic actually touches them (bridges, continue points, crumbling sections of the map)? "
There is a VRAM which buffers all the patterns that have to be used at any one given time. To create an animated effect, they could either load all the frames of the animation in the VRAM at one time, and just change the block numbers being used, or they could realod the appropriate patterns into the VRAM over the top of the old ones. The first method is preferred because it uses less power, but it also uses more video ram, so they sometimes have to settle for the second depending on how much has been used already.
Quote: "Do all the map pieces conform to a certain set of size constraints (i.e., each dimension must be in a multiple of 8 pixels)? "
Heh, you're not going to believe this part. Every single block you see in the game is made up of 8x8 pixel blocks, which is a requirement of the VDP. In order to construct the 128x128 pixel blocks used in the levels, they use what have been dubbed mappings to construct larger blocks out of these 8x8 blocks. First, there are the 16x16 block mappings. When defining the 16x16 block mappings, you can flip and mirror any of the 8x8 blocks being loaded in, and you specify the palette line to use for that block (The genesis has 4 16 colour palette lines). There's then the 128x128 block mappings, which are a collection of 16x16 block mappings. The only thing that can be directly placed into a level is a 128x128 block, and a sprite.
Quote: "What's amazing is the framerates those guys were able to achieve working off that z90 and hacking in pure machine code. I've seen far more trivial games use infinately more media and not look as good as this."
Well, the genesis used a M68K as the primary chipset. The Z80 was used as a sound processor. It was programmed very well though.
I'll also let you know how the collision works. First of all forget the image that the block contains. The image has absolutely nothing to do with the collision. There's basically in invisible collision box on top of every 16x16 block that sets what's solid and what's not. This collision box has two parts to it. The main part of it is the collision array. The collision array stores the actual data that says that is a block is solid in certain places. It does that through 16 bytes per collision box. To understand how those 16 bytes set what's solid, imagine a 16x16 block. Now imagine that 16x16 block with the numbers 1-10 (hex) down the side starting from the bottom and going up to the top, and starting from the left and going up as it moves right along the top, so that you can give an exact location of each pixel. (eg, the top left pixel would be 10,00) Now, in this array the first two bytes define what's solid for the row of pixels on the left side of that 16x16 block. Basically the first of those two bytes says where to start making things solid, and the second byte says where to stop making them solid. So if you entered the value 0010, the first row would be solid from the very bottom of the block all the way up to the top. If you were to enter the value 020E, there would be two pixels on either side of the block that are not solid, and everything in the middle would be. The next two bytes after that are for the next row, etc. After 16 bytes the definitions for the next collision box begin.
Now, to specify which blocks use which collision boxes, there are collision indexes, which give an array location for each 16x16 block. If you look at the space used by the collision array, you can divide that by 16 (the number of bytes used by each entry into the array) to give a one byte value, which represents the maximum number of collision boxes that the array can hold in the S2 platform, which is FF. Now, for each level there is at least one 16x16 collision index, and that index consists of a whole heap of array locations, one for each 16x16 block. If for example you wanted the 9th 16x16 block to use the collision box with an array location of 3E, you would give the 9th byte of the collision index for that level a value of 3E.
It is through collision indexes that the loops work in the game. For any levels that use multiple collision layers like that, there is a secondary 16x16 collision index. There is a sprite that switches between the 16x16 collision index in use.
Now just setting something as solid, doesn't give it the effect of having a slope. There's anotehr array in the rom, which has one byte in it for each collision array location. To understand how this value works, think of two lines running parallel to each other, both with the value 0-F along them. Now, the first value of the byte gives a point on the right line, and the second value gives a point on the left line. Now imagine drawing a line between these to points. If the points are different, the resulting gradient will be taken to create the effect of a slope and the resistance going up it on the box in the corresponding collision array location.
Sprite collision is handeled differently though. Sprites can have two collision boxes, one active, and one passive. The active one is used for effects, such as when two active boxes touch, run this section of code. They use this box for collisions with enemies. The second passive one is used for collision against the level itself.
I know everything! At least I don't know anything I don't know.
