Mario Kart Wii/Unused Courses

This is a sub-page of Mario Kart Wii.

There are a total of 12 unused course files, all present in the /Race/Course directory.

General

Filename	Description	Notes	Identical to its respective single-player version?
old_mario_gc_b	Unused version of GCN Mario Circuit.		-
old_mario_gc_b_d	Multiplayer version of old_mario_gc_b.		✔
old_mario_gc_hayasi	Unused version of GCN Mario Circuit.		-
old_mario_gc_narita	Unused version of GCN Mario Circuit.		-
old_mario_gc_yabuki	Unused version of GCN Mario Circuit.		-
course.0	Early version of Bowser's Castle collision and parameters.	Found within the archives of Bowser's Castle (koopa_course*.szs).	-
draw_demo	Unused version of Mario Circuit.		-
draw_demo_d	Multiplayer version of draw_demo.		✘
winningrun_demo_d	Multiplayer version of the award ceremony version of Mario Circuit.	Only the single-player version is used, even when playing in multiplayer.	✘
loser_demo_d	Multiplayer version of the losing sequence version of Mario Circuit.	Only the single-player version is used, even when playing in multiplayer.	✘
ending_demo_d	Multiplayer version of the ending version of Luigi Circuit.	It is impossible to access this version of the course in multiplayer, since Grand Prix is a single-player mode.	✔
ring_mission_d	Multiplayer version of the Galaxy Colosseum tournament stage.	It is impossible to access this version of the course in multiplayer, since competitions/tournaments were single-player only.	✔

old_mario_gc_b

This course is almost identical to GCN Mario Circuit, but with some small differences. This may in fact be a direct port of the data from Mario Kart: Double Dash!!, indicated by the model similarities, as well as the behaviour of a few objects in comparison to the final version of the course.

General

• This track does not have a course ID defined, so it cannot be loaded with code. The only way to load it is by swapping its SZS file with another course.
• The course is rotated 180 degrees in comparison with the final version. This was likely done to orient the minimap in the same way as in Double Dash!!, since it would look upside down if the rotation from this version was kept, as seen in this mockup.

Models

Course

Overview
old_mario_gc_b	Final
Wireframe
old_mario_gc_b	Final
Vertex Colors
old_mario_gc_b	Final

The model is identical to the original version from Double Dash!!, as indicated by the following differences:

• The second curve was originally a bit narrower.
• The little humps near the Goombas are the same shape as in the Double Dash!! version.
• Some of the tree shadows are a bit darker in the early version, matching the look from Double Dash!!
• The early version had different vertex shading in some places, such as the exit of the tunnel, the left side of the last stretch with the Piranha Plants, and the stems of the mushrooms.
• The early version does not have normals, which makes it look more blocky when viewing it in a model viewer. This can't be seen in-game, however, as vertex colors are used to give the shading instead.
• The decorative mushrooms and pipes seen in the background were more polygoned in the early version.
• The final version added many more polygons in some places, most of which were made to match the collision model properly, to account the addition of shadows.
• The texture animation for the water does not loop properly, and is missing the distortion effect. Said texture is moved towards the east of the course, instead of the south (just like in the original version from Double Dash!!).

old_mario_gc_b	Final

• Two textures were also changed. The castle's roof now uses the same texture as the one seen in DS Peach Gardens (albeit slightly darker), and the stars seen in the tunnel's walls were made brighter in the final version.

Minimap

old_mario_gc_b	Final

The map model inside the course's file is the same one seen in Mario Circuit from the Flower Cup, with a slight difference in the vertex shading in the tunnel part, being slightly brighter in the final version.
This model can't be seen normally in gameplay (see below).

Skybox

The skybox does not rotate in this version, as it doesn't have a texture animation.

Lighting and Environmental Settings

This version does not have post-processing effects, such as bloom, and the lighting is also noticeably darker. This is all because the files that handle this kind of effects (usually found in /./posteffect in the course's archive) are missing in the early version, so the game loads a default lighting setup from /Race/Common.szs instead, which results in the lighting looking noticeably darker.

This is one of the few courses from the game that has an SCN0 file, which is used in many Wii games to control scene settings, such as lighting, fog, etc. This file type, however, is not used in the final game at all, since this kind of settings are loaded from the posteffect directory mentioned above. The SCN0 in this course contains the following data:

• 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).

This might just be a default SCN0 file however, considering the data from here is the same as the one found in other leftover SCN0 files from the game (such as the one from Mushroom Gorge).

Collision

old_mario_gc_b	Final

In general, many of the changes in the collision model were made to match the geometry of the visual model, such as increased polygon count in the final version. The collision-specific changes include:

• When driving on grass, the game acts like the player is driving on dirt. In the same way, every wall is set to the "regular wall" collision effect (even for rocky and wooden walls), and every road is set to "asphalt" (even the dirt road). Given how each of the collision effects in the early version are indexed as 0x00 for each type, they might just be default collision effects.
• The humps and the bridge are not trickable.
• The road collision seems to be slightly bouncier in general, likely due to this version being less polygoned overall. This is mostly notable in curves with variant heights.
• Shadows don't give off a "shading" effect to anything that passes under them.
• One of the border road polygons at the right of the beginning of the course (right before it starts curving to the left) has been mistakenly assigned as off-road.
• Many of the invisible walls were originally lower in the early version.
• Several out of bounds item walls (those that only items can interact with) are missing in the early version, such as the one on the right of the finish line or the walls (and floors) seen in the section with the Goombas.
• The sound echo effect is missing when inside the tunnel.

Parameters

Starting Position (KTPT)

The starting position is located more backwards than in the final version, and it is also slightly more shifted to the left.

CPU Points (ENPT and ENPH)

old_mario_gc_b	Final

This version has 45 CPU points defined, 13 less than in the final version, with the positioning changing a little bit in some sections, such as in the second curve, or inside the tunnel.
In the final game, these points are subdivided in 5 groups, and CPUs are also forced to do a wheelie in the first section after the starting line and also after the tunnel. The early version only has one single group, and CPUs aren't forced to do any action at all.

Notably, the final point (located before the finish line) is not connected to the first one. This will make the game crash when a CPU player is about to complete a lap, as they don't know where to go next. It is possible to fix this by changing the bytes at offsets 0x406 and 0x40C in the course.kmp file from 0xFF to 0x00.

Checkpoints (CKPT and CKPH)

The checkpoint data is almost the exact same as in the final version, with the only difference being some very slight positioning differences in some of them, which aren't apparent in normal gameplay.

Objects (GOBJ)

old_mario_gc_b	Final

This version has 37 instances for a total of 5 different object types. In the final game, there are 60 instances of 10 different object types.

• Goombas
  • The first and second Goombas are faster in this version (with the speed being 60, instead of 40), while the third Goomba is a bit slower (30 instead of 40). Because of this, their animation speeds also differ, with the first and second Goomba being slightly faster (125 instead of 120), and the third one a bit slower (110 instead of 120). This is the same behaviour that was seen in the original version from Double Dash!!

• Piranha Plants
  • These are a bit smaller than in the final version (1 instead of 1.3 scale units).
  • In this version, the Piranha Plants won't attack the player in Time Trial or online mode, as their idle time between 2 attacks is set to 0. This is the same behaviour that was seen in the original version from Double Dash!!
  • Notably, the Piranha Plants don't have pipes. The reason for this is because none of those objects (pakkun_dokan) are defined in the parameters. It is likely that the model for the Piranha Plants originally included the pipe alongside it (instead of being separated in two separate model files). A piece of evidence to support this is how an early version of the Piranha Plant model file includes both the plant and the pipe.

• Air Balloon
  • In this version, it moves a bit faster (15 instead of 10)
  • In addition, the balloon does not move up and down while floating, as the parameter that controls the maximum floating height is 0, instead of 1000 like in the final version.

• Solid Trees (found in the section with the Chain Chomp)
  • The tree that is located the nearest to the road is positioned a bit differently, as a result of the grass section being slightly moved between versions.
  • The other one is a bit smaller in the early version (1.320 instead of 1.584 scale units).

• Decorative (unsolid) Trees
  • All of these are smaller in size in this version, and four of them were also positioned slightly different (such as the first set of trees seen behind the walls in the section with the Chain Chomp).

• Missing objects

The following objects are not present in this version: item boxes, Piranha Plant's pipes (pakkun_dokan), Chain Chomp, the sun and the lens effect.

Item Routes (ITPT and ITPH)

These sections are empty, so items such as the Red or Blue Shells won't follow a predetermined route when fired. In addition, using the Bullet Bill will crash the game, as it doesn't know where to go. This is not possible to see in-game however, since this version lacks item boxes.

Object/Camera Routes (POTI)

• The air balloon route has less points in this version, which makes its movement less smooth.
• The second point of the route assigned to the second Goomba is positioned lower in this version, as a result of the bump being less tall in the early version.

Triggers (AREA)

A single AREA entry exists in this file. It is type 0x05, which was used in certain competitions/tournaments that took place in a specific part of the course to control which portions of the minimap appeared on screen. It has a rectangle shape, and it's located in the southern part of the track (the section with the Goombas).

How the minimap looks like when this AREA entry is removed.

This is responsible for mispositioning the minimap, making it look like there is none. By removing this entry (which can be done by changing the byte at offset 0x10B5 in the course.kmp file from 0x01 to 0x00), we can see the minimap again.

How the minimap would look like if this version had a matching minimap model.

If the minimap model actually matched the course layout, we could see that it is supposed to zoom-in on the last section of the track (where this AREA trigger is positioned), as shown above.

Cameras (CAME)

The early version does not have any cameras defined. This will make the course opening cutscene end abruptly, and the camera will always stay behind the player after the race has ended or when watching a replay.

Respawn Point (JGPT)

The respawn point is located more backwards than in the final version, and it is also slightly more shifted to the left.

Stage Info (STGI)

This version lacks the lens flare flash effect that appears when looking at the sun, and additionally, the transparency for said effect is set to 0x00 (in the final version, it is 0x4B).

Either way, it is not possible to see this in-game, since this version does not have the object that makes the lens effect appear in the first place.

old_mario_gc_hayasi

Download old_mario_gc_hayasi.szs (Restoration) File: MKWii old mario gc hayasi Restoration.zip (1.32 MB) (info)

Another unused version of GCN Mario Circuit, named after Yugo Hayashi from the game's Planning team. Unlike with old_mario_gc_b, it is impossible to load this track by swapping it with another course, as most of its subfiles are stored in an early version of their respective formats.

General

• This track does not have a course ID defined, so it cannot be loaded with code. The only way to load it is by swapping its SZS file with another course.
• This course does not have a multiplayer version (those whose filenames end with *_d).
• All the subfiles are stored in the root of the archive, instead of being inside a subdirectory named "." (dot).
• This course lacks a minimap model, which will make the game crash. However, earlier versions of the game lacked minimaps.
• The course is rotated 180 degrees in comparison with the final version. This was likely done to orient the minimap in the same way as in Double Dash!!, since it would look upside down if the rotation from this version was kept, as seen in this mockup.

Models

Both the course and skybox models (MDL0) are stored in an older version of the format, version 8, when the final game only supports version 11. And in the same way, the water texture animation (SRT0) is in version 4, when the final version can only handle version 5 files. Because of this, trying to load these files will crash the game.

The textures are stored in TEX0 version 1, when the final game only supports version 3. However, loading them actually works, since both versions share the same data structure with 1 section.

Once converted to the supported formats, the models, textures and texture animation look and behave seemingly the same to the ones seen in old_mario_gc_b (with the course model being ported directly from Double Dash!!), the only exception being that both the course and skybox models from this version have normals, just like in the final version. This makes the shading look smoother in comparison to old_mario_gc_b, for example, as seen here. However, this can't be seen in-game, as vertex colors are used to give the shading instead.

This course also has an SCN0 file (in version 4, all other leftover SCN0 files in this game are in version 5), whose data is apparently the same as the one from old_mario_gc_b as well.

Collision

Identical to old_mario_gc_b, with one exception: this version adds two tree trunks for both trees that normally appear in the beginning of the big curve with the Chain Chomp. Not only do none of these trunks match the shape of the actual tree model, but the collision type is set to "regular wall" instead of "wooden", much like with the rest of the course's walls. In the final version, the tree's collision is not stored in the course's collision model itself.

Parameters

The course.kmp file is in an older version of the format (0x0640) in which some sections have a different layout, meaning they will crash in the final game. The older format has 8 sections, while the final version has a total of 15.

Starting Position (KTPT)

old_mario_gc_hayasi	Final

The starting position is placed slightly further than in the final version.

CPU Points (ENPT)

old_mario_gc_hayasi	Final

There are a total of 34 CPU points, 24 less than in the final version. It is impossible to know exactly how these points were linked and grouped together, as the section that controls this (ENPH) is missing. Because of this, CPUs won't move at all.

A few extra parameters are also unknown (such as the width in which the CPU can navigate and a few other settings like when should the CPUs use a Mushroom, do a wheelie, etc.), as this version of the format does not implement these entries.

Checkpoints (CKPT and CKPH)

old_mario_gc_hayasi	Final

This version has 41 checkpoints, 10 more than in the final version. They are also shorter in length for the most part, and because of this, the right corner of the entrance to the tunnel is outside of the area defined by these checkpoints.

The last three key checkpoints (in pink in the images above) are placed differently between both versions.

Objects (GOBJ)

This section is empty.

Object/Camera Routes (POTI)

This section is empty.

Cameras (CAME and AREA)

old_mario_gc_hayasi	Final

There are 8 cameras defined in this version: 7 FixSearch (static cameras that look at the player) and 1 Goal (after-race camera, highlighted in red in the images above), making this the only unused course with cameras defined.

They are all placed from the beginning of the track until around before the entrance of the tunnel, in different places when compared to the final version.
When the Goal camera is activated it will zoom in on the character very closely for a frame and then zoom out a little, to then stay in that position (in the final version, the camera starts far away from the character, to then slowly zoom in). This camera is also placed at a different angle.

While the first intro camera is defined to be the first one (index 0x00), that camera is not the type that is meant to be used in the intro sequence (with the type being OP_FixMoveAt, 0x05, and/or OP_PathMoveAt, 0x04, instead). Because of this, the camera stays in place behind the racers in the intro sequence (although this is just a side effect that is triggered when the game doesn't know which camera to use for the intro sequence).

old_mario_gc_hayasi	Final

Seven AREAs are also defined (seen above in semi-transparent yellow), all of which act as camera activators (one for each camera), so that when the player passes through them, its associated camera will activate. They are placed in similar positions as the cameras.

Other Sections

All of the other sections that the final game expects are missing, which is already enough to make the game crash.

old_mario_gc_narita

Download old_mario_gc_narita.szs (Restoration) File: MKWii old mario gc narita Restoration.zip (1.25 MB) (info)

Another unused version of GCN Mario Circuit, named after Minoru Narita from the game's Planning team. Unlike with old_mario_gc_b, it is impossible to load this track by swapping it with another course, as most of its subfiles are stored in an early version of their respective formats.

General

• This track does not have a course ID defined, so it cannot be loaded with code. The only way to load it is by swapping its SZS file with another course.
• This course does not have a multiplayer version (those whose filenames end with *_d).
• All the subfiles are stored in the root of the archive, instead of being inside a subdirectory named "." (dot).
• This course lacks a minimap model, which will make the game crash. However, earlier versions of the game lacked minimaps.
• The course is rotated 180 degrees in comparison with the final version. This was likely done to orient the minimap in the same way as in Double Dash!!, since it would look upside down if the rotation from this version was kept, as seen in this mockup.

Models

Both the course and skybox models (MDL0) are stored in an older version of the format, version 8, when the final game only supports version 11. And in the same way, the water texture animation (SRT0) is in version 4, when the final version can only handle version 5 files. Because of this, trying to load these files will crash the game.

The textures are stored in TEX0 version 1, when the final game only supports version 3. However, loading them actually works, since both versions share the same data structure with 1 section.

Once converted to the supported formats, the models, textures and texture animation look and behave seemingly the same to the ones seen in old_mario_gc_b (with the course model being ported directly from Double Dash!!).

This course also has an SCN0 file (in version 4, all other leftover SCN0 files in this game are in version 5), whose data is apparently the same as the one from old_mario_gc_b as well.

Collision

The collision file is byte-to-byte identical to the one from old_mario_gc_hayasi.

Parameters

The course.kmp file is in an older version of the format in which some sections have a different layout, meaning they will crash in the final game. The older format has 6 sections, while the final version has a total of 15.

Starting Position (KTPT)

old_mario_gc_narita	Final

The starting position is located in almost the same place as in the final version, albeit rotated 180 degrees in the Y-axis.

CPU Points (ENPT)

old_mario_gc_narita	Final

There are a total of 32 CPU points, 26 less than in the final version. It is impossible to know exactly how these points were linked and grouped together, as the section that controls this (ENPH) is missing. Because of this, CPUs won't move at all.

A few extra parameters are also unknown (such as the width in which the CPU can navigate and a few other settings like when should the CPUs use a Mushroom, do a wheelie, etc.), as this version of the format does not implement these entries.

Notably, all of these points are indexed following the course in reverse (i.e. the first point is located before the finish line, the second one before it in the jump, etc).

Checkpoints (CKPT and CKPH)

old_mario_gc_narita	Final

This version has 27 checkpoints, 4 less than in the final version. They are also shorter in length for the most part, and because of this, a few locations are outside of the area defined by these checkpoints.
Most of these are also placed in diagonal, and in some places (like around the beginning of the tunnel section), the position tracker will show an incorrect position number, to then correct itself as the player continues to drive. This is because the checkpoints located in those places do not form convex quadrilaterals with the next one that is linked to.

Just like with the CPU points, all of these checkpoints are indexed following the course in reverse. This time, however, we can see that they are also linked following this order as well.

This, together with the fact that the starting point is rotated backwards, makes this version pretty remarkable, since it is driven backwards. Whether this was intentional or an oversight is unknown, however.

There is only one key checkpoint (the lap counter, in pink) located behind the finish line.

Objects (GOBJ)

This section is empty.

Object/Camera Routes (POTI)

This section is empty.

Other Sections

All of the other sections that the final game expects are missing, which is already enough to make the game crash.

old_mario_gc_yabuki

Download old_mario_gc_yabuki.szs (Restoration) File: MKWii old mario gc yabuki Restoration.zip (1.19 MB) (info)

Another unused version of GCN Mario Circuit, named after Kosuke Yabuki from the game's Planning team. Unlike with old_mario_gc_b, it is impossible to load this track by swapping it with another course, as most of its subfiles are stored in an early version of their respective formats.

General

• This track does not have a course ID defined, so it cannot be loaded with code. The only way to load it is by swapping its SZS file with another course.
• This course does not have a multiplayer version (those whose filenames end with *_d).
• All the subfiles are stored in the root of the archive, instead of being inside a subdirectory named "." (dot).
• This course lacks a minimap model, which will make the game crash. However, earlier versions of the game lacked minimaps.
• The course is rotated 180 degrees in comparison with the final version. This was likely done to orient the minimap in the same way as in Double Dash!!, since it would look upside down if the rotation from this version was kept, as seen in this mockup.

Models

Both the course's and skybox's models, textures, and texture animation are byte-to-byte identical to the ones from old_mario_gc_narita.

Collision

The collision is almost the same one from old_mario_gc_hayasi, with the collision model itself being identical to that one. The only differences are the thickness, the spatial grid first coordinate and the hitbox radius cap header parameters. The "Spatial index" section, which is used to determine which of the model's triangles will appear in each cube of space, is also completely different as well.

Notably, if a racer is using a kart, they will bounce when first entering the course. The exact reason for this is unknown, though it might be related to one of the header parameters mentioned above.

	old_mario_gc_yabuki	old_mario_gc_hayasi
Thickness	100	300
Spatial grid first coordinate (X, Y, Z)	(-21254.80078125, 853.479614257812, -36923.25)	(-21454.80078125, 612.438903808594, -37316.14453125)
Hitbox radius cap	50	250

Parameters

The course.kmp file is in an older version of the format (0x0640) in which some sections have a different layout, meaning they will crash in the final game. The older format has 8 sections, while the final version has a total of 15.

Starting Position (KTPT)

old_mario_gc_yabuki	Final

The starting position is located in the exact same position as old_mario_gc_hayasi, albeit rotated 180 degrees (0x43340000) in the Y-axis.

CPU Points (ENPT)

old_mario_gc_yabuki	Final

There are a total of 55 CPU points, 3 less than in the final version. It is impossible to know exactly how these points were linked and grouped together, as the section that controls this (ENPH) is missing. Because of this, CPUs won't move at all.

A few extra parameters are also unknown (such as the width in which the CPU can navigate and a few other settings like when should the CPUs use a Mushroom, do a wheelie, etc.), as this version of the format does not implement these entries.

Much like with old_mario_gc_narita, all of these points are indexed following the course in reverse (i.e. the second point is located before the finish line, the third one before it in the jump, etc).

Checkpoints (CKPT and CKPH)

old_mario_gc_yabuki	Final

This version has 61 checkpoints, 30 more than in the final version. They are also shorter in length for the most part, and because of this, a few locations are outside of the area defined by these checkpoints.

Just like with the CPU points, all of these checkpoints are indexed following the course in reverse. This time, however, we can see that they are also linked following this order as well.

This, together with the fact that the starting point is rotated backwards, makes this version pretty remarkable, since it is driven backwards. Whether this was intentional or an oversight is unknown, however.

There is only one key checkpoint (the lap counter, in pink) located behind the finish line, and interestingly, the previous checkpoint that is linked to it is located after this lap counter.

Objects (GOBJ)

This section is empty.

Object/Camera Routes (POTI)

This section is empty.

Cameras (CAME)

The early version does not have any cameras defined. This will make the course opening cutscene end abruptly, and the camera will always stay behind the player after the race has ended or when watching a replay.

Triggers (AREA)

This section is empty.

Other Sections

All of the other sections that the final game expects are missing, which is already enough to make the game crash.

course.0

Download course.0 (koopa_course.jmp) (Restoration) File: BCWii-early-KevinVG207.zip (1,44 MB) (info)

course.0 is a unique file across all courses, as it's a representation of an early version of Bowser's Castle collision and parameters prior to being compiled into a archive file.

This file seems to represent an earlier version of the parameters format, as it describes features from Mario Kart DS. The file has been of great use to hackers, as it contains metadata describing the format of courses and revealing much information about the course parameters (KMP).

Header

The section HeaderInfo gives us general information on the file.

course.0 was created by Kosuke Yabuki (from the game's Planning team) on August 30th, 2007 11:50 (AM) using a piece of software called JMap, which is part of Nintendo's JSYSTEM middleware. It seems the original filename for course.0 was koopa_course.jmp, and was stored in the following directory: D:\RevoKart\rawdata\Race\Course\Model\koopa_course\

The version that JMap was when this file was created is 2.8.4.1 (as a matter of fact, The Legend of Zelda: The Wind Waker and Twilight Princess also contain leftover JMap files, although they are both on version 1.31).

Map information (Stage)

StageDefine and StageInfo define global information about the course. In a compiled parameters file (KMP), this corresponds to the STGI section. Each entry is as follows:

Name	Description	Values	The entry appears in the final version of the STGI format?
ID	The course identifier.	-	✘ (Leftover from MKDS's parameter format)
STAGE_TYPE	Appears to be the slot identifier. Interestingly, it lists the IDs and filenames of much of the MKDS's courses.	(See below)	✘
TotalLap	Number of laps.	-	✔, but unused.
corner	Decides whether players start from the left or from the right of the start line.	LEFT = 0 RIGHT = 1	✔
GP_TYPE	Appears to dictate in which game mode the track is meant to be played.	(null) = 0 Test = 1 MINI_GAME = 2 (Battle Mode) Grandprix = 3	✘
START_POS	Decides whether players are closer or farther of each other when starting the race.	default = 0 (Normal) short = 1 (Closer together)	✔
FLARE_COLOR	Lens flare color.	-	✔
FLARE_TOBI	Enables the Lens Flare flashing effect.	ON = 0 OFF = 1	✔

Name	ID	Description
(null)	0
Luigi_GC	1	GCN Luigi Circuit
Mario_GC	2	GCN Mario Circuit
luigi_course	3	Early version of Waluigi Pinball
dokan_course	4	dokan_course
test1_course	5	test1_course
donkey_course	6	Early version of Waluigi Pinball
wario_course	7	Early version of Wario Stadium
nokonoko_course	8	nokonoko_course
mini_stage1	9	Nintendo DS
mini_stage2	10	Twilight House
mini_stage3	11	Palm Shore
mini_stage4	12	Tart Top
mini_block_64	13	N64 Block Fort
mini_dokan_gc	14	GCN Pipe Plaza
mini_stage7	15	Unknown. Interesting considering Mario Kart DS does not have a battle course named like this.
mini_stage8	16	Unknown. Interesting considering Mario Kart DS does not have a battle course named like this.
old_mario_gc	17	GCN Mario Circuit
old_yoshi_gc	18	GCN Yoshi Circuit
old_mario_sfc	19	SNES Mario Circuit 1
old_momo_64	20	N64 Moo Moo Farm
old_baby_gc	21	GCN Baby Park
old_koopa_agb	22	GBA Bowser Castle 2
old_peach_agb	23	GBA Peach Circuit
old_luigi_gc	24	GCN Luigi Circuit
old_choco_64	25	N64 Choco Mountain
old_choco_sfc	26	SNES Choco Island 2
old_frappe_64	27	N64 Frappe Snowland
old_hyudoro_64	28	N64 Banshee Boardwalk
old_donut_sfc	29	SNES Donut Plains 1
old_kinoko_gc	30	GCN Mushroom Bridge
old_luigi_agb	31	GBA Luigi Circuit
old_noko_sfc	32	SNES Koopa Beach 2
old_sky_agb	33-39	GBA Sky Garden

The values defined for course.0 are as follows. These values match with the final version of the course (for the parameters present both in course.0 and in the final parameters file).

ID	STAGE_TYPE	TotalLap	corner	GP_TYPE	START_POS	FLARE_COLOR	FLARE_TOBI
0	(null)	3	LEFT	(null)	default	15132390 (0xE6E6E6)	ON

KartPoint

The KartPointDefine and KartPointInfo sections define points used for different purposes. In a compiled parameters file (KMP), this corresponds to various sections, including the KTPT (starting position), JGPT (respawn positions) and CNPT (cannon destination position) sections. Each entry is as follows:

Name	Description	Values	The entry appears in the final version of the AREA format?
name	The name of the point (string)	StartPoint = Starting position JugemPoint = Respawn position CannonPoint = Cannon destination position	✘
pos_x	X position coordinate	-	✔
pos_y	Y position coordinate	-	✔
pos_z	Z position coordinate	-	✔
dir_x	X direction coordinate	-	✔
dir_y	Y direction coordinate	-	✔
dir_z	Z direction coordinate	-	✔
param1	1st point parameter. In all three point types found in course.0, it's the ID of the point.	-	✔
param2	2nd point parameter. The exact meaning of this parameter depends on the point type.	StartPoint = In the final game, it's padding. JugemPoint = In the final game, it's the range. CannonPoint = In the final game, it's the shoot effect, where 0 (same as -1 or 0xFFFF) is straight, 1 is curved and 2 is curved but slow.	✔

The values defined for course.0 (excluding the position and direction coordinates) are as follows:

name	param1	param2
StartPoint	-1	-1
JugemPoint	0	-1
CannonPoint	0	1
JugemPoint	1	-1
JugemPoint	2	-1
JugemPoint	3	-1
JugemPoint	4	-1
JugemPoint	5	-1
JugemPoint	6	-1
JugemPoint	7	-1
JugemPoint	8	-1
JugemPoint	9	-1
JugemPoint	10	-1

Starting point

To do: Add comparative images.

Respawn points

To do: Add comparative images.

Cannon destination point

Interestingly, there is a cannon destination point defined, which is located above where the giant Bowser statue is. The second parameter for this cannon (param2) is set to 1. In the final game, this makes the players travel in an arc through the cannon (instead of being launched directly towards the destination point). Either way, the collision model doesn't have a location defined for a cannon trigger, so the cannon can't be activated.

Interestingly, in the final game, the "group" that has all sets of SFX to load for Bowser's Castle contains the set used for the cannon sound effects too, as it includes the SFX set of index 638 (the cannon SFX set).

Cameras (Camera)

The CameraDefine and CameraInfo sections define the cameras. In a compiled parameters file (KMP), this corresponds to the CAME section. Each entry is as follows:

Name	Description	Values	The entry appears in the final version of the CAME format?
name	The name of the camera (string)	-	✘
pos_x	X position coordinate	-	✔
pos_y	Y position coordinate	-	✔
pos_z	Z position coordinate	-	✔
dir_x	X direction coordinate	-	✔
dir_y	Y direction coordinate	-	✔
dir_z	Z direction coordinate	-	✔
CAMType	Defines the type of camera	(See below)	✔
PathID	Index of the route used by certain types of cameras	-	✔
PathSpd	Speed of the camera	-	✔
fovy	Zooming start value	-	✔
fovy2	Zooming end value	-	✔
fovySpd	Zooming speed	-	✔
at_x	Start X position of the view point	-	✔
at_y	Start Y position of the view point	-	✔
at_z	Start Z position of the view point	-	✔
at2_x	Destination X position of the view point	-	✔
at2_y	Destination Y position of the view point	-	✔
at2_z	Destination Z position of the view point	-	✔
atSpd	Speed of the view point	-	✔
CamTime	Defines how long the camera is active	-	✔
NextCamera	Defines the index of the next camera to be switched	-	✔
CamShake	Camera shake parameter (always 0 in all courses in the final game)	-	✔
StartFlag	Start flag	-	✔
MovieFlag	Movie flag	-	✔

Name	ID	Description
Goal	0	This camera activates when the player finishes the race.
FixSearch	1	Static camera that always looks towards the player.
PathSearch	2	Camera that always looks towards the player and follows a route.
KartFollow	3	With the player as the origin, the camera's location is at View Start and it follows and points towards View End.
KartPathFollow	4	From its position, it looks at View Start and shifts view to View End.
OP_FixMoveAt	5	Meant for the course intro cutscene, it looks at View Start from its position and shifts view to View End if set, otherwise looks at player. It follows a route.
OP_PathMoveAt	6	This camera will move along a route with the player and turn with the player as well.
MiniGame	7	This camera is unused in the final game. Judging by the name, it may have been intended for when finishing a Battle match (as MiniGame is the codename for Battle mode). In fact, in MKDS's parameter format, camera type 0x07 is indeed the camera used after finishing Battle matches.
MissionSuccess	8	This camera is unused in the final game. Judging by the name, it may have been intended for when finishing a match in competition / tournaments or in the unused Mission mode. In fact, in MKDS's parameter format, camera type 0x08 is indeed the camera used after successfully finishing a mission.

course.0 does not have any cameras defined.

Triggers (Area)

The AreaDefine and AreaInfo sections define the triggers used for many different things (also known as AREA). In a compiled parameters file (KMP), this corresponds to the AREA section. Each entry is as follows:

Name	Description	Values	The entry appears in the final version of the AREA format?
name	The name of the AREA (string)	-	✘
pos_x	X position coordinate	-	✔
pos_y	Y position coordinate	-	✔
pos_z	Z position coordinate	-	✔
dir_x	X direction coordinate	-	✔
dir_y	Y direction coordinate	-	✔
dir_z	Z direction coordinate	-	✔
scale_x	X scale value	-	✔
scale_y	Y scale value	-	✔
scale_z	Z scale value	-	✔
AREAtype	Defines what the AREA should do.	(See below)	✔
CameraID	Index of the camera that should be activated by the AREA (for AREAtype = 0)	-	✔
pri	Priority value. A higher number means a higher priority to choose which area activates if multiple areas are intersected.	-	✔
param1	1st AREA parameter. In the final game, it's used by AREAtype 2, 3, 6, 8 and 9.	-	✔
param2	2nd AREA parameter. In the final game, it's used by AREA type 6 and 3.	-	✔
RailID	This is the route ID. In the final game, it's used by AREAtype 3 (in order to make moving road terrain move through a route)	-	✔
EneLinkID	This is the Enemy (CPU racer) point ID. In the final game, it's used by AREA type 4.	-	✔

Name	ID	Description
Camera	0	The camera in the CameraID field is enabled.
ObjClip	1	This may have been the equivalent of AREAtype 8 and/or 9 in the final game (used for disabling certain object entities in the course)
EfControl	2	This may have been the equivalent of AREAtype 1 in the final game (which defines where certain effects are enabled/disabled)
FogControl	3	This may have been the equivalent of AREAtype 2 in the final game (used for switching between different fog types)
PullControl	4	This may have been the equivalent of AREAtype 3 in the final game (make a moving road terrain move through a route)
EnemyFall	5	This may have been the equivalent of AREAtype 4 in the final game (force redirection of CPU racers)
2DmapArea	6	This may have been the equivalent of AREAtype 5 in the final game, which was used in certain competitions/tournaments that took place in a specific part of the course to control which portions of the minimap appeared on screen.

course.0 does not have any AREA triggers.

(Source: Custom Mario Kart Wiiki)

(Parameters format (KMP): Custom Mario Kart Wiiki)

(CAMType values: Custom Mario Kart Wiiki)

(AREAtype values: Custom Mario Kart Wiiki)

draw_demo

This is an early version of Mario Circuit. Since loser_demo.szs (the version of Mario Circuit that is loaded when a Grand Prix/VS Race/Battle is lost) is very close in various aspects to draw_demo, we will compare both versions specifically in this article, unless stated otherwise. For this reason, it's recommended to read this article on the differences between loser_demo and the final version of Mario Circuit before proceeding, as that contains most of the other differences not mentioned here (such as geometry and texture differences).

Visuals

Every single file used for the visuals (models, model animations, texture animations, etc) in draw_demo is byte-to-byte identical to their equivalents from loser_demo. This includes the files used for lighting and post-processing effects.

In other words, for all BRRES files in draw_demo, each of its subfiles are 1:1 the exact same as their equivalents from loser_demo.

The only exception being... the textures.

Textures

The textures on draw_demo use an older version of the texture format (known as TEX0): version 2 (a.k.a. v2). This is can be verified by looking at the value located at 0x0B in one of its texture files. The final game can only parse TEX0 v3 files properly (and technically v1 too, as they both share an identical file format).

Both the v2 and v3 formats have an almost identical file format, with the only difference being found on the header:

• On v2, there are 4 additional bytes at 0x10 (and 4 bytes less at 0x3C, to keep the header at a fixed size of 0x40 bytes).

• The byte at 0x0B, which represents the version number, is 02 on v2, and 03 on v3.

The bytes located at 0x10 are what's known as a section offset. In v3, there's only 1 section offset (which represents the address where the image data begins). However, in v2 there are 2 offsets, the 2nd one (whose purpose is the same as the section offset from v3), and the 1st one. The purpose of the 1st section offset in v2 is unknown, however, it seems to be unused, as its value is always 00000000 (i.e. pointing to the beginning of the file. It could also represent a null pointer).

The final game can only parse v1/v3 TEX0 files properly, and thus the code expects certain parameters at specific addresses in the header of the file. However, since the presence of that 1st section offset causes the following bytes until 0x40 to be shifted to the right, the values of the different header parameters (image format, dimensions, etc) get moved from the locations the code expects to read them from, thus causing the game to read wrong metadata, which ultimately causes the textures to look corrupt.

Some examples of header parameters read wrong include:

• Address where the image data begins: This value is often misread as 00000000, causing the texture to become a group of random pixels, as its reading non-image data.
• Dimensions: Both the height and width are incorrectly read as 0, which causes the game to read data out of bounds.
• Image data format: In all cases, this value is read as 0, which represents the I4 format. This explains why all textures look black and white, as this image format doesn't support color. In the roof of most houses (as well as the castle), the textures are mostly blue, but that's due to the blending with the shadow map texture. The blue color on the water is controlled separately by its material in the course model.

Restored textures

The textures can be "fixed" (i.e. converting them from v2 to v3) by moving the 4 bytes at 0x10 into 0x3C, and changing the byte at 0x0B to 03. Doing this with each texture file found in draw_demo and comparing the resulting file with its equivalent from loser_demo reveals that every single texture is byte-to-byte identical accross both courses. Since every other BRRES subfile (model, animations, etc) is also identical accross both tracks (as we stated above), this means that draw_demo is supposed to look exactly just like loser_demo!

(Technical explanation: B_squo)

(Texture (TEX0) Format: Custom Mario Kart Wiiki)

Collision

Top
draw_demo	loser_demo
Left side
draw_demo	loser_demo

In comparison with loser_demo, various polygons were flipped, while others weren't present in draw_demo, as seen above.

draw_demo	loser_demo

The most interesting change, however, is how the invisible walls located near the Chain Chomp are shorter in draw_demo. This might imply that draw_demo dates before the addition of the Boost Ramp to the course, which would explain why these invisible walls were made taller in the rest of the versions of Mario Circuit (to prevent players from jumping over the walls to the other side of the course).

Parameters

draw_demo uses a slightly earlier version of the KMP format (0x0910 instead of 0x09D8), where the only apparent difference is that the "Stage Info (STGI)" section is missing 4 bytes (see below). Even then, the game still parses the parameters correctly.

Starting Position (KTPT)

In comparison to the final version of the course, the starting point is positioned slightly more to the left and more forwards in draw_demo.
In addition to this, the racers start from the left of the finish line instead of the right (this is only noticeable if at least 2 players or more are present). While this was also the case in loser_demo, it couldn't be seen there due to the addition of multiple starting points (one for each player).

Objects (GOBJ)

draw_demo	loser_demo

Prerelease

In comparison to loser_demo, the position of most of the 3D flowers is different (highlighted in blue above). In fact, not only all the flowers now match the positioning of their shadows in the shadow map texture (unlike in loser_demo), but the positioning in draw_demo matches with the E3 2007/Fall 2007 Press Conference version of Mario Circuit!
An example is shown above: one of the flowers can be seen in front of one of the lamp poles to the right in prerelease footage, which has been carried over to draw_demo.

Missing objects

Most other objects, such as item boxes, Goombas, the enemy audience, the Chain Chomp, the sun and lens flare effect, the air balloon or the Boost Ramp are missing in draw_demo.

Respawn Point (JGPT)

The respawn point has the exact same coordinates as the starting point. In the final version of the course, however, it's placed a bit more backwards.

Stage Info (STGI)

This section is just like in loser_demo, albeit with the last 4 bytes (1 for the lens flare transparency value, and 3 for padding) being missing in draw_demo (due to the older KMP format).
The effects of the missing lens flare transparency byte can't be seen, as this version lacks the object that draws the lens flare in the first place.

Empty parameters

There are no CPU nor item routes, checkpoints (so laps don't count), camera/object routes, AREAs, nor cameras.

Code leftovers

draw_demo has a course ID assigned to it: 0x39. Funnily enough, its filename is written as draw_dmeo in the code of the game (this can be seen at 0x380514 (PAL) in /rel/StaticR.rel).
This means that, attempting to load the course via its ID will crash the game, since the filename doesn't match with the string from the game's code. The only way to fix this is by either renaming the course file to draw_dmeo.szs, or renaming the string in StaticR.rel to match the actual filename of the course.

No other code or data related to the course has been found. There haven't been any findings regarding code that attempts to load draw_demo via its course ID, either.

Possible purpose

The most feasible theory on the purpose of draw_demo is that it was meant to be loaded when a match ended up in a tie, which would have then triggered a unique cutscene.

The first evidence is on its filename: files with "demo" on their name are used for cutscenes, and two other similarly named courses, winningrun_demo and loser_demo, are used when a Grand Prix / VS Race / Battle is won and lost respectively, therefore "draw_demo" may have been used when a match ended up in a draw. In the final game, tieing results in either winningrun_demo (if playing a single match) or loser_demo (if playing a team match) being loaded instead.

This would explain the lack of most objects and other parameters, as mentioned above (since they're not needed for a cutscene). In fact, winningrun_demo and loser_demo also lack most of those objects and parameters as well.

Another piece of evidence is that the course ID for draw_demo (0x39) goes right after the IDs for winningrun_demo (0x37) and loser_demo (0x38).

Old theories and statements

Many stories have been circulating around trying to explain the purpose of draw_demo. However, most of them can be debunked with what we've explained above:

• It was a TEX0 test: This is very unlikely, since TEX0 files have been used ever since the first Wii games. Wii Sports or Wii Play, for example, use TEX0 version 1 files, which predate the version 2 files found in draw_demo.

• The track looks like this because the pointers that tell the course model which textures to load miss slightly: This is also false. As mentioned above, every single model is byte-to-byte identical to those found in loser_demo, and obviously, the models there look fine. Either way, the problem resides in the texture files themselves anyway, NOT the models.

(Source: B_squo)

draw_demo_d

This is the multiplayer version of draw_demo. It is identical to the single player version, with almost all of its subfiles being identical to it. The only exception is the course model, which was made less complex.

This course model and its textures are identical to the ones from loser_demo_d, the unused multiplayer version of Mario Circuit that is loaded when a player loses a Grand Prix/VS. Race/Battle, with said textures being stored in an earlier version of the format (TEX0 v2, instead of v3), which is what causes the corrupted visuals (see the article on draw_demo for an in-depth explanation regarding the textures).

winningrun_demo_d

This is the multiplayer version of winningrun_demo, the version of Mario Circuit used for the award ceremony. This file is never used, since the game loads the single player version when playing in multiplayer instead.

It is identical to the single player version, with almost all of its subfiles being identical to it. The only exception is the course model, which was made less complex (being byte-to-byte identical to the one used in the multiplayer version of Mario Circuit). Because of this, loading this version in the winning cutscene will make some animated trees appear merged with their respective static variants from the course model, since said animated trees were not removed from the parameters file. Other objects, such as the flowers, will also appear in conjunction with their static variants for the same reason, overall causing the course to appear to have a few more objects than usual.

In addition, loading the course in a multiplayer match will make every animated object become static as expected, which includes the crowd.

loser_demo_d

This is the multiplayer version of loser_demo, the version of Mario Circuit used when a player loses a Grand Prix/VS. Race/Battle. This file is never used, since the game loads the single player version when playing in multiplayer instead.

It is identical to the single player version, with almost all of its subfiles being identical to it. The only exception is the course model, which was made less complex. Because of this, loading this version in the losing cutscene will make some animated trees appear merged with their respective static variants from the course model, since said animated trees were not removed from the parameters file. Other objects, such as the flowers, will also appear in conjunction with their static variants for the same reason, overall causing the course to appear to have a few more objects than usual. In addition, loading the course in a multiplayer match will make every animated object become static as expected.

Curiously (much like with the used variation), it is a copy of an earlier version of Mario Circuit.