As the planned release of CTGP Nitro v1.1.0 draws near, we're performing the final bug fixes and tests to ensure everything works properly. Overall, the online experience is pretty smooth, and we're quite happy about that. It was during this more intensive testing, though, that we uncovered an interesting bug that was present in the base game.
If you enter a VS or Grand Prix race with a certain combination of characters, Waluigi's voice will be muted in-game. This is because, when loading the driver voice lines into sound heap memory, his is the last of that group of characters to have his loaded. The size of the sound heap these are loaded into is just a half kilobyte too small to fit his sound data, so the allocation fails and he is muted in-game. It's possible this was a niche bug not caught by the testers since it's relatively infrequent and difficult to notice when it does occur.
It became a problem for CTGP, however, since we have code in place to raise an exception any time a heap allocation fails. This has been of great use during development and testing, but proves adverse in a case like this, where the base game is tolerant to an allocation failing. However, since this was just a bug due to an improperly sized sound heap, we've increased it the required amount to allow this combination of characters to load properly.
See you on the other side!
— Garhoogin
In the last release, the title screen and the VS mode randomizer would only select tracks from the cup page you most recently played on. This isn't very fun when you first start the game since the title screen will only show tracks from the base game, and so will the random VS. Starting now in 1.1.0, both of these will select from the pool of all playable tracks in the hack.
For the title screen, the game would generate a random number using the current time and system tick count and use that to decide which track to show, taking the unlocked cups into consideration. All that needed to be patched here is the code that selects the track from this random seed. In CTGP, this doesn't even need to consider which tracks are unlocked since all tracks are unlocked.
For the VS mode randomizer, the logic is more interesting. Rather than choosing a random track every race, the game creates a course queue at the start of the session with all 32 tracks in a random order. This ensures that it is impossible to play the same track more than once in a given VS session, similar to how Random in online multiplayer avoids the previously played tracks. In this case, the allocation needs to be increased to accommodate all of CTGP's tracks, then the course IDs can be filled. The game shuffles the list using Fisher-Yates, so this logic didn't need to be touched.
With this expanding of track count, it only makes sense that the maximum number of races be increased as well. The game now currently has a total of 104 tracks, including those from the base game. Allowing the player to set the number of tracks to anything above 99 causes visual glitches in the UI, so we've set the maximum number of races in a single session to 99. Sorry.
— Garhoogin
Yes, CTGP Nitro 1.1.0 is still being finalized. With the people working on the project being pulled away to other projects and real life matters, progress has been slow. Though now that it's no longer 2023, all the title screens will need to be re-generated to reflect the change in year.
Happy new years!
— Garhoogin
One feature that has been notably missing from the previous versions of CTGP has been the lack of Custom Tracks Worldwide. In 1.0.0, online multiplayer was only possible through friends-only. The main focus was on getting custom regions to work, but this ended up not panning out. Instead, a cleaner approach was found to allow this to work without interfering with vanilla players.
We've also been taking much more effort to keep the code size as low as possible to cut less into the game's available heap spaces, which was a notable problem in the last version, especially online. Cleaner code and better debugging will make problems easier to troubleshoot before release.
— Garhoogin
In the base game, adding to the number of songs in the sounddata.sdat file causes things to break down. It's not immediately obvious either, since the first signs of problems are a bit more subtle.
The first thing that starts to break is the menu sound effects. Clicking buttons, for example, won't make any noise. Beyond this, other sounds will start failing to load, until ultimately the game does crash when loading a course. With enough added songs, the game will begin to crash on startup.
As it turns out, preventing the game from crashing on startup due to extra songs is to simply increase the size of the static sound heap. Since the header, FAT, FNT and info sections of the sdat are loaded into memory on startup, when these increase in size, later allocations to the same heap begin to fail.
To prevent any subtle or deferred issues from happening in the future, I wrote some heap debugging code that triggers a breakpoint on any failed allocation. Mario Kart DS does not make use of unit heaps, only extended heaps and frame heaps. Because of this, the heap debug code only involves modifying four functions (AllocFromHead and AllocFromTail for both heap types). This allows memory problems, beyond even just sound issues, from being debugged more easily. On hardware, these breakpoints trigger the debug screen, which should make it easier to judge the cause of failure is.
— Garhoogin
In the last release of CTGP Nitro, there was a set of 10 title screens, where one would be randomly chosen to display each time. These title screens were generated by Nintendo's graphics software for DS, and hence have notable color banding and dithering artifacts. This, in addition to the fact that the version number and year would need to be updated, compelled me to update the title images for the coming release.
It was recently found out that Mario Kart DS is using extended palettes for the main backgrounds, but only ever uses the first palette, effectively negating any benefit it would gain from using this. Because of this, an extended palette NCLR can be used for the title image and the whole palette will load just as expected. This allows for up to 16 palettes to be used on the game's title screen, with a palette size coming in at 8KB, up from 0.5KB where just one normal palette is typically used.
The unlocalized title images (all except Shyguy's) had a total file size of 660KB, which is apparently enough to ensure that the game does not get past the title screen on some B4DS configurations, so increasing the palette size by 7.5KB per title image (75KB of total file size!) seems like a poor choice. However, each title NCGR was a full 256x256 image, to account for the logo graphics that are blended on top of the background. However, since the display configuration manager clears the background VRAM before loading the new graphics in, this extra padding underneath can be omitted, saving 16KB per image (160KB in total). With each image using its own set of extended palettes, each would also now need its own dedicated NSCR, taking up about 1.5KB each, totaling 15KB.
So with adding 75KB of palette size and reducing the graphics size by 145KB, it comes out to a net 70KB savings.
With the new extended palette title images, color banding is noticeably reduced, with color gradients appearing less "crusty." There is still some dithering visible, but it is less harsh than it used to look.
Is this too much effort to go through for just the title screen images? Maybe. I feel like the title screen images are worth investing a good amount of time into for the sole reason that they are one of the first things that you see when you boot up the game, so making them look clean makes the game feel cleaner overall.
— Garhoogin
The past two releases of CTGP Nitro were built using quite a tedious set of tools. New Super Mario Bros. Editor was used to build and patch extra code, which required opening the GUI every time the ROM needed to have code patched (every time the code is changed or the ROM was repacked). This gets old pretty quick.
The next release of CTGP is making use of TheGameratorT's NCPatcher (massive thanks Roco for porting the code to it), which can be found on GitHub at https://github.com/TheGameratorT/NCPatcher. This allows us now to pack the ROM and patch code in one single command, making the build process much less tedious.
The previous releases have also been managed by editing tables in code. So any time a course needed to be moved around or updated, scattered tables across a couple source files would need to be modified. The course IDs were also tied annoyingly to UI positions in the cup menu, which meant that moving a course from one cup to another would require moving it around all of these tables. Now, these tables are generated automatically from some CSV files. One file outlines the courses and their attributes, one controls the course layout in the cup menu, and one controls the battle stage selections.
Generating battle course pictures has been made a bit more straightforward, and can make better use of palette sharing than the base game did with its pictures. Since all 12 palettes are loaded at all times, all pictures can theoretically use any of these 12 palettes at will, which is exactly what the new utility makebpic does. It can take 6 image files as arguments and generates the NCL, NCG, and 3 NSC files.
All these changes in workflow make it a less arduous task to carry out management tasks with tracks and battle stages, letting things move more smoothly as we hope to gear up for a release around August.
— Garhoogin
This is the first post on the new CTGP Nitro development blog. From now on, this blog can serve as a place to receive updates on what's been going on in CTGP Nitro development lately. Hope this might be interesting to some.
— Garhoogin