Kid Tripp Nintendo Switch Development Blog

Phase 3

DHL Tracking

As mentioned previously, I'm currently waiting for a delivery of some Nintendo Switch development hardware. DHL has the package and Nintendo provided me with a tracking number. I've decided that DHL are pretty terrible for package tracking compared to other delivery companies. When I first went to the tracking section of their site and entered the tracking number, it reported that it was not recognised. It still does that. Nintendo kindly managed to find out how to track the package and sent me a link to a different part of the DHL site that actually worked.

So, as of 5AM this morning, my package was still showing the same status as late last night, in the UK, on the way to the delivery depot. The UK is not that big, it could have made it from one corner to the most distant corner in that time. At about 8:30am, I was all ready to start work on Phase 3 so I hit F5 one more time. The status had changed! Now it was at the delivery depot. Good stuff, it was looking likely that I would be getting it today! Then I heard a strange tapping sound. Can't be the front door, we have a doorbell. Probably one of the three cats we have, the one that likes to murder anything smaller than it, and a few things bigger, in the local neighbourhood. I figure I should check, just in case and to my immense surprise, there is a delivery van parked outside the house. I have my Switch development hardware. I am very happy.

Finishing up Phase 2

So, after unpacking everything, having a fiddle with the settings and getting familiar with how the hardware works, I try to run the sample demo that failed to run on the PC. It fails. About three times, with no error message that I could be bothered looking into too much. I checked some documents to see if I was doing anything wrong and decide to try again part way through checking. This time it works fine. No idea why. Now to check the test code that ensures that nagEngineCore works fine. Remember I ran this on PC and was 100% sure that it would work on the hardware when it arrived? I was right. It worked fine first time.

Technical Debt

Programmers often have choices to make, particularly when there is limited time to implement a feature. They can choose to ignore the time constraint and 'do the job right' or they can save time and 'do the job wrong'. Right and wrong aren't really the best terms to use, no code that achieves the required output can be considered 'wrong', just not optimal, or inflexible. nagGame unfortunately carries a lot of technical debt. It evolved from mixEngine which I originally created when I first converted the Digger Dan DSiWare source code to run on 3DS. I managed to extract the engine functionality from the original source, but I didn't do a great job of the architecture of that engine. To make matters worse, when I made the engine work with on the PC for rapid development, I didn't fix any of the architecture issues, I just piled more problems on top. This is what is known as Technical Debt. You borrow time from the future in the hope that you never have to pay it back, but when you do, you pay it back with interest!

nagEngine was going to be the end of the technical debt in mixEngine. I built it from the ground up taking cues from the original mixEngine code but getting the job right first time - right in terms of making it easy to add to, modify and to port to new platforms. nagEngineCore was completed by the time I started work on Kid Tripp, and this is evident in the fact that I was able to produce the Switch implementation of it in about 6 hours. I had barely started nagGame, however, so when I got the source code for Kid Tripp with a view to making only a 3DS version, I made the decision to simply copy over the content of mixGame into nagGame retaining all the technical debt.

So what is Phase 3?

Phase 3 is to remove (or at least reduce) the technical debt. I hadn't actually planned to do this, but when I looked at the existing code again it made me weep. That means that for all of today, I have not written a single line of Switch code for my shiny new development hardware, but I am happy with the results so far.

The first object that I tackled was the nagTexture object. This imaginatively titled object represents a texture held in graphics memory ready for rendering to the screen. Despite is turning out to be a pretty simple object when I was finished, all it does is load the image data from a custom file format, convert it where necessary for the graphics hardware and provide a means of referencing that data when it is on the graphics hardware, it took a remarkably long time to fix up. The end result is that I can now create a Switch implementation of the nagTexture object in about 1 minute that compiles but doesn't do anything and all that will be missing to make it work will be a fairly small amount of Switch specific code, the rest is shared across all platforms.

After sorting the texture object I performed similar actions for nagSprite and nagInput. Both of these were fairly simple and fast compared to nagTexture. All that remains now is to tackle nagRenderer - the beast that deals with the sprites and textures and renders them to the screen. This currently has different source files for the Win32 version and the 3DS version, but a lot of the code inside those files is common. A good amount of it could be moved into the shared nagSprite object and doing so could also offer a performance boost, so that is definitely something I should do. I'm considering leaving most of nagRenderer untouched though, it really will be a huge job to sort it out properly and I've already delayed the Switch implementation quite a lot today.

Decisions, decisions

I don't know whether the time spent resolving the Technical Debt should count towards the total time spent on the Switch conversion. It isn't contributing directly to the Switch code, so maybe it shouldn't count. But then again, the Switch conversion will be faster with the work done, so maybe it should. For now, I've decided to track the total amount of time spent on Technical Debt whilst still including it in the total time spent.

There will be no further progress until the weekend as I have a couple of family events, so I'll have time to decide whether to sort out more of the technical debt or actually get on with the Switch conversion.

Conversion Time

Time in this Phase: 8h 05m

Total Time: 17h 10m

Total Technical Debt Time: 6h 05m

More Pages

Overview
Phase 1
Phase 2
Phase 4
Phase 5
Phase 6