We just reached 30,000 articles on this wiki! 🥳
If you appreciate the work done within the wiki, please consider supporting The Cutting Room Floor on Patreon. Thanks for all your support!
This article has a talk page!

Development:Super Mario Kart/November 29, 1991 Proto

From The Cutting Room Floor
Jump to navigation Jump to search

This is a sub-page of Development:Super Mario Kart.

This cactus is UNDER CONSTRUCTION
This article is a work in progress.
...Well, all the articles here are, in a way. But this one moreso, and the article may contain incomplete information and editor's notes.
Hmmm...
To do:
  • Fix a lot of the formatting.
  • See individual todo's throughout.
Super Mario Kart Nov'91 Startup Screen

This prototype is dated November 29, 1991, however, it was built on November 7, 1991. The ROM was discovered in the July 24th, 2020 gigaleak, and can be found in NEWS_05/home/kimura/games/temp/game.hex as a precompiled Intel Hex file. As such, no assets (sprites, BG layouts, etc.) can be found within it.

A lot of work has been put into a Python script that repairs the game into a visually working state. Research has also been done as to how to make the repair the most historically accurate, however, not everything can be guaranteed to be 100% accurate on all accounts. This page will cover only the information that we can be certain or mostly certain of from the prototype.

Sub-Pages

SMK prerelease B1-X.BAK.png
Early Maps
Mario Circuit 2 and 4 had more jumps? Ghost Valley 2 had multiple branching pathways? This and more very early track layouts can be found here.

Hardware Differences

ROM

This prototype requires the use of a 1MB ROM, whereas the final game fits comfortably into 512KB. None of the banks of the ROM utilize any data in the regions xx:0000-xx:7FFF.

SRAM

Data that is saved to SRAM in this prototype saves to a larger and different area of memory, indicating the use of a larger SRAM chip during development. Comparison of the specs below:

Memory Mirror Storage Size
Prototype SRAM $70:0000 32 KB
Retail SRAM $30:6000 2 KB

SFX-DOS

This prototype makes use of a special in-house operating system intended to work on in-house development hardware. The software is known as SFX-DOS, and in-game it allows files to be saved between sessions by reading and writing data to an external floppy disk. This feature is used in the ED-1 and ED-2 modes.

(Source: MrL314)

General Differences

Hmmm...
To do:
  • there's a lot more
  • drifting mentioned in source files... how do you do it?
  • The boot up screen, title menu, race results, podium, kart select, and world select screens are not implemented yet.
  • This prototype does not include a sound driver, so there is no sound included in this prototype.
  • The game modes available in this build are "RACE" and "BAT" (Battle).
    • There are unfinished prototypes of battle modes: "test" and "gun".
  • This prototype uses the early item box graphics, showing 1p and 2p rather than 1 and 2.
  • Proto SMK Proto 1P.png SMK Proto 2P.png
    Final SMK Final 1.png SMK Final 2.png
    Nov'91 Font
    • Uses the font on the right for most debugging purposes. The 2 high font is not found in the final release.
    • Debugging editor modes can be used

    In Race

    • Drifting and hopping are not implemented in this version.
      • However, drifting is mentioned in the source files, but at this time it is unsure how it is supposed to be executed.
    • It's possible to turn arround while standing
    • Coins and Lives are not implemented yet.
    • Lightning, Boo and the 2x Coins items are not implemented yet.
      • There are unfinished items, one of which evolved into the poison mushroom in the final game.
    • AI players don't use items yet
    • When being in the underwater state, the driver is still visible above the water
      • Lakitu does not pick up the driver when being underwater
    • Lakitu's rescuing animations are unfinished; Drivers will rise up the screen immediately when going out of bounds.
    • The timer is not capped at 09'59"99. It counts all the way up to 99'59"99 and then loops back to 00'00"00 right after.
    • When falling off the track, a splashing effect is briefly shown.
    • Other drivers seen in the distance are a bit shaky, similar to the 1991 Alpha.
    • There is no pause screen when pausing the game by pressing Start.
    • When racing to the goal or end the race, the game won't fade out to any other screen and stays at the race.
      • There is also no winning animation yet and the driver's camera simply locks when driving over the finish line.

    Debug Controls

    • Soft Reset: You can exit any mode and go back to the main menu by pressing START+SELECT+Y+B
    • Mini RAM Viewer/Editor: Hold Down + L or R and press Select
    • CPU Usage Meter: Hold Up + L or R and press Select
    • Item debugger: Hold L+R+X and press A. The letter X will be displayed on the top left (this letter graphic got later replaced by the boo item graphic)
    • Frame Advance: When the game is paused, pressing R will advance one frame like in the Alpha 1991 build.

    Minor bugs

    Hmmm...
    To do:
    • other bugs (there's a lot more)
  • Not initializing RAM on boot causes a lot of very unpredictable bugs.
  • CLEA mode does not function properly in ED-1 mode after loading data via L-RAM or L-DISK.
  • The diagonal AI zones are slightly misprogrammed, meaning that they do not work correctly in the regular races. This is what most likely led to the diagonal checkpoints not being used in later prototypes.
  • CASTLE-1's AI data has issues with SFX-DOS saving and loading for ED-1 mode, since the checkpoint data is larger than the allocated space. It is in fact too large by exactly 2 zones (technically 3, since the last zone takes up the space needed to end the table).
    • This indicates that the maximum number of checkpoints allowed using this editor is 0x3f, making 0x3e the maximum stable checkpoint index for the ED-1 mode.
    • This bug can only be encountered if you set the file names properly
  • In Race

    • Boost panels do not work properly in this version, causing the AI to not be able to make it over some jumps.
    • Touching a wall while being underwater causes the driver to jump into the walls and possibly get stuck.
    • When someone crash into you kart while standing still, you won't get pushed away with any momentum, instead only moved some tiles away and standing still eventually.
      • Crashing into other driving karts while using a mushroom will cause the same effect on them.

    Track Specific

    • Lots of starting position data conflicts with finish line data, which means some races can't be completed normally.
    • Attempting to run the BATTLE-1 track in RACE mode will crash the game.
    • CASTLE-3's starting line data is completely missing, which messes up the starting line data for the tracks that come after
    • GRASS-3 is not completeable, since the data regarding the finish line placement is out of bounds of the normal table, and instead reads from different data.


    Main Menu

    Main Menu

    MODE

    There are 6 different selections for the MODE option. In order, they are

    • MAN-MAN
    • MAN-MON
    • MON-MAN
    • MAN-COM
    • COM-MAN
    • COM-COM

    For each selection the first part indicates the mode for the top screen, and the second part indicates the mode for the bottom screen. The functions of each mode are as follows:

    • MAN: Indicates that the screen will be used for a User-controlled racer. Nothing too special.
    • COM: Indicates that the screen will be used for an AI-controlled racer.
    • MON: Indicates that the screen will be used as a MONITOR screen. See here for more in depth information on the MON mode.
    (Source: MrL314)

    PLAY-1/PLAY-2

    These control the character that will be used for Player 1 (Top Screen) and Player 2 (Bottom Screen). The names displayed are internal names for each character, which are as follows:

    • MARIO - Mario
    • LUIGI - Luigi
    • KOOPA - Bowser (Refers to Bowser's Japanese name: クッパ, translating to "kuppa")
      • This is changed from the Alpha prototype, where he uses the direct translation: KUPPA.
    • PEACH - Peach
    • CONG - DK Jr. (Likely for "Donkey Cong")
    • NOKO - Koopa Troopa (Short for Koopa Troopa's Japanese name: ノコノコ, translating to "nokonoko")
    • KINO - Toad (Short for Toad's Japanese name: キノピオ, translating to "kinopio")
    • YOSSY - Yoshi (Refers to Yoshi's Japanese name: ヨッシ, translating to "yossi")
    (Source: MrL314)

    DISP-1/DISP-2

    Hmmm...
    To do:
    • maybe format this a bit better? different gif sizes maybe?
    • What is the cause of the major slowdown in NOPERS-2 mode?

    These control how the MON screen will be displayed for DISP-1 (Top Screen) and DISP-2 (Bottom Screen). The screen with the monitor on it seems to always be dimmed. The different display modes are as follows:

    • FR-VIEW: Normal view with camera behind kart, like final game
      • Allows use of the RAM Viewer / Editor (See details here)
      • The current checkpoint's target location is displayed by the track's object on the MON screen.
    • REA-VIEW: Normal view with camera in front of kart, like when you change the camera in the final game from the map to the "backwards" camera.
    • SD-VIEW: Like FR-VIEW, but the camera does not change its angle, always pointing north.
    • LONG-PER: Similar to the map screen mode in the final game, but with effects stated in NOTE 1 below.
    • NO-PERS1: Zoomed out Top-Down view of the map screen. Like LONG-PER, has effects of NOTE 1 below.
    • NO-PERS2: Zoomed in Top-Down view of the map screen, similar to the bottom screen of Mario Kart DS. Screen rotates with player angle. While perspective is top-down, it seems to be a bit warped as if not looking directly down. Also has effects of NOTE 1 below.
      • For some reason, the game experiences major slowdown using this mode while there are other objects on screen.
    • NO-PERS3: Zoomed in Top-Down view of the map screen. Like NO-PERS2, but the camera does not rotate. While perspective is top-down, it seems to be a bit warped as if not looking directly down. Also has effects of NOTE 1 below.
    (Source: MrL314)
    FR-VIEW REA-VIEW SD-VIEW
    SMK Nov'91 DISP FRVIEW Mode.gif SMK Nov'91 DISP REAVIEW Mode.gif SMK Nov'91 DISP SDVIEW Mode.gif
    LONG-PER NO-PERS1
    SMK Nov'91 DISP LONGPER Mode.gif SMK Nov'91 DISP NOPERS1 Mode.gif
    NO-PERS2 NO-PERS3
    SMK Nov'91 DISP NOPERS2 Mode.gif SMK Nov'91 DISP NOPERS3 Mode.gif

    NOTE 1: The sprites are not resized to be larger. Instead they are sized according to their distance from the map screen's camera. Also unlike the final game's map screen, these modes display the track objects (pipes, moles, bubbles, flowers, cheep cheeps, etc.) also using the sprite size according to the distance from the camera.


    (Source: MrL314)

    PROG

    RACE

    Careful, you'll lose an eye.
    This page or section needs more images.
    There's a whole lotta words here, but not enough pictures. Please fix this.

    The race mode during this stage in development is mostly finished. At this time, each race contains 8 players, and a 5-lap drive around the track like the final game. However at this point in development, Grand Prix does not exist. When the player finishes a race, the camera no longer turns with the racer, but will follow the racer's position (like the SD-VIEW mode).

    Interestingly, the "finished racers" sidebar in the final game is slightly different in this version. Instead of only showing racers as they finish the race, the entire set of 8 is displayed at all times, and will automatically update during the race to show the racer positions. In effect, this acts similar to the sidebar mode in Mario Kart 64, but instead of only showing the top 4 racer's positions, it will show all 8 players.

    Unlike later prototypes, this prototype does not include a life counter, or a coin counter. Neither of those existed at this point in development, so there are no HUD elements showing the lives or coins.

    (Source: MrL314)

    BAT

    The battle mode at this stage in development is highly unfinished. This build includes two battle modes, which internally are called test and gun. Both of these battle modes are merely proof of concept ideas, and have no implementation of a way to "win" the battle. The battle modes are selected by the BATTLE OBJ option in the ED-3 mode. (See below for description of ED-3).

    "TEST" battle

    TEST battle (Source: MrL314)
    Ball kick

    This mode consists of 12 objects moving around the battle field. On the top screen, these objects are displayed as 3D coins, which have an animation to them. However, on the bottom screen these objects appear as the balloons that you see in the final version of the game (I will be referring to the objects as "coins", for brevity sake). This mode has a few bugs however:

    1. It seems like the coins are meant to have collision, but due to a bug in the code, each coin can only collide with another object once before losing the ability to interact with it.
    2. Due to uncleaned RAM, the coins that are allocated between $7E:0800-$7E:0AFF have their collision-based RAM set as garbage bytes. This means that sometimes these objects will not start with the ability to be collided with.

    The Bound Power Value in ED-3 menu sets besides the knock back value the speed of the objects.
    If by luck you are able to touch the objects without the collision bug, they will be kicked away by the player with momentum, kinda like kicking a ball away. Depending on with how much speed you kick the object with, the object will gain more speed. Sometimes, however, you are hit on contact, as if you had run over a banana peel.
    After some time the objects stop moving until they are kicked by a player.
    Items are completely disabled in this mode, and even using the Item debugging option, no items will take effect in this mode.

    It could be assumed that the goal could be to kick the objects like soccer balls, and looking at the battle map with the solid target line, it could be possible that you are supposed to kick it into the opponent's field similar to volley ball.

    Due to the nature of how this battle mode looks, fans have referred to this mode as "Coin Collection" mode, however it is unverified whether this mode has any connection to the Coin Collection battles seen in later games in the series.

    (Source: MrL314)

    "GUN" battle

    Hmmm...
    To do:
    • is there any reference whatsoever to the gate mode in this prototype, or is it completely after this version?
    GUN battle (Source: MrL314)

    This mode consists of the two players holding an objects behind them, similar to how you can hold shells and bananas in later games in the series. When the player presses L or R, the player fires their respective object forward, and it disappears after a certain amount of time. For the top screen, the object appears as the 3D coin mentioned above, and for the bottom screen the object appears as the balloon mentioned above.

    These objects act like green shells with a limited lifetime, and are able to bounce off of walls. When the object collides with a player, it also acts similar to a shell, spinning the player out. There is no limit to how fast you are able to fire these objects, however the limited storage space of the game means you aren't able to fire an infinite amount. However, you are able to rapid-fire these objects, and considering the internal name for this mode is "gun", it is very likely that this battle mode is the "machine gun mode" referenced in this developer interview.

    Items are completely disabled in this mode, and even using the Item debugging option, no items will take effect in this mode. This mode also does not have a scoring system, so there is no way to "win" the battle. The drivers will also constantly turn their head during this mode, since they recognize the object they are carrying behind them as similar to a racer, which is when they usually would turn their head.

    (Source: MrL314)


    Here are the animations of the battle objects:

    Top Screen Object (Coin) SMK Prototype Coin Animation.gif
    Bottom Screen Object (Balloon) SMK Prototype Balloon Animation.gif

    ED-1

    This mode is a early version of the EDIT1 MODE found in later versions of the game. Most of the information on that page is unchanged from this version to the later versions.

    One minor difference is that when setting zone types 0A and 0C, if the Y distance is exactly 3 more than the X distance, the game will display the zone incorrectly in the editor. This can be fixed by setting $10C57E to 00.

    Interesting to note is that internally the game only has a few pointers for the track name specified for saving and loading via the SFX-DOS, even though the code itself allows the pointer to read from a table much larger. Mario Circuit's save file names are all named by RBIR-1x, meanwhile 7 other track's save file names are called CIRC-2x, and use the same name (where x is the save slot number). The rest of the tracks load data from out of the table, so the file names are corrupted text. Also the save file name does not correlate to the track name displayed on screen, since it is a default value hard-coded for OAM.

    EDIT1 Layout Comparison
    Nov'91 ED-1 Later EDIT1
    SMK ED1 Nov91 Layout.png SMKDebug Edit1-AIareas.gif


    (Source: MrL314)


    ED-2

    ED-2 Available Objects (source: MrL314)

    This mode is a early version of the EDIT2 MODE found in later versions of the game. Most of the information on that page is unchanged from this version to the later versions, however there are fewer objects in this version of the editing mode.

    This build only includes the options to place 4 types of objects:

    • QUES: Item Panel Tiles
    • NIKO: Used Item Tile
    • AROW: Speed Boost Arrow
    • KABE: Multicolored 2x2 Wall

    Coin tiles and oil slicks have not been implemented at this point, so they do not appear in the editor yet.

    Interesting to note is that internally the game only has a ONE pointer for the track name specified for saving and loading via the SFX-DOS, even though the code itself allows the pointer to read from a table much larger. Only Mario Circuit 3 can save and load to the SFX-DOS, since it is the only track with data specified for save file names. It uses the save file name CIRC-1x, where x is the save slot number. Also the save file name does not correlate to the track name displayed on screen, since it is a default value hard-coded for OAM.


    (Source: MrL314)

    ED-3

    Nov'91 Debug Menu
    MARIO Debug Option

    This mode is an early version of the Debug Menu. As such, most elements from the later debug menus are missing. However, two of the debug options stayed in this menu:

    There are three other options in this menu that don't seem to appear in later prototypes:

    • BATTLE OBJ
    • BOUND POWER
    • MARIO

    BATTLE OBJ: Value is supposed to be bounded between 00 and 01, however due to unclean RAM it will sometimes start with a different value.

    • 00 - Sets the Battle Mode to "TEST" mode
    • 01 - Sets the Battle Mode to "GUN" mode, as referenced in this developer interview.

    BOUND POWER: Represents the power at which objects are knocked back by collisions.

    MARIO: This option will load up a screen with all 8 characters' sprites loaded up at a skewed angle. Unsure at the time if anything else is supposed to happen on this screen. Interestingly, the driver sprites are loaded in VRAM in Mode 7 format, possibly a scaling test?


    (Source: MrL314)

    Track Theme Differences

    Hmmm...
    To do:
    • Track BG comparisons. Can those be verified in any way?

    This is a shady area when it comes to the tilesets and verification. Please make sure to read the discussion section about why we came to these conclusions, and what information for the tilesets we actually can be certain of. The tilesets provided here are our best estimates based on tile property data found within the code, as well as cross referencing with known tileset data and dates.

    Shared Tileset

    At this point in development there is no oil slick or coin tile, so the shared tileset is different from later builds. It is highly likely that the early rounded item panels were used.

    Nov'91 Set Final Set
    SMK Nov91 Shared Tiles.png SMK final Shared Tiles.png
    (Source: MrL314)


    CIRCUIT (Mario Circuit)

    Hmmm...
    To do:
    • compare BGs
    • gif showing animation
    • any differences in tileset?

    Mario Circuit at this time uses a test for the track animations. This test animations consists of cycling the colors of the barriers of the track. All of the CIRCUIT tracks share this animation.

    Nov'91 Set Final Set
    SMK Nov91 CIRCUIT Tiles.png SMK final MC Tiles.png
    (Source: MrL314)

    OBAKE (Ghost Valley)

    The breakable blocks have not been implemented yet, so there are no barriers to the tracks. The unused tile is in the spot of where the checkered tile would usually be, indicating that the finish line checker was not intended to be used on this track yet? Due to the source of this file being relatively old, it is also likely that the checker tile was in fact used, however this is unverified.

    Nov'91 Set Final Set
    SMK Nov91 OBAKE Tiles.png SMK final GV Tiles.png
    Hmmm...
    To do:
    • compare BGs
      • early Boo BG used.
    • Is the finish line tile implemented in GV yet?
    (Source: MrL314)


    GRASS (Donut Plains)

    Hmmm...
    To do:
    • compare BGs

    Interestingly, only one tile is different. It is an extra grass tile that has the "road" physics property. In the source code itself, there is even this comment about the tile, calling it unnecessary.

    	byte  00h;<<<<<unnessesaly
    Nov'91 Set Final Set
    SMK Nov91 GRASS Tiles.png SMK final DP Tiles.png


    (Source: MrL314)

    CASTLE (Bowser Castle)

    Bubble behavior (Source: MrL314)

    Extra STOP tiles, early arrow tiles. The "Dark Lava" tile is brighter. Instead of using Thwomps as the track object, the Nov'91 prototype uses the Bubble object (seen on the right).

    Nov'91 Set Final Set
    SMK Nov91 CASTLE Tiles.png SMK final BC Tiles.png
    Hmmm...
    To do:
    • compare BGs
    (Source: MrL314)


    ICE (Vanilla Lake)

    • The breakable ice blocks have not been implemented yet
    • The ice water does not act like other water tiles, instead drivers will be picked up immediately like when driving into lava.
    Nov'91 Set Final Set
    SMK Nov91 ICE Tiles.png SMK final VL Tiles.png
    Hmmm...
    To do:
    • compare BGs
    (Source: MrL314)


    DART (Choco Island)

    • There are a few mud puddles not implemented yet.
    • The offroad tile slows the kart down dramatically in this build.
    Nov'91 Set Final Set
    SMK Nov91 DART Tiles.png SMK final CI Tiles.png
    Hmmm...
    To do:
    • compare BGs
    (Source: MrL314)


    SAND (Koopa Beach)

    Cheep Cheep behavior (Source: MrL314)

    While the finish line tile is included in the tile set, the actual tiles used for indicating the finish line include the horizontal line in the sand to indicate the racer staring positions, as well as two extra tiles that would be a part of the "wet sand" and be used at the edges of the finish line.

    Nov'91 Set Final Set
    SMK Nov91 SAND Tiles.png SMK final KB Tiles.png

    Cheep cheeps also do not have any AI at this point, staying completely stationary.

    Hmmm...
    To do:
    • compare BGs
    • update gif. Uses wrong sprite set for cheep cheep.
    (Source: MrL314)

    Other notes

    Hmmm...
    To do:
    • other notes

    Actual build date?: While the rom is dated November 29, 1991, the map file for the rom (game.map), contains an actual build date of November 7, 1991.

    ED buffer error: Normally in ED-1 and ED-2 when you call L-DISK, data is read in via the SFX-DOS from an external floppy disk, and the data is written to a buffer in RAM. After this data is written, the game will parse this data and represent it accordingly in the editor. However, the SFX-DOS uses the same buffer in RAM for both when writing AND reading data via the SFX-DOS. If you disable the SFX-DOS functionality (by calling RTI immediately from the COP vector), when you use the S-DISK function the data will be written to the RAM buffer, but will not be written via SFX-DOS. If you then use the L-DISK function after doing so, the game will read the data that was previously written to the RAM buffer, giving the illusion that it is reading data via the SFX-DOS. This is not the case, it is only reading the data from the RAM buffer that was previously written to.


    Finish Line data: The data for the finish lines and starting positions for the racers in the code is inconsistent, however some of the finish lines do not line up with where they should given the checkpoint data. In a few cases, the finish line is maybe a few tiles off, but in other cases like MC4, the finish line zone data is on the opposite side of the map. However, this should not be taken at face value. BOTH the starting positions for the racers AND the finish line data are hard-coded into the game, meaning both are completely valid points for basing results off of. The finish line data is also incomplete since for some reason CASTLE-3's finish line data is completely omitted from the data table, throwing off the data for the remaining tracks after it.


    (Source: MrL314)

    Unused Material

    This cactus is UNDER CONSTRUCTION
    This article is a work in progress.
    ...Well, all the articles here are, in a way. But this one moreso, and the article may contain incomplete information and editor's notes.
    Careful, you'll lose an eye.
    This page or section needs more images.
    There's a whole lotta words here, but not enough pictures. Please fix this.

    Items

    Careful, you'll lose an eye.
    This page or section needs more images.
    There's a whole lotta words here, but not enough pictures. Please fix this.

    The item pool in this prototype is different than the final version of the game. For one, the Boo, Lightning, Coin, and Poison Mushroom are not implemented yet. However, there are unused items left in the game's code, one of which will look familiar. Internally these items are called:

    • coin
    • packn
    • kinoko

    Interestingly, the Red Shell is called "missile" in the source code, and the feather is simply called "jump".

    In the HUD, these items appear as green versions of normal item sprites, with "coin" using the banana sprite, "packn" using the star sprite, and "kinoko" using the mushroom sprite.

    When used, these items can be placed on the floor similar to a banana. The coin is also the same coin sprite set used in the Battle Modes, and has an animation as well.

    The "kinoko" item would later become the Poison Mushroom used by Toad and Peach in the final game.


    The items can be seen in action here.

    Logo Arches

    Careful, you'll lose an eye.
    This page or section needs more images.
    There's a whole lotta words here, but not enough pictures. Please fix this.
    Hmmm...
    To do:
    • How to activate the logo arches? (Action Replay code, patch, etc.)
    • Images/Gif

    Another unused but almost fully programmed object in the game's code is referred to as a "logo arch". Considering the data on these arches, these would have been placed over the finish lines, and display some text on them. These are inspired by the famous "Dunlop Bridges", and are directly referenced in the code as one of the logo arches spells out DUNLOP.

    There are four arches, each with different text. Two of them are confirmed to line up with the starting line for CIRCUIT-1 and CASTLE-1. The arches when displayed spell

    • NINTENDO: Confirmed to match up with CIRCUIT-1's finish line (Mario Circuit 3)
    • CASTEL : Confirmed to match up with CASTLE-1's finish line (Bowser Castle 2). Is misspelled.
    • TROPICAL: Unconfirmed which track this would have been used on, however the name implies SAND-1 (Koopa Beach 2).
      • From the coordinates, it seems to line up with right side outer edge of Koopa Beach 2 (SAND-1).
    • DUNLOP : Unconfirmed which track this would have been used on.

    While it appears that the logo arches stop the driver if they try to drive through it in the reverse direction, this might be an issue with how the arches were repaired (see below). It is not certain that the arches had collision, but there does not seem to be any collision code for the arch.


    The logo arches can be seen in action here along with additional information and the positions.


    (Source: MrL314)