Introducing TX-1696

So here is what I have been up to

Programming games for me is easy now as in the last 30 years or so I have made over 35 games on different platforms, however z80 took me a while to learn, and if any of you have been following my updates here, you will see that my journey has involved lots of Googling and learning.

My approach to this game has been my normal approach, which involved getting a dev environment up and running, then doing some test code to understand how the platform works, then expanding from that point.

I started with an object list, this is memory reserved for game objects or sprites which should not be confused with the hardware sprites in the spectrum next, my game objects contain more parameter’s than are needed to simply draw the sprites, things like an object type identifier animation speed, address of the animation frames, address of the collision data for the animation frames etc.

With this kind of structure, I can simply create the object and then run it through the same game code as all the rest, and it just works. Almost like writing a sprite engine that handles animation, movement, collisions and display, for speed I implemented a linked list, now I originally ported my c++ linked list that had been using for year, but it was not until recently that I discovered a bug in the code and decided to rewrite it from scratch which has turned out faster and smaller that the port. So that was a win.

The reason I chose a linked list was so that I can quickly get a new object and only traverse through the objects I am using to either draw or move etc. The alternative method is to have an array of objects and when I want a new one, I have to go through the whole array and test to see if its in use, if not then check the next and so on, likewise if I want to move everything, I would have to check the whole array again to see if it’s in use, then move it.

The next thing is collisions, I check my collisions in the move object’s function which iterates through the used linked list. I found here I could save some loops in TX-1696 by simply arranging the object IDs in things to check and things to check against, for example you would not want to check each shot against all the other shots when checking if you killed a baddie, so by having all the shots on IDs say 1-31 and all the baddies say 32-64, then if I am checking the shots against an object I just see if the id greater than 32 if so, check the collisions

To create the data and files for the map and the sprites I wrote the next graphics c# app, which only took a week or so, and then a bit more time here and there as I added features like my parallax scrolling and fixed the bugs, but now its quite easy for me to make art and get it into the game.

Art, yes let’s talk about the art, for many years I have been using 3dsmax to create game art for my games which has made it much easier for me, however rendering 16 colour sprites has been a little more challenging, luckily there is some things built into 3dsmax that produced the output I needed. Firstly, I used ink and paint materials, and turned off the ink, so I am just getting cell shading as you can see in the typical material below, also notice in my render settings I have turned off all antialiasing which gives it that crisp pixel art look when rendered to a png-256.

Also, sometimes I would need to do some photoshop work on the art, here I used a pencil, or a brush with the feather set to zero and interpolation is set to nearest neighbour, while avoiding resized and the like, basically restricting photoshops ability to blur my images. Also, when I saved my images I always chose “save for web” which is now under legacy tools, here I chose PNG-8 which limited the colours to 16, making the output ripe for importing into my Next Graphics tool.

As for the movements I wrote another tool called Bezier Designer, well that’s not true, actually I originally wrote a tool that used Pythagoras sin and cos tables to define the movement patterns, but one of the responses I got when I shared it was that they used Beziers, and for me this was high end math which I have tended to stay away from, however I was struggling to get the baddies to match the map, as in TX-1696 I wanted the bad guys to actually follow the shapes in the map and with that Bezier comment in the back of my mind I then looked into Bezier curves. I found out they were much simpler than I thought and that there was a drawBezier in c#. So wrote the Bezier Designer tool, which outputs x and y positions of the sprites on the pattern data.

But like all my other tools they expand over the project so Bezier Designer now also outputs frames if I want the object to rotate along the path.

It also manages my hardware sprites, telling me how many hardware sprites are on screen at any one time. As part of the output data, it outputs upload data giving me a dynamic hardware sprite management. So in game my create new baddie function handles the uploading and replacing of the hardware sprites in FPGA sprite memory via the DMA, it does this seamlessly in the background. So, another win.

Having the source code to the tools, means I can add functionality and improve the output making the process simpler, and this would be a major win if I intend to make more games, but I think this may be my last, but then I have said that before.

I will leave you with this short video!

Press play

Nerd Attic review of work in progress

For a longer video and a pre review of work in progress click here