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

Eh, I'm sure you'll enjoy what we have to offer in the end~

EDIT: "~"

Green Snake, on 22 July 2015 - 04:06 AM, said:

I agree. But that was not what was said. He said it "set" the bar (past tense, which is true), not "is" the current bar.

In fact...

...Megamix has passed it's own bar since too, but of course, you wouldn't know that given Megamix has not had a proper release since. The thing is, the bar can only be set by released content, most other hacks have been released post, therefore, they have set a higher bar (that's logic, expected, and common sense really), Megamix "did" set the bar, and it will set a higher bar when it is released. In my opinion, it already surpasses the current bar set by other hacks in its private state even now, and a lot of hacks being released at the current time don't really live up to what we have in store already, nevermind what we'll have in the future. So sit back, be patient, and we'll deliver eventually. Of course, donations help reduce the time of "eventually" (which is what the recent discussion of this thread is pretty much all about...).

In his defence, I was actually tempted to post and ask the same thing. Even after clicking around, it wasn't exactly 100% apparent to me, that it was an official page.

er1c1996, on 08 July 2015 - 06:58 PM, said:

Your only 100% way of detecting if a block is a floor, wall or ceiling of some kind, is by checking a combination of things:

• Collect the chunk ID. If it is 00, then all blocks will automatically be 0000 (therefore it is safe to assume it is nothing but an air block). If not, then...
  
• Collect the block from the chunk. If it's SS bits are both 00, then there is no collision (it's either an air block, or a "background" (foreground design) block). If not, then...
  
• Using the block ID, collect the collision ID from the collision table, and use that collision ID to reference the correct collision array block (10 bytes), if all of those 10 bytes are 00, then the block won't have any effect (treat it as air/background). If not, then it is a solid floor/wall/ceiling block of some kind.

Unfortunately, comparing it to Mario, you're looking at a difficulty step like no other. Certain slopes will cause Sonic to slow down at a gradual pace, so you'd need to take the angle into consideration, and decide if Sonic should continue running up the slope, or go back and take a run up. It'll be the case of Speed vs Angle. However, judging by the Mario one, it seems the I/O was able to keep up a good pace, if it can do the same for Sonic, then it is possible that checking for slopes can be avoided entirely. I was also going to point out the whole "top solid"/"left, right, bottom solid"/"all solid" issue, but Mario also has top solid situations, so I assume that one's covered.

So, I wasn't able to view that video in a high enough quality to see the values (my connection isn't very solid at times), I will tell you what I know though...

You'll start with the layout which is decompressed and loaded to RAM A400+, and every 40 bytes represents a line of chunks, this means:

• A400 - A43F = Top line of FG chunks from left to right.
  
• A440 - A47F = Top line of BG chunks from left to right.
  
• A480 - A4BF = Second line of FG chunks from left to right.
  
• A4C0 - A4FF = Second line of BG chunks from left to right.
  
• A500 - A53F = Third line of FG chunks from left to right.
  
• etc, etc...

Each byte in these lines is a single "chunk" (a square section displaying 256x256 pixels), the byte references the chunk table stored in RAM at 0000+, when reading the byte from the layout:

• 01 = Chunk 01 (RAM 0000 - 01FF)
  
• 02 = Chunk 02 (RAM 0200 - 03FF)
  
• 03 = Chunk 03 (RAM 0400 - 05FF)
  
• etc, etc...

Please note; 00 automatically places a "blank" chunk (empty and transparent). The chunks consist of words in a grid, each word is a single "block" (a square section displaying 16x16 pixels inside the 256x256 square), the words referrence blocks, this means:

• 000 - 01F (10 words) = Top line of blocks in the chunk
  
• 020 - 03F (10 words) = Second line of blocks in the chunk
  
• 040 - 05F (10 words) = Third line of blocks in the chunk
  
• etc, etc...

The words from these chunks are setup in the following format (Binary): 0SSY X0BB BBBB BBBB

• SS = Solidity "status" of block (00 = No solid | 01 = Top solid | 10 = Left, Right & Bottom Solid | 11 = All solid) - This is not the solidity itself, but rather a state control.
  
• Y = Block flip vertically (0 = No | 1 = Yes) - Note, these flip/mirror flags effect the solidity shape's flip/mirror
  
• X = Block mirror horizontally (0 = No | 1 = Yes)
  
• BBBBBBBBBB = Block reference ID

The block reference ID can only be from 000 to 3FF. This references from the block table at RAM B000+:

• 000 = Block 000 (4 words - RAM B000 - B007)
  
• 001 = Block 001 (4 words - RAM B008 - B00F)
  
• 002 = Block 002 (4 words - RAM B010 - B017)
  
• etc, etc...

^ the block table is useless for collision, it's for displaying tile patterns. But the block reference ID can also reference from a collision table. The collision tables are uncompressed but stored in ROM, here is the table offset in ROM of a Rev00 Sonic The Hedgehog game:

• ROM 004100 = Green Hill Zone long-word collision table pointer
  
• ROM 004104 = Labyrinth Zone long-word collision table pointer
  
• ROM 004108 = Marble Zone long-word collision table pointer
  
• ROM 00410C = Starlight Zone Zone long-word collision table pointer
  
• etc, etc... (In order of level ID)

The pointers will point to a table of collision IDs, for example, Green Hill Zone's pointer is "00 06 4A 00" (ROM offset 064A00), at that offset we have:

00 FF 1A 00 00 00 1A 00 1D 1C FF FF 09 14 0B 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF .... etc

Using the block ID, you can collect the correct collision ID. If the block ID is 006, you collect the 006th byte from the collision table, which is 1A. The collision ID is then referrenced from a collision and/or angle array, these can be found at:

• 062900 - 0629FF = Angle reference table
  
• 062A00 - 0639FF = Collision array normal
  
• 063A00 - 0649FF = Collision array rotated (for 90 degree collision with loops and sharp curvers/walls)

Using the collision ID we collected, we can reference the correct angle the block is using (062900 + Collision ID = offset of the block's angle ID). We can also reference the collision array. To brief aside about the collision array, this is a series of values that represent a soldity shape that the block has, be it a curve of some kind, or just a flat solid surface. Each collision block is 10 bytes big, this means:

• Collision ID 00 = 062A00 - 062A0F (Collision block 00)
  
• Collision ID 01 = 062A10 - 062A1F (Collision block 01)
  
• Collision ID 02 = 062A20 - 062A2F (Collision block 02)
  
• Collision ID 03 = 062A20 - 062A2F (Collision block 03)
  
• etc, etc...

Each byte of the collision block is a solid height from left to right of the block, for example: 00 00 00 00 00 00 00 01 02 03 04 06 07 08 0A 0B will give you:


If the number is positive from 00 to 0F, the solid starts from the bottom and rises to the top (for floor pieces).
If the number is negative from FF to F1, the solid starts from the top and drops to the bottom (for ceiling pieces).

The exact same method is used for the rotated collision, except, the numbers would be from left to right, and right to left (depending on positive or negative): 00 00 00 00 00 01 02 02 03 04 05 05 06 07 08 09


It is extraordinarily complicated, and one thing to explain, yet another to understand. The design (in my opinion) is the work of pure genius, and when understood, you can begin to appreciate the efforts that went into constructing a format, that provides a nice balance between speed and memory usage. For large level construction it is the most ideal.

For more information about the format, see this page: http://info.sonicret...g/Level_Editing