don't click here

How does the tile layer/plane system work in games past Sonic 1?

Discussion in 'Engineering & Reverse Engineering' started by foobles, Oct 9, 2022.

Tags:
  1. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    If I were to write my own loop system, I would have an object (like in S2) that changes the layout (like in S1) when Sonic touches it. Much simpler than hardcoded chunks or any nonsense with collision planes. You'd need a second level layout for player 2 of course.
     
  2. Xiao Hayes

    Xiao Hayes

    Classic Eggman art Member
    I don't see why. I mean, I get you don't need blocks with dual collision everywhere, having it on the blocks themselves makes it ready from the start, and it's already a second layout that each character can handle with their own flag instead of competing with others to get the right collision or running through a couple of twin loops one in front of each other and assigned to each player. What I would do is similar to what you suggest, though: I'd set flags that tell if the block is permanent or it shifts, and in which layer (0, 1 and 2 values would do), and add to the shifting blocks the ID of the block they shift with. You'd have less info per block but need some more blocks on your list, and it would be handled like S1 without needing to change the blocks with a new routine: block 1 loads by default but applies it's sibling's collision if the player is on layer 2 without a general remapping or character-specific layouts, just a pointer for a different block when needed.
     
  3. Brainulator

    Brainulator

    Regular garden-variety member Member
    I went over some oddities with Star Light Zone's loop chunks here. Something I didn't mention is that Sonic 1 felt the need to not only use the most significant bit of the chunk ID to indicate that a chunk is a loop chunk, but also check whether the chunk you're on matches either one that's been put into RAM. Why not stick to one or the other? Was it an old design choice that the game had to suffer from later in development?
     
  4. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,192
    405
    63
    Japan
    SLZ's 2nd loop forces Sonic to path 0 if he's in air, the 1st loop doesn't, a single bit won't distinguish that.

    It's quicker to "bmi" to chunk swap code for collision detection, than to compare against both ID's.

    That's why both are used.
     
  5. Xiao Hayes

    Xiao Hayes

    Classic Eggman art Member
    While I think this wasn't directed to me, if I understood it, my idea would work worse?

    In any case, after writing that hastily I noticed I wouldn't need shifting blocks for two layers, just putting the shifting one as the default one and using the block ID to point towards a standard block ID for the alternate layer would work too. I have some notes about layers I did a long time ago that more or less handled the layers that way (I wrote that from memory) because I was designing how to handle more layers (default 0, negatives for behind 0 and positives in front of 0, higher number for higher depth/proximity). Not very useful for MD games, but I had some absurdly complex loops in mind so I needed them.
     
  6. saxman

    saxman

    Oldbie Tech Member
    Would anyone care to explain how Sandopolis loops work? I have never looked into it myself, so I have no clue. But they clearly need some kind of trickery to do what they do within the two-plane model.
     
  7. Devon

    Devon

    Down you're going... down you're going... Tech Member
    1,218
    1,374
    93
    your mom
    They use a second path swapper made specifically for that. Basically just resets Sonic back to the first path a couple of times before letting it remain on second path.

    [​IMG] [​IMG]

    (The green rings there are just the object that makes Sonic spin into a ball when touched)
     
    Last edited: Oct 12, 2022
    • Informative Informative x 1
    • List
  8. saxman

    saxman

    Oldbie Tech Member
    So I'm guessing the bottom path swapper has a flag that if not set, gets set and resets the path. If already set, do nothing. And going the opposite direction does the inverse operation. Or to draw it out:

    Code (Text):
    1.  
    2. If path is #2 {
    3.   If flag set {
    4.     // Do nothing
    5.   }
    6.   Else {
    7.     Set flag
    8.     Set path to #1
    9.   }
    10. }
    11. Else {
    12.   // Do nothing
    13. }
    14.  
     
  9. Devon

    Devon

    Down you're going... down you're going... Tech Member
    1,218
    1,374
    93
    your mom
    It actually uses an internal counter to decide when to set a path.
     
  10. Lapper

    Lapper

    Lappering Tech Member
    1,763
    951
    93
    England
    Sonic Studio, Sonic Physics Guide, Kyle & Lucy, Freedom Planet 2
    I was looking at these recently and I'm fairly sure this is a check for the Player being grounded rather than being Y flipped. Code checks bit 1 of the Player status, for general objects that's Y flip, but for Player that is their grounded state.

    (Also just made sure by moving a "subtype bit 7 flagged" switcher down to the bottom of a loop and it still worked :P )

    -
    Also, just noting here that the Sonic Physics Guide now has a page on how path switchers work & are used.
    It goes in depth about the conditions based on the Player's position needed to activate them, but could use more information/clarity regarding the collision layers themselves and some other aspects.
     
    • Informative Informative x 2
    • List
  11. Devon

    Devon

    Down you're going... down you're going... Tech Member
    1,218
    1,374
    93
    your mom
    That would be correct. My bad.
     
    • Informative Informative x 1
    • List