So here we are, for the sixth and hopefully final time. It’s the end of the second last trimester of my studies and I need to summarise all the things that I’ve done. And should get marks for. Right, let’s get to it.
Hello once more, reader! It’s time for another blog, this time focusing on a brand new subject I’ve not touched before. Data Security.
It’s no secret that games collect data – all kinds of data. From analytics, to login details, to personal player information, to payment info. And of course, when this data is stored it needs to be protected in one way or another from those who would try to access it without the proper authorisation. In a worst case scenario, if your data is accessed illegally, money or identities could be stolen, and lives harmfully impacted, even ruined. So this is pretty important.
Now, each different type of data will require a different level of security, proportional to how devastating it would be if that data were made public or got into the wrong hands. If your analytics data for the average amount of time players spend browsing through the options menu gets out, it’s going to be far less terrible for everyone than if the credit card data for your users gets stolen. So you’re going to want to protect that second one a fair bit more, to say the least. But how much? And how?
Hey reader! You read that title right, today I’m looking at the rendering systems of the Nintendo Entertainment System. It’s an old system, and one I’m not likely to be developing on in the near future, so it’s an understandably and odd choice to be analysing. However, it’s one of the few consoles that not only has a host of hardware information readily available, but also has an architecture simple enough to get a grasp on with relative ease.
Anyway, the core of what I’m going to be looking at today is the rendering processes and limitations of the console, since I don’t have to break down the entire thing. More importantly, I’m going to be looking at some of the ways these impact how one would design a game for the NES. So let’s get to it.
Hello again, reader! I’m back to talk about shaders again. A number of weeks ago I had the pleasure of working with Jack McClenaghan to create a distortion shader and beat-mapper for an outrun themed project he and some others were working on – Synthracer Maxiumum.
The idea behind the game was that players would drive around a track whilst objects in the world around the them distorted to beat of the music. But this wasn’t any distortion, it had to be glitchy and retro, so as to fit with the game’s 80s outrun aesthetic. All this took some doing, but it turned out pretty damn well.
Well hello there, reader. It’s time to talk about optimisation – the process of realising that what you did the first time was terrible and finding a new way that runs a hundred times better. Fortunately, in the particular example I’m about to go through, I’m not optimising my own code, but a program provided to me.
This idea behind this program is that it renders an image of various 3D shapes by using a series of ray traces. For each and every pixel in the window, the program performs a ray trace that returns the colour of that particular pixel, one by one. Considering there are a few thousand pixels involved, this takes a while. By default, the original took 80.157 seconds to render the entire image on my machine. That’s my time to beat.