If you want to find it yourself via searching, this will work:
At any rate. While this post is going to get technical, I feel like I should point out - a lot of what I'm going to be detailing in the explanation is conjecture. I haven't tested it empirically, and I'm not even sure if there's a way to do so. Having said that, based on what I do know about the game's logic, the trick itself, and the tile involved, I'm reasonably convinced that my conjecture is at least close to what's going on. There'll be a shorter explanation at the bottom of each section in bold, in case you don't feel like reading through all these walls.
---
So, let's get started. First off - What is the "walking on walls" trick?
I'll start out by admitting that I don't know the background behind the genesis of the trick. In his 2006 post on the subject, Amadeus! states simply that:
I don't know how VirtLands discovered this code, or how he managed to figure out how to apply it to the level itself. The key part here is that it was found.Amadeus! wrote:Here's a picture of Stinky walking on top of a wall after implementing a code that VirtLands discovered.
The level itself is extremely small - a simple 4x7 set of tiles, shaped like this:
Code: Select all
XXXX
XH_X
XH_X
XHF*
XH_X
XH_X
XXXXThe * is special - we'll get to that a bit later.
Unless you follow specific instructions before loading the level, the game will crash. Specifically, you have to load up another level in-game first. On loading the test level itself, the instructions were to "hold right" before the level fully loaded (the screen finishes fading in). If done correctly, then there was a chance Stinky would appear on top of the walls, like so:
For some reason, this trick is very hit-and-miss. To the best of my knowledge, no one is 100% certain as to why (though I detail my suspicions on such below).
Short version: The walking on walls trick is a strange phenomenon in a test level posted in February 2006 (download since removed, however). This behaviour has not, to my knowledge, been reproduced on any other levels, in part because it's very hit-and-miss and in part because it makes the game extremely unstable.
---
So, that's what the walking on walls trick is, what the level itself is like, and so on. Next question: What is it about the level that causes the odd behaviour?
The level cannot be loaded in the level editor; it will simply crash. The reason for both the crashing and the trick happening in the first place is that the level file's been modified in a hex editor.
Hexadecimal is a numeral system with a base of 16. The most common base is base 10 - the decimal system we're all used to. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, and so on - 10 unique symbols.
Hexadecimal has 16 symbols - 0 through 9, plus A, B, C, D, E, and F. As a result, counting in hex is different to counting in decimal:
Code: Select all
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12The classic trilogy of the series stores its level files in hexadecimal - Level size, music, time limit, background, texture, and so on. Unless you know what you're doing, editing a level with hex is extremely dangerous. It's very easy to corrupt a file, preventing it from being loaded in the editor or even in-game (I don't know for sure, but I believe the editor is hard-coded with regards to what tiles it can and cannot load, which is why it crashes more readily than the game itself).
I have a full set of notes on what I've decoded of the classic trilogy's level format, but there's only one part of it that's relevant here - in the latter half of the file, the level's tile and object layout is stored, in two simple arrays that are scaled according to the size of the level itself. In other words, a 14x14 level will have a 196-entry-long array for both tiles and objects, regardless of how many objects are actually in the level itself. Tiles with no objects on them are simply blank.
In the game logic itself, the tile list is much larger than what's actually available in the editor. There are significant gaps - sometimes hundreds of values - between different "types" of tiles. For instance, there's a gap between the "floor" appearance tiles (including the invisible wall) and the "wall" appearance tiles (including the fake wall). These gaps have unusual behaviour - more often than not, they visually appear as an empty "pit" tile, and behave like the previous "type" of tile in the list. In other words, the values between floors and walls will appear as pit tiles, but can be walked on like regular floor tiles.
There are two nonstandard tiles in the test level file that prevent it from being loaded in the editor. One of them is the asterisk noted above in the level layout, the other is the tile to its immediate right. I believe that these two tiles in unison are what create the unusual behaviour.
Short version: The level doesn't load in the editor because it's been modified in an external program, in order to replace two tiles in the level with abnormal tiles that cannot be used under standard circumstances. These tiles are the only unusual thing about the level file, so they are what allow the trick to happen.
---
Nonstandard tiles, huh? The curious thing here - what are the tiles in question?
I'll begin by explaining the rightmost tile, as it's the most straightforward one - simply put, the tile to the immediate right of the asterisk appears as empty space, but behaves like water. I will admit I haven't tested this specific tile value to see how it behaves, but the value is in the gap between water and ice tiles, which leads me to conclude it's water.
The asterisk tile is the critical one here, and the most difficult to explain. To make things easier, I'll start by assigning a name to this tile - we're going to call it 0x0838.
Why that name specifically? It's because of what I mentioned above about the level data being stored as hexadecimal. Both objects and tiles get four bytes to define themselves in (00 00 00 00). In the case of objects, this means there are three empty bytes (00's) between each object, as the only object values are 01 through 59 (again, in hex - in decimal, this is equal to 89). 00 is an empty object slot - nothing occupies this space, beyond the tile itself.
The tile array is more complicated. There are far more tiles than there are objects, and due to the gaps between tile values, the number far exceeds a single byte (FF). As a result, most tiles in the game take up two bytes. However, it's still not quite that simple.
The classic trilogy's levels are in a format known as little endian. A file can be either big or little endian. The difference between the two is the order they store bytes in. Simple explanation:
Our example byte sequence is going to be 01 02 03 04. In big endian, this is stored as 01 02 03 04, the same way as we would write it.
In little endian, however, it's stored as 04 03 02 01. Frankly, I have no idea why the different endian types exist, but that's besides the point here. The point is that the tile values in a hex editor aren't stored internally in the order they appear to be. For example, a water tile has an ID of 0x012C, or 01 2C. In a level file, this is saved as 2C 01.
The asterisk tile in the walking on walls level is saved in the file as 38 08. Accounting for endianness, its tile ID is 0x0838, hence the name.
Okay, so, enough about the etymology of this tile that never gets used. What's special about it?
I'll be quite frank here: I have no idea how this tile works. Going by the internal IDs for regular tiles, it immediately follows RTWP's link spheres:
Code: Select all
08 34 - Red Link Sphere
08 35 - Yellow Link Sphere
08 36 - Green Link Sphere
08 37 - Blue Link Sphere
08 38 - Invalid
0x0838 can be pushed around, like a box. The game tends to crash when the level is exited, and (sometimes?) crashes if the box is destroyed. Honestly, I don't know a lot about the specifics of how it behaves.
Cooldudepoke provided some code snippets (that I'll refrain from posting here) that lead me to believe that the reason for 0x0838's unpredictable behaviour is that there's no valid object creation code for it. There's no model or texture associated with it. I believe that, since there's no valid object behaviour defined either, it inherits some properties from its "parent" (the link sphere base), and some from a "default" pushable object (a wooden box).
Short version: The nonstandard tiles in the walking on walls level are an invisible water tile, and an undefined pushable object (hereafter called 0x0838 due to its internal value) that exhibits some very strange behaviours, including crashing the game.
---
So, there's all the background for this. Now, the main question (yeah, took me long enough to get to it) - Why does the walking on walls trick happen?
This is where we're entering speculation territory. I repeat: most of what follows is unproven. It is the result of reasoning based on an understanding of 0x0838's unusual properties, the walking on walls level itself, and odd phenomena observed in other Wonderland games.
To help explain a bit better, here's what the level looks like with 0x0838 replaced with a red link sphere and the water tile made visible:
Since 0x0838's "parent" object is a link sphere, it inherits some properties - specifically, the fact that link spheres (and boulders) sink in water. I believe this, coupled with 0x0838's unusual behaviour of "stealing" graphics, is what creates the walking on walls trick - or rather, illusion.
The walkable tiles in the level are in the same pattern as the walls (fake wall included) to their immediate left - a column of five tiles, with one sticking out to the right at the centre. If you were to visualize the layout by tile height (not counting the invisible walls), both would look like this:
Code: Select all
O
O
OO
O
OThe question is: Why does 0x0838 steal the entire level? To the best of my knowledge, this behaviour hasn't been observed anywhere else, so why is it the case here?
Something I think is relevant, though it's from the Adventures trilogy - it's not unheard of for the Wonderland games to require a brief moment of time to properly "initialize" things. During character creation in WA, it's not uncommon to see something flit past on-screen when changing between different hat/accessory models. The reason is because the engine has to create the model at x/y/z co-ordinates 0, 0, 0, before moving it to the player's position. Due to frame interpolation, the model is briefly drawn at a location between 0, 0, 0 and the player's position. Similarly odd visual behaviour can be observed if the game is paused on the very first frame of a level being loaded - giant Stinkers or Chompers, for instance.
In the case of the classic trilogy, I believe that there's a similar "initialization" period, though it's masked by the screen fading in from black. During this time, objects and graphics are loaded separately, but quickly get assigned to each other properly and moved into position before the player can see. However, the player can still move during this period.
However, 0x0838 is a rogue element - it doesn't create any graphics of any kind to be associated with. I believe this attribute is responsible for both the instability of 0x0838 itself, and its "graphic stealing" capabilities.
I have not verified this by monitoring the game's memory, so it could be entirely incorrect, but my theory is this: When the game starts up, the "graphics" assignment data is either entirely blank, or in a different format used for the main menu background. As a result, when a level with 0x0838 is loaded, it receives invalid data for what graphics it should use. Since there's nothing there, the game crashes.
When a level is completed or exited, its graphics assignment data is not cleared - it's left over in the game's memory. In most cases, on loading a new level, it's simply overwritten before anything untoward can be observed. However, if the next level to be loaded is 0x0838, part of this data is not overwritten - instead, 0x0838 will use the leftover data to determine what graphics it should use. While I haven't tested this, it means that in theory, loading a specific level before a 0x0838 level should result in the same graphics being used for 0x0838 each time.
Two other assumptions:
1. Depending on the sequence of objects in the level, 0x0838 may either permanently steal an object's graphics, or steal them temporarily before the source object catches up and steals them back. As a result, 0x0838 is sometimes rendered invisible, as opposed to having any visuals associated with it.
2. The main level graphics are, presumably, among the last sets of graphics to be assigned.
Putting all of this together, when the walking on walls trick works successfully, the sequence of events is as follows:
- The level loads. All the graphics (Stinky, the level, and the background) are loaded, but not yet assigned.
Because of the leftover assignment data, 0x0838 takes the level's graphics as its own. This is why the trick is so hit-and-miss - only some leftover data will make 0x0838 take the level's graphics successfully.
The player holds right during this brief period. 0x0838 moves right one tile and sinks to the bottom of the invisible water pit.
There are two possibilities here, depending on how the graphics assignment actually works. One - The game properly reassigns the level's graphics, but they remain offset from where they should be. This creates the illusion of Stinky walking on walls. Two - The game fails to reassign the level's graphics, meaning they're still "parented" to 0x0838. The level logic stays intact and the graphics stay offset, but the level doesn't have any graphics connected to it. For all intents and purposes, assuming the trick is done correctly and 0x0838 takes ownership of the level's graphics, the end result is the same - Stinky appears to be standing on top of the walls.
Short version: The walking on walls trick is an "illusion" - 0x0838, due to being undefined, effectively "steals" the level's graphics. When pushed to the right, it sinks into an invisible water pit, moving right by one tile and down by two. This displaces the level's graphics - but NOT its logic - so that Stinky appears to be standing on top of the wall.
---
Phew, that was a long post. NO REGRETS
No, but seriously. Maybe I'm the only one, but I thought this would be interesting to post. Whether or not this is what actually happens when the trick succeeds... Who knows? I'm sure it's possible to verify it somehow, but I'm not capable of that right now. More to the point, though, who'd want to completely take the mystery out of it?
(If you actually read all of this, I'm impressed)
