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

19 thoughts on “Introducing TX-1696”

  1. Hi Patricia. I would be happy to help test your games. There is no one particular type of game that I play but I not platfromers. I am intrigued with games that show innovative features and true quality and thoughtfulness of design execution. You can hit me up by email or on fb if u like. Cheers. Jay

  2. That looks awesome Patricia. Fantastic work and a great quote up on how you made it..
    Essence of R-Type which is a firm favorite.
    Definately count me in on game testing! (in running cspect until ks2 arrives)

  3. The graphics are quite superb given the Next’s low resolution.
    Have you ever used a state machine in your games? An event driven state machine is ideal for handling game flow; states only respond to events they’re interested in and ignore others, which removes a lot of redundant code.
    Anyway, don’t stop writing games Patricia. If TX-1696 is typical of your skill, you surely cannot stop.

  4. This looks fantastic! I love the style and how much you have moving around. If you need a play tester, I am a big shooty fan, especially R-Type 1&2, X-multiply, Cybernoid, Rex, Salamander, Thunder Cross II etc etc… I’m only on CSpect though!

    1. I will sort something out, many people want to test, but you are the first to actually tell me what you like playing and well if Salamander is on your list then you should certainly have a a test of some of it.

      1. No problem – happy to help if I can. There are obvious echoes of Salamander – with the drone movement following the ship’s path, and the additional partial vertical component to the scroll opening up the playing area (compared to R-type for example). Keep up the great work!

        1. Your comment nagged my memory further…something wasn’t quite right…so I’ve been on a YouTube historical journey, and realised the Gradius version I was remembering best is Vulcan Venture.

  5. Love to see the insights of artisan game development. I don’t know how much coding difficulty is added with the vertical scroll but it brings a fresh approach to R-Type games in Spectrum. Like the graphics and speed too. Congrats, it looks it’s gonna be a great game.

Leave a Reply to Dean Swain from the Retro Asylum podcast Cancel reply

Your email address will not be published. Required fields are marked *