Hello and welcome to week 4 of Deep Madness development logs. This week, I kept working on the tile system. For the most part, that means I don’t have a lot of visually appealing things to show off for you, but I did make one small change which made the whole game look nicer. I replaced the squares with actual textures.

On the technical side of things, I had to spend a fair amount of time working on the bitmap rendering code. The original version I was using was fairly haphazard. You see, bitmaps are essentially composed of two segments, the heading and the pixel data. The heading contains information such as the width and height of the image as well as how much data is used for each pixel and other technical details like that. The pixel data is essentially a long row of numbers which records what color each pixel is in the image, row by row. When I originally wrote the bitmap rendering code, I had no idea how to get any of the header info or how to find the point where the header ended and the pixel data began. My original solution was to just jump to the end of the data, and then jump backwards to the beginning of the pixel data because I could calculate that. Obviously, that was weird and led to various problems.

As I discovered when I was working on solving this, the header actually tells you where the pixel data starts. So once I had solved that problem, it was fairly straightforward to fix the rest.

One other thing you may have noticed in the screenshots above is the backgrounds. Artistically, it’s not a very impressive change, but technologically, it signifies another capability I’ve added to my bitmap rendering toolkit: tiling. Prior to this week, each tile of a bitmap had to be drawn separately. But now I can draw one tile over a large area and have it repeat as necessary. This is a feature I’ll be reusing several times from now on with backgrounds, terrain, UI elements, and anywhere else where there’s a repeating pattern. It’s a simple but important capability.

The player flashing different colors is a bug that comes from the recording software I used. Not part of the game. The final obvious addition is that of screen movement. If you look at the gifs from last week’s build, you’ll notice that the screen was fixed in place and the character moved around on it. Now, your character remains on the same part of the screen, and the camera follows him around the map. This means the world is now (seemingly) continuous. You can walk from one map to the next without realizing they’re separate maps.

That said, maps are still each saved as individual files. As I mentioned last week, this is a questionable method. I’m going to work on saving levels more efficiently in the future. That’s a feature that won’t be very visible to the user though, as it’s a feature that only affects the technical side of things. The final change I’ve made this week is changing the game’s coordinate system. This is a fairly technical and uninteresting topic, so I’ll try to keep it simple. In every math class ever, when you’re shown a graph with an X axis and a Y axis, X increases as you go to the right and Y increases as you go upwards. But in computer graphics, the Y axis is reversed. The top row of pixels on your computer is at a Y of zero.

That entire system is fairly inconvenient when you want to simulate a world. When you have to do all of your math while keeping in mind the fact that the entire universe is upside-down, it’s fairly easy to make a mistake. As such, I went through a bit of work to detach the location of something in the game’s world from the location of something on your screen. Now, instead of measuring everything in pixels, everything is measured in meters, and meters are converted to pixels when they need to be put on the user’s screen.

That’s it for this week. Thank you for reading. We hope you enjoyed it!