Kid Tripp  

Kid Tripp Nintendo Switch Development Blog

Phase 5

The start of a long day

The first empty Switch implementation I decided to tackle was the Texture. Having worked on the Hello World code, this was still fresh in my mind and I was surprised by how little platform specific code needed to be added to the object. I really wish I'd known how to code like this when I first wrote an engine! Next I added graphics hardware initialisation and shutdown to the Switch renderer along with clear buffer and swap buffers. Modern rendering systems work by having at least 2 buffers which contain the data for the images you see on the screen. The 'front' buffer is the completed image currently being displayed and the 'back' buffer is the one that is being drawn for the next frame. 'Swap buffers' does just that, once the next image has been completed, it is swapped to become the front buffer and the old front buffer is drawn over. Clear buffer just makes sure you don't leave any of the old image behind.

Now I have some code in my engine that I can actually test on the Switch. Simply by running the existing test code that draws some sprites to the screen and setting the clear colour to something vibrant rather than dull black, I can see that the code is running. I could mess around changing the clear colour every frame, but I'm confident it is working, no sense spending any more time on it.

Preparations for the sprites

Next I create some structures that will hold the data that the rendering hardware will need to render the sprites. It is possible to just tell the graphics hardware to draw 2 triangles immediately whenever you want to draw a sprite. It isn't a good idea to do this though, you very quickly hit performance issues. Graphics hardware works best when you don't change state too often or perform too many draw calls. The code I wrote batches up sprites that share the same texture and only calls for them to be drawn by the graphics hardware when a new texture is used or swap buffers is called. As it happens, Kid Tripp on 3DS and Switch only uses a single texture so every frame of the game is drawn in a single call to the hardware.

Next I add the shaders. These are taken exactly as they were in the 'Hello World' code. Finally I add the code to populate the sprite data structures for the graphics hardware and to draw them. I'm making that sound pretty easy, but it took quite some time to get the test code running and looking just about right. At this point I decide to try the Kid Tripp code again. It turned out that there was just one Switch library that need to be initialised for it to run and it runs pretty well. Here is a link to a video I Tweeted out earlier.

Finishing off for the day

Next I fixed up a few bugs - texture colours were wrong, sprites weren't scaled, flipped or rotated and I made a couple of improvements. The changes I had made prevented the PC and 3DS builds compiling so I got those fixed up again. Then I decided to have a quick look at getting controls into the game. How hard could that be? Well, despite having a nice empty Switch implementation ready to drop the new code into, it took a little longer than I expected, mostly down to me making assumptions about how to read the controller properly! Never mind, it works, at least when the Switch is in handheld mode with the controllers attached.

Next I needed to change the Kid Tripp code to handle the screen resolution of the Switch. Kid Tripp is a little odd in the way it deals with screen resolutions. The game draws to a virtual screen of 142x96 pixels, but these are magnified by 3 times to 426x288, which gives the game that nice chunky look however, we sometimes cheat and display some of the text at x2 and x1 magnification where we need to fit it on screen better. This intermediate screen resolution is fine for the 3DS, it can be cropped down to 400x240 without a problem. For the Switch, we need to scale it up further. I experimented with a total magnification of x8 which gave a pretty good height for the Switch's screen but left borders at either side. x9 magnification crops quite a lot off the top and bottom of the display but as it happens gives exactly the same view as on the original iOS version running on the highest resolution screen, so that is what I have settled with.

That's me done for today. The finish line is definitely in sight, I need to sort out load/save (no idea what it isn't working already) and put audio in for me to consider the goal I set out to achieve as being complete. Here's another Tweet with a video of the game running properly on the Switch. The video quality is terrible! It runs smoothly in real life.

Conversion Time

Time in this Phase: 8h 25m

Total Time: 30h 05m

Total Technical Debt Time: 6h 05m

More Pages

Overview
Phase 1
Phase 2
Phase 3
Phase 4
Phase 6