User:B squo

Discord → B_squo#5127

Details on my old_mario_gc_hayasi restoration attempt

Download

Models

old_mario_gc_hayasi has two models:

course_model.brres

The course's model.

MDL0

Its MDL0 (model format) is in version 8 (the final game only supports version 11), so attempting to load this model will crash the game.

For this restoration, I used BrawlBox v0.71 to convert the model to version 11, and so far, the resultant model looks identical to the original Double Dash!! version of the model (which also happens with old_mario_gc_b, and the rest of the unused versions of GCN Mario Circuit). You can tell by looking to the little bumps where the Goombas are, which look identical to how they did in Double Dash!! (in MKWii, the bumps have been raised up a little).

TEX0

The textures, while identical looking to the ones in the final, are stored in TEX0 version 1 format (the final game is meant to used TEX0 version 3 format). However, because v1 and v3 formats both have the same structure, the final game can actually load them just fine! So in this case, I didn't need to do any conversion/editing at all to make it work.

STR0

The texture animation is stored in the format SRT0 v4 (the final game only supports v5). For this I actually imported the SRT0 file from the old_mario_gc_b version instead of changing the version using BrawlBox v0.71. This is because I originally did change the format with BrawlBox v0.71, but I then compared the resultant SRT0 with the one from old_mario_gc_b and I realised the were ALMOST identical, except for a few bytes that, following the SRT0 format page, I did not think they affected the actual texture animation data itself. In both cases, the water animation works, but does not loop properly.

SCN0

Much like old_mario_gc_b, this version also features a SCN0 (scene settings) file in version 4 (the final game only supports version 5). This file controls things like ambient light, fog settings, etc.

As far as I'm aware, SCN0 files are used for showing live rendered videos and are not found in any used course at all (again, as far as I know), in fact, things like the lights or the fog settings are actually controlled by other type of files unrelated to SCN0 files, so it's not that important. Nonetheless, I still added it to the restoration as well (in this case I also imported the one from old_mario_gc_b given the similarities).

According to BrawlBox v0.71, the SCN0 file contains the following

• One light whose starting position is XYZ = (4, 4, 4), with a Specular Shine of 16 (every other entry = 0). Both light and specular colors are equal to RGBA = (255, 255, 255, 255) (completely white).
• An ambient light whose color is equal to RGBA = (255, 255, 255, 0) (completely white).
• A camera with position XYZ = (0, 10, 20), Fov Y = 30, Aspect = 1,777777, Near Z = 1 and Far Z = 1000000 (every other entry = 0).

vrconr_model.brres

The skybox model.

MDL0

This MDL0 (model format) is also in version 8, so it was converted to version 11 using BrawlBox v0.71.

TEX0

Much like with the course model, its only texture is also stored in TEX0 version 1 format. And again, I left it as it was from the original unused course file, since the final game can load it just fine.

map_model.brres

While the unused version does not feature a minimap model, I had to add one to the restoration, since the game crashes if it's not present. I just added an empty model and moved its positional bones far away (-99999, 0, -99999), so that the character icons don't appear in the screen.

Collision (course.kcl)

The collision from the unused file can be loaded in the final game just fine, so I just added it to the restoration as is.

The collision itself is very similar to the one found in old_mario_gc_b at first glance (main type of road assigned to every single road texture, main type of wall assigned to all of the wall texture kinds, no shadowing when passing under shadows, tricks cannot be done, etc). However, there is actually something that is unique to this and one of the other unused GCN Mario Circuit versions: there are two tree trunks standing in the area with the wide curve in the grass shortcut! This is not in the final game nor in old_mario_gc_b, as the trees (and their collision) are added as separate objects.

Parameters (course.kmp)

The course.kmp is in an older version of the format (0x0640) in which some sections have a different layout, meaning it won't work in the final game. I studied this file, assuming the final version's KMP format to figure out what was still in the file and also what's wrong with it. This has a summary of the technical differences between this and the final version of the format.

KTPT (Starting point)

As you saw in the video, the starting point is placed a bit forward than in the final game.

When it comes to the section in the KMP, it lacks the section header that is common to all sections of the file, which tells things like the number of entries the section is using. The section data starts right after the magic, but otherwise it seems to follow the same structure as the final version.

ENPT (CPU points)

- Number of CPU points = 34 (0x22)

These are the invisible points the CPU follow in order to navigate around the course. In comparison to the final, old_mario_gc_hayasi has less points, but nonetheless follows the course correctly.

The section data in this version only contains position data (3 single-precision floats), and lacks the additional float, uint16 and two bytes that dictates the width in which the CPU can navigate and a few settings such as when should the CPUs use a mushroom, do a wheeliee, etc.

Because these missing bytes are not present in the unused version, I decided to make them 0 (like a default case). This explains why, for example, the CPUs seem to be in a strict line the whole time instead of moving left/right sometimes.

ENPH (CPU points group info)

This section is missing from the unused file. Because of this, the CPUs shouldn't even actually move at all.

However, I've decided to add an entry to the restoration to create a group containing all the CPU points and linking itself as the "previous" and "next" group so that you can see the CPUs following the already-predefined CPU points. Again, remember that this is technically custom, and CPUs should not actually move. If you want to truly make the restoration's KMP accurate, you can always "remove" this section by opening the course.kmp file and then changing the byte at offset 0x325 from 01 to 00, which will make the game think this section is empty.

CKPT (checkpoints)

This section seems to be in the same format as the final one, so I just copy/pasted the data from the unused version as is.

CKPH (checkpoint groups)

This section seems to be in the same format as the final one, so I just copy/pasted the data from the unused version as is. There is only one checkpoint group that contains all of the checkpoints.

GOBJ (objects)

This section is empty.

POTI (object/camera routes)

This section is empty.

AREA

- Number of AREAs = 7

From what I know, this is the only unused GCN Mario Circuit version with AREAs defined, all of which act as camera activators. They're all located from the beginning of the first curve until around the curve before the tunnel.

The section layout is almost the same as the final version, except that it is 4 bytes shorter. In the restoration, these missing bytes were added as 0.

CAME (cameras)

- Number of cameras = 8 (7 FixSearch + 1 Goal)

Much like with the AREAs, this is the only unused GCN Mario Circuit version with cameras defined. The cameras are placed in more or less the same places as with the AREAs.

The Goal camera is closer to the character than in the final version, and it does not zoom in slightly when it is activated.

While the unused file defines the intro camera to be the first one, that one is not the type of camera that is meant to be used in that sequence (with the type being OP_FixMoveAt and/or OP_PathMoveAt). Not only that but because this camera can only be activated by passing through its associated AREA, it does not actually show up in the intro. Instead, the camera just focuses on your character, similarly to what happens when there're no cameras defined (however in this case, the camera actually stays in place, probably because the camera does exist). To sum up, no, the developers did not actually add opening cameras to the file.

The section layout is almost the same as the final version, except that it is 4 bytes shorter. In the restoration, these missing bytes were added as 0.

Other sections

Every other section is missing from the unused file. In the restoration, they've been added, but are empty.

The only exception (aside of the ENPH section from before) is the STGI section, since the game crashes if it's not present in the file. For this case, I made all the section data bytes 0 EXCEPT for the number of laps (3). This is because, if I make this byte 0, Lakitu won't appear when driving backwards.

Be careful because if you fall out of bounds (or if a CPU gets stuck for a while) the game will crash because of the lack of respawn points.

Details on my old_mario_gc_yabuki restoration attempt

Download

Models (MDL0)

Much like old_mario_gc_hayasi, this version also has two models: the course's model (course_model.brres) and the skybox's model (vrcorn_model.brres), both of them are in the same older formats as with old_mario_gc_hayasi. Because of this, I followed the same process to convert these resources as with old_mario_gc_hayasi.

As far as the differences goes, they are both identical looking, the only exception is that none of the old_mario_gc_yabuki models (MDL0) have normals. This does not seem to change its appearence, however.

TEX0

The textures, while identical looking to the ones in the final, are stored in TEX0 version 1 format (the final game is meant to used TEX0 version 3 format). However, because v1 and v3 formats both have the same structure, the final game can actually load them just fine! So in this case, I didn't need to do any conversion/editing at all to make it work.

STR0

The texture animation is stored in the format SRT0 v4 (the final game only supports v5). For this I actually imported the SRT0 file from the old_mario_gc_b version instead of changing the version using BrawlBox v0.71. This is because I originally did change the format with BrawlBox v0.71, but I then compared the resultant SRT0 with the one from old_mario_gc_b and I realised the were ALMOST identical, except for a few bytes that, following the SRT0 format page, I did not think they affected the actual texture animation data itself. In both cases, the water animation works, but does not loop properly.

SCN0

Much like old_mario_gc_b, this version also features a SCN0 (scene settings) file in version 4 (the final game only supports version 5). This file controls things like ambient light, fog settings, etc.

As far as I'm aware, SCN0 files are used for showing live rendered videos and are not found in any used course at all (again, as far as I know), in fact, things like the lights or the fog settings are actually controlled by other type of files unrelated to SCN0 files, so it's not that important. Nonetheless, I still added it to the restoration as well (in this case I also imported the one from old_mario_gc_b given the similarities).

According to BrawlBox v0.71, the SCN0 file contains the following

• One light whose starting position is XYZ = (4, 4, 4), with a Specular Shine of 16 (every other entry = 0). Both light and specular colors are equal to RGBA = (255, 255, 255, 255) (completely white).
• An ambient light whose color is equal to RGBA = (255, 255, 255, 0) (completely white).
• A camera with position XYZ = (0, 10, 20), Fov Y = 30, Aspect = 1,777777, Near Z = 1 and Far Z = 1000000 (every other entry = 0).

map_model.brres

While the unused version does not feature a minimap model, I had to add one to the restoration, since the game crashes if it's not present. I just added an empty model and moved its positional bones far away (-99999, 0, -99999), so that the character icons don't appear in the screen.

Collision (course.kcl)

The collision from the unused file can be loaded in the final game just fine, so I just added it to the restoration as is.

The collision itself seems identical to the one used in old_mario_gc_hayasi (although both files are technically different, i.e. not byte-to-byte identical).

Parameters (course.kmp)

The course.kmp is in an older version of the format (0x0640) (much like with old_mario_gc_hayasi) in which some sections have a different layout, meaning it won't work in the final game. I studied this file, assuming the final version's KMP format to figure out what was still in the file and also what's wrong with it. This has a summary of the technical differences between this and the final version of the format.

KTPT (Starting point)

The point has the exact same coordinates as with old_mario_gc_hayasi, except that it is rotated backwards 180 units (Y Rotation = 0x43340000).

Something curious about this is that, if you play in a kart, you will bounce when starting the race (this does not happen when playing in a bike). No idea why this happens.

ENPT (CPU points)

- Number of CPU points = 55 (0x37)

These are the invisible points the CPU follow in order to navigate around the course. In comparison to the final version, old_mario_gc_yabuki has around the same number of points, following the course correctly... except backwards.

The section data in this version only contains position data (3 single-precision floats), and lacks the additional float, uint16 and two bytes that dictates the width in which the CPU can navigate and a few settings such as when should the CPUs use a mushroom, do a wheeliee, etc.

Because these missing bytes are not present in the unused version, I decided to make them 0 (like a default case). This explains why, for example, the CPUs seem to be in a strict line the whole time instead of moving left/right sometimes.

ENPH (CPU points group info)

This section is missing from the unused file. Because of this, the CPUs shouldn't even actually move at all.

However, I've decided to add an entry to the restoration to create a group containing all the CPU points and linking itself as the "previous" and "next" group so that you can see the CPUs following the already-predefined CPU points. Again, remember that this is technically custom, and CPUs should not actually move. If you want to truly make the restoration's KMP accurate, you can always "remove" this section by opening the course.kmp file and then changing the byte at offset 0x4C9 from 01 to 00, which will make the game think this section is empty.

CKPT (checkpoints)

This section seems to be in the same format as the final one, so I just copy/pasted the data from the unused version as is. Much like with the CPU points, the checkpoints are indexed following the course backwards.

CKPH (checkpoint groups)

This section seems to be in the same format as the final one, so I just copy/pasted the data from the unused version as is. There is only one checkpoint group that contains all of the checkpoints.

GOBJ (objects)

This section is empty.

POTI (object/camera routes)

This section is empty.

AREA

This section is empty.

CAME (cameras)

This section is empty.

Other sections

Every other section is missing from the unused file. In the restoration, they've been added, but are empty.

The only exception (aside of the ENPH section from before) is the STGI section, since the game crashes if it's not present in the file. For this case, I made all the section data bytes 0 EXCEPT for the number of laps (3). This is because, if I make this byte 0, Lakitu won't appear when driving backwards.

Be careful because if you fall out of bounds (or if a CPU gets stuck for a while) the game will crash because of the lack of respawn points.

So... why do you drive backwards in this version???

As you have seen, the quirk about this version is that, for some reason, it is driven backwards! Not only the CPU points and checkpoints are indexed following the course backwards, but the starting point is rotated backwards as well. So... what's going on?

Now beforehand: yes, the data IS correct. This is not an inaccuracy of the restoration or something like that. I've checked the KMP file throughly and this is indeed how the data is stored in the file. For those who don't know, the way the game determines the indexes of the CPU points and checkpoints quadrilaterals (assuming they belong to the same group, and in this case, checkpoints are grouped in a single group) is simply by checking the order in which each entry is defined. For example, in the case of the CPU points (assuming they belong to the same group), the first point defined in the file (after the section header) is the point with index 0, the one that comes after it, index 1, the next one, index 2, and so on. In the case of old_mario_gc_yabuki, the 2nd point defined is positioned before the start line, the 3rd one, right before it (in the jump), and so on, following the course in reverse.

So now that we have discarded any issues with the KMP itself, these are my theories on why this happens:

• The course was originally rotated backwards: When comparing the early versions of GCN Mario Circuit with the final version, they are rotated 180 degrees. Which might explain the reason why the starting point is backwards for example. However, this is unlikely in my opinion, because if you rotate the whole course, sure, the rotation will match, but the position will be completely different. Not only that, but both the CPU points and checkpoints follow the course as it is stored in the file, and not rotated (which would misposition all of those entries out of bounds).

• The code for parsing KMP files worked differently at the time. The point entries were indexed in reverse: It is true that the code of the game might have been different at the time, and so the order of the points might have been determined from the last to the first entry. Now all we can do really is speculate on this one, since we have don't have any evidence on this. One argument to go against it is how old_mario_gc_yabuki 's KMP version is the exact same one as the one from old_mario_gc_hayasi (0x0640). If both KMP files have the same version, that could mean that the code that parsed both files had to be the same. If that was the case, then this would be pretty much debunked considering that old_mario_gc_hayasi has the points following the course in the correct order.

• It was a developer oversight: Discarding any issue with the KMP or how the code worked when this version was made, all there is left to speculate is that this was an oversight from the developer. Maybe they weren't told about the correct orientation of the course?

• • Sadly, this is very speculative, but I do have something interesting to say here. Remember how I said that the point coordinates were the exact same as the ones from old_mario_gc_hayasi? Maybe old_mario_gc_hayasi originally took old_mario_gc_yabuki as a base, and then (among other things) corrected the starting point orientation.

• • Another thing is how the lap counter checkpoint is placed before the finish line. Because of this, the lap can only count if the course is driven backwards. In order to be able to drive forwards and make the lap count, this lap counter checkpoint has to be put in front of the line.

Details on my old_mario_gc_narita restoration attempt

Download

BRRES (models, textures, texture animation and scene settings)

Both *.brres files are byte-to-byte identical to the ones from old_mario_gc_yabuki, so I just copied those files from that restoration into this one.

map_model.brres

While the unused version does not feature a minimap model, I had to add one to the restoration, since the game crashes if it's not present. I just added an empty model and moved its positional bones far away (-99999, 0, -99999), so that the character icons don't appear in the screen.

Collision (course.kcl)

The collision from the unused file can be loaded in the final game just fine, so I just added it to the restoration as is.

The collision file itself is identical to the one from old_mario_gc_hayasi.

Parameters (course.kmp)

The course.kmp is in an older version of the format, in which some sections have a different layout, meaning it won't work in the final game. However, unlike with old_mario_gc_hayasi and old_mario_gc_yabuki, the exact version number is unknown, as that field is missing from the file. Though it is possible that the version in this file is earlier than the ones from the aforementioned courses, given how it only has 6 sections defined, instead of 8.

I studied this file, assuming the final version's KMP format to figure out what was still in the file and also what's wrong with it. This has a summary of the technical differences between this and the final version of the format.

KTPT (Starting point)

The position is almost the same one as in the final version, except it is rotated backwards 180 units (Y Rotation = 0x43340000).

ENPT (CPU points)

- Number of CPU points = 32 (0x20)

These are the invisible points the CPU follow in order to navigate around the course. In comparison to the final version, old_mario_gc_narita has less points, following the course correctly... except backwards.

The section data in this version only contains position data (3 single-precision floats), and lacks the additional float, uint16 and two bytes that dictates the width in which the CPU can navigate and a few settings such as when should the CPUs use a mushroom, do a wheeliee, etc.

Because these missing bytes are not present in the unused version, I decided to make them 0 (like a default case). This explains why, for example, the CPUs seem to be in a strict line the whole time instead of moving left/right sometimes.

ENPH (CPU points group info)

This section is missing from the unused file. Because of this, the CPUs shouldn't even actually move at all.

However, I've decided to add an entry to the restoration to create a group containing all the CPU points and linking itself as the "previous" and "next" group so that you can see the CPUs following the already-predefined CPU points. Again, remember that this is technically custom, and CPUs should not actually move. If you want to truly make the restoration's KMP accurate, you can always "remove" this section by opening the course.kmp file and then changing the byte at offset 0x2FD from 01 to 00, which will make the game think this section is empty.

CKPT (checkpoints)

This section seems to be in the same format as the final one, so I just copy/pasted the data from the unused version as is. Much like with the CPU points, the checkpoints are indexed following the course backwards.

CKPH (checkpoint groups)

This section seems to be in the same format as the final one, so I just copy/pasted the data from the unused version as is. There is only one checkpoint group that contains all of the checkpoints.

GOBJ (objects)

This section is empty.

POTI (object/camera routes)

This section is empty.

AREA

This section is empty.

CAME (cameras)

This section is empty.

Other sections

Every other section is missing from the unused file. In the restoration, they've been added, but are empty.

The only exception (aside of the ENPH section from before) is the STGI section, since the game crashes if it's not present in the file. For this case, I made all the section data bytes 0 EXCEPT for the number of laps (3). This is because, if I make this byte 0, Lakitu won't appear when driving backwards.

Be careful because if you fall out of bounds (or if a CPU gets stuck for a while) the game will crash because of the lack of respawn points.

So... why do you drive backwards in this version???

As you have seen, the quirk about this version is that, for some reason, it is driven backwards! Not only the CPU points and checkpoints are indexed following the course backwards, but the starting point is rotated backwards as well. So... what's going on?

Now beforehand: yes, the data IS correct. This is not an inaccuracy of the restoration or something like that. I've checked the KMP file throughly and this is indeed how the data is stored in the file. For those who don't know, the way the game determines the indexes of the CPU points and checkpoints quadrilaterals (assuming they belong to the same group, and in this case, checkpoints are grouped in a single group) is simply by checking the order in which each entry is defined. For example, in the case of the CPU points (assuming they belong to the same group), the first point defined in the file (after the section header) is the point with index 0, the one that comes after it, index 1, the next one, index 2, and so on. In the case of old_mario_gc_narita, the first point defined is positioned before the start line, the second one, right before it (in the jump), and so on, following the course in reverse.

So now that we have discarded any issues with the KMP itself, these are my theories on why this happens:

• The course was originally rotated backwards: When comparing the early versions of GCN Mario Circuit with the final version, they are rotated 180 degrees. Which might explain the reason why the starting point is backwards for example. However, this is unlikely in my opinion, because if you rotate the whole course, sure, the rotation will match, but the position will be completely different. Not only that, but both the CPU points and checkpoints follow the course as it is stored in the file, and not rotated (which would misposition all of those entries out of bounds).

• The code for parsing KMP files worked differently at the time. The point entries were indexed in reverse: It is true that the code of the game might have been different at the time, and so the order of the points might have been determined from the last to the first entry. Now all we can do really is speculate on this one, since we don't have any evidence on this.

• It was a developer oversight: Discarding any issue with the KMP or how the code worked when this version was made, all there is left to speculate is that this was an oversight from the developer. Maybe they weren't told about the correct orientation of the course?

• • One fact to support this is how the lap counter checkpoint is placed before the finish line. Because of this, the lap can only count if the course is driven backwards. In order to be able to drive forwards and make the lap count, this lap counter checkpoint has to be put in front of the line.

Differences between old_mario_gc_hayasi and yabuki's (0x0640) and the final (0x09D8) KMP versions

KMP (Parameters) format

General

The older version only defines 8 sections: KTPT, ENPT, CKPT, CKPH, GOBJ, POTI, AREA and CAME. The final version in the other hand, has the following additional sections: ENPH, ITPT, ITPH, JGPT, CNPT, MSPT and STGI; adding up to a total of 15 sections.

KTPT (Starting point)

The section header that is common in all sections is missing in this section. The section data starts inmediately after the magic. This likely indicates that at this point of time multiple starting positions (used in Battle mode for example) were not implemented.

ENPT (CPU points)

Each entry only has position data for the X, Y and Z coordinates (3 single-precision floats).

AREA (activators) and CAME (cameras)

In the older format, both sections are 4 bytes shorter.

• In the case of the AREA section, the AREA setting 2, Route ID and Enemy point (ENPT) ID fields are not implemented.
• In the case of the CAME section, the field that indicates the time that a camera has been active is not present.

Differences between old_mario_gc_narita (unknown version) and the final (0x09D8) KMP versions

KMP (Parameters) format

General

• The older version only defines 6 sections: KTPT, ENPT, CKPT, CKPH, GOBJ and POTI. The final version in the other hand, has the following additional sections: ENPH, ITPT, ITPH, AREA, CAME, JGPT, CNPT, MSPT and STGI; adding up to a total of 15 sections.

• The older version lacks the "version number" field, so we can't tell which version this is exactly.
  It is possible that this version of the format is earlier than the ones from old_mario_gc_hayasi and yabuki though, given how its format is pretty similar, but defines less sections, and is lacking this "version number" field (unlike with all other versions of the format found in the game).

KTPT (Starting point)

Much like with old_mario_gc_hayasi and yabuki, the section header that is common in all sections is missing in this section. The section data starts inmediately after the magic. This likely indicates that at this point of time multiple starting positions (used in Battle mode for example) were not implemented.

ENPT (CPU points)

Much like with old_mario_gc_hayasi and yabuki, each entry only has position data for the X, Y and Z coordinates (3 single-precision floats).

About Mario Kart Wii's Special Ghosts

For those who don't know, Special Ghosts (スペシャルゴースト in Japanese) were a feature in which Nintendo would deliver ghosts themselves through WiiConnect24. It is mentioned in some of the game's text, and the Mario Kart Channel also has some icon files stored for it. TCRF.net article.

For a long time, many of us believed it was an unused feature, since there is barely any mention at all of them (in English) on the internet. However, as it turns out, they actually existed!

Historical context

On April 16th, 2008 (roughly a week after the game came out in Japan) a ghost of Japanese actor and comedian Medaka Ikeno (池乃めだか) was delivered (exclusively?) to Japanese Wiis, alongside a letter to the Wii Message Board. He appeared in several Mario Kart Wii Japanese commercials, such as this one.

This was promoted by Nintendo in their official Wii website, together with a video (sadly, I wasn't able to watch said video, as it is a Flash video). Apparently, Ikeno-san was asked to record this ghost in the dressing room where they recorded the TV commercials.

The ghost

As mentioned by several websites from back in the day, the ghost metadata is the following:

• Course: Luigi Circuit (ルイージサーキット in Japanese)
• Time: 01:36.157
• Mii Name: ★めだか
• Country: Japan
• Character: Small Mii (Male Outfit A?, see the videos below)
• Vehicle: Quacker
• Controller: Wii Wheel
• Drift Type: Very likely Automatic (see the videos below)

The Mii used in this ghost also appears in one of the Japanese commercials.

This article contains images of the letter sent to Wiis alongisde the ghost, as well as the Mii used and the record as seen in the Rankings menu. A few more images can be found here, which shows the Time Trial card for this ghost (direct link to the image). This website shows a little bit more of the ghost's letter (direct link to the image).

So far, I was able to find two videos showcasing the ghost: this one and this one.

Other

• Special Ghosts might have also been delivered to Korean Wiis, since one of the official Korean trailers shows the special ghost icon.
• Special Ghosts seem to have unique sound effects for the bubbles that appear for them in the Rankings menu (labeled SE_UI_RANK_ENTER_FAMOUS and SE_UI_RANK_BTN_IN_FAMOUS respectively). The "FAMOUS" string implies that special ghosts were indeed meant to be celebrities' ghosts.

Conclusions

While the ghost mentioned is the only one confirmed to exist, there is the possibility that more special ghosts (presumably from other actors that appeared in the Japanese commercials, such as the ones listed here) could have been delivered.

If you know anything more about Special Ghosts (or have received this, or even, another special ghost back in the day), feel free to message me on Discord! (at the top of the page)

loser_demo (Losing version of Mario Circuit) vs. castle_course (Final Mario Circuit)

To do: Investigate the multiplayer version.

loser_demo.szs (the version of Mario Circuit that gets loaded when losing a Grand Prix/VS Race/Battle) is very interesting because it represents an earlier version of the course! This is almost imperceptible in gameplay, but looking further at the course data reveals quite a few elements that were seen in the E3/Fall 2007 Press Conference versions of the course that are missing or were changed in the final version. This section will discuss the differences found between loser_demo and the final (single player) version of Mario Circuit.

NOTE:

• Keep in mind that, while similar, loser_demo is not 100% identical to the E3 version, so we can't really call it the "E3 version" itself.
• Only the elements that are found in both versions of the course will be mentioned. For example, some things, such as checkpoints, and some objects like the Chain Chomp and item boxes, are not found in loser_demo, as they cannot be seen in its associated cutscene, and thus are not really needed.
  • In the same way, if there is a resource that is found between both versions but it's not mentioned, then it is assumed that it is byte-to-byte identical between both versions. For example, most textures are the same between both versions, so this article will only contain the textures that are different.

Models

vrcorn_model.brres (Skybox model)

In the material settings, the FogIndex parameter (under the SCN0 References) is 0 in loser_demo, while -1 in the final version. This has seemingly no effect in-game, as none of the courses have a SCN0 file in the first place.

Textures

loser_demo	Final

The "M" in the flags found on top of the castle had a different design. In the final version, it was changed to the stylized "M" seen on Mario's cap.

loser_demo	Final

	loser_demo	Final
Filename	p_union_A17km.tex0	p_union_A33k.tex0

• Many of the billboards say MarioKart (stylized like the Nintendo logo) in loser_demo, all of which were changed to MARIO.
• The cloud texture is a little bit darker in the final version.
• The "?" on top of the item boxes were removed in the final version, and the colors of both boxes are very slightly less saturated as well.

loser_demo	Final

	loser_demo	Final
Filename	p_union_C45k.tex0	p_union_C51k.tex0

The colors of the finish line texture are a bit more saturated in the final version.

loser_demo	Final

	loser_demo	Final
Filename	p_unionE15.tex0	p_unionE17.tex0

The start line banner was made slightly darker in the final version. The Mario picture is also a bit different with Mario being slightly shorter in the final version.

In addition, the purple chimney hole was also made a bit more saturated in the final version.

loser_demo	Final

	loser_demo	Final
Filename	t_kabe_sita_047.tex0	t_kabe_sita_048.tex0

The semi-transparent dark outline is less scattered in the final version.

loser_demo	Final

	loser_demo	Final
Filename	t_road_i04f6k2.tex0	t_road_i04f6k3.tex0

loser_demo	Final

	loser_demo	Final
Filename	t_road_i21f6k2.tex0	t_road_i21f6k3.tex0

loser_demo	Final

	loser_demo	Final
Filename	t_road_i40f6k2.tex0	t_road_i40f6k3.tex0

The road textures were made very slightly less saturated in the final version (increase the brightness of your screen, and quickly toggle between both images to see it).

loser_demo	Final

• The shadows of a couple of the trees were made smaller and more circular in the final version.
• One of the flower's shadow in the northern part of the course was moved in the final version, since the object was also moved in comparison with loser_demo (see below).
• In addition to that, several other flower shadows that did not match the actual flower positions in loser_demo were moved (and a few of them were removed) in the final version to better match the final course layout. Interestingly, most of these are leftovers from the E3/Fall 2007 Press Conference footage, as flowers (such as the one seen in the left at the beginning of the course) can be seen in those spots from the loser_demo shadow map.

Lighting and Post-processing effects

loser_demo	Final

Outside, the bloom effect is noticeably more widespread in the final version than in loser_demo. When driving under shadows, the ambience lighting is brighter in loser_demo than in the final version. This cannot be seen in loser_demo however, as this version does not have shadowing effects.

Loser_demo also lacks the blur effect seen in the areas farther away from the camera that appears in the final version, as it lacks a posteffect.bdof file.

The exact differences between the post-effects files are presented below:

• /./posteffect/posteffect.blight (Lighting)
  • The second ambiance light defined in loser_demo has an alpha value of 0xFF, while in the final version it was changed to 0x82. The third ambient light has the RGBA value of 0x3F4C5CFF in loser_demo, while in the final version, it was changed to 0x47586A3C (a bit lighter in comparison).
  • In the same way, the second and third lights objects defined in that file in loser_demo have an alpha value of 0xFF, while in the final version, the second light's alpha value was changed to 80, and the third one, to 64. In addition, each light object entry is in version 0x01 in loser_demo, while in the final version, it is 0x02. It is unknown what the exact difference between both versions is, however.

• /./posteffect/posteffect.bblm (bloom and glow)

To do: Write the meaning of these differences once the format is figured out.

Offset	loser_demo	Final
0x0C	806F5A34	00000000
0x9C	3F000000	3F333333
0xA0	3D880000	3D75C28F

• /./posteffect/posteffect.blmap (Environment mapping controller) (exclusive to loser_demo)

To do: Write the meaning of these differences once the format is figured out. Maybe this file is the reason why, in loser_demo, the lighting when driving under the shadows looks brighter?

References the lm_0 texture (not present in the course file).

Collision (course.kcl)

loser_demo	Final

One wall was added in the final version near the end of the course at the left.

loser_demo	Final

Just like with the regular course model, in the off-road section in the right of the road near the final curve of the course, some polygons were added in the final version. In the wall in front of that, another polygon was added, and two polygons were flipped near the end of the course at the right.

In addition to these, the shadows do not give a shadowing effect in loser_demo, as they are not defined in the collision model, unlike in the final version (seen in some of the screenshots above).

Parameters (course.kmp)

Respawn Point (JGPT)

loser_demo	Final

The respawn point was moved a bit backwards and was better centered in the final version.

Objects (GOBJ)

DummyPole (Lamp post collision)

In loser_demo, the collision flag set for these objects is "regular wall" (first object setting is 0), while in the final version, it is set to "metallic wall" (first object setting is 2).

castletree1 (3D tree) and castletree2 (2D tree)

loser_demo	Final

In loser_demo, there is a 2D tree located in the center of the area with the houses in the northern part of the course. This object was seemingly replaced by a 3D tree in the final version, as the 2D tree was removed, and the 3D one is located in almost the exact same position (albeit with different rotation).

Additionally, all of the instances of both tree objects in loser_demo have their "presence value" set to 0x3F (always visible), while in the final version this value is set to 0x09 (meaning they will appear in single player modes only, so they'll be disabled in multiplayer).

castleflower1 (3D flower)

	loser_demo	Final
Fourth 3D flower's Y Position	3208.649	3208.65

The fourth 3D flower defined (the one found in the right of the starting line), has been very slightly positioned more upwards in the final version...

loser_demo	Final

...while the fourth 3D flower has a different position altogether (highlighted above in red).

Additionally, all of the instances of this object in loser_demo have their "presence value" set to 0x3F (always visible), while in the final version this value is set to 0x09 (meaning they will appear in single player modes only, so they'll be disabled in multiplayer).

Lens Colors

To do: Get comparison picture of this

	loser_demo	Final
Sun flare lighting color value (RGBA)	0xE6E6E64B	0xE6E6E632

The lighting color that covers the screen when looking at the sun is a bit more opaque in loser_demo. This can't be seen however, as loser_demo does not have the object for said effect defined.

Model and Texture Animations

vrcorn_model.brres/vrcorn.srt0 (Skybox's texture animation)

	loser_demo	Final
Skybox texture animation's frame count	1500	2249

The skybox texture rotates faster in loser_demo than in the final version, as its animation has less frames.

castleflower1.brres/castleflower1.chr0 (3D flower's animation)

Some of the keyframes have very slightly different rotation and positioning (for example, in loser_demo, frame 98 of the Hm_body45 bone (which rotates the stem) has the X rotation set to -4.434772, while in the final version, it is -4.544624). This change is pretty much unnoticeable to the naked eye, however.

castletree1.brres/castletree1.chr0 (3D tree's animation)

	loser_demo	Final
Frame 18's Z rotation	-2.734277	-2.753552

In the final version, the Z rotation of frame 18 was made very slightly more rotated towards the right. This change is pretty much unnoticeable to the naked eye, however.

castletree2.brres/castletree2.chr0 (2D tree's animation)

Some of the keyframes have very slightly different rotation and positioning (for example, in loser_demo, frame 18 has the Z rotation set to -2.734277, while in the final version, it is -2.753552). This change is pretty much unnoticeable to the naked eye, however.