Working on sloped terrain.
Work Since Last Devlog
- Added some ad hoc debug drawing functions which can be called from game ticks, and defer rendering until love.draw() runs. This is to highlight bounding boxes, print variables, and do other things within the gameplay logic, at the specific code location where I’m troubleshooting. (Otherwise, with the way I have things set up, I’d have to stuff it into the actor’s draw callback, which isn’t guaranteed to be called at the same frequency.)
- Got pass-through platforms working (ones you can walk underneath and jump over, and then connect foot-to-ground). Hibernator had floating platforms, but they were all actor objects instead of tilemap terrain.
- Added a crude engine-level fatal error handler for issues like not being able to parse actor code or map files. For now, it behaves similarly to the built-in error handler, which can also be overridden with a custom handler, but I like the idea of engine-level problems having a separate screen. In the future, maybe it can be modified to have more options.
- Began working on sloped tile collision detection. There are several bugs I’m still trying to fix, mainly related to continuity of movement when passing vertical tile boundaries, but the player does, more or less, move up and down diagonal terrain now. This is a project milestone for me, as it’s something I wanted in Hibernator, but made a judgement call early on to drop in favour of completing more important parts of the game.
- This isn’t in the main codebase, but a first for me: I wrote a simple GLSL pixel shader following this nifty article. I’ll probably step away from it for now — I just did enough to confirm that they work, and to understand how they work in the context of LÖVE — but I’m hoping to eventually use shaders to simulate indexed palette swaps and ramping.
Thoughts
I found an old text file from last August with some notes on how far I was with LÖVE project development. I had yet to finish reading Programming in Lua, was still figuring out how to make the framework play sounds, and was scratching my head over why LÖVE test programs I wrote on Linux appeared as completely white screens under Windows. (It turned out that at some point, LÖVE changed the numeric range for colors from 0 – 255 to 0.0 – 1.0.) The Windows machine was an old AMD APU-based HTPC that I had recently dug out of storage. Running off a single hard drive, it was hideously slow. I installed an SSD, installed Windows 10, connected it to a KVM switch, and it’s a lot more reasonable now.
Back to terrain slopes. I’m making them a property of the terrain def, and specifying two numbers in the range of 0.0-1.0, which represent the height of the left and right sides of the tile (0.0 is the top, 1.0 is the bottom.) When the player’s bottom-center point is overlapping a tile with slope attributes, linear interpolation is used to get a height value from the left and right slope values, using the player’s center X coordinate (with some additional modulo / divide operations to get it down to a number between 0 and 1) as the input. I was going to go by pixel count instead of 0-1, but if the tiles have to be resized for whatever reason, I think 0-1 would be less of a headache to convert. Likewise for collision bitmasks.
I’ve tested a one-tile-high ramp that spans 16 tiles, which is the widest slope I imagine I’ll be using, and it works pretty well (at least when not moving up a whole row of tiles due to the aforementioned glitches). In the image above, it’s the black slope in the upper-right.
I read about a Lua preprocessor on this blog. I have no use case for it right now, but it might come in handy when packaging for different platforms.
- Fix the positioning bugs related to slopes!
- I feel like I’m not doing very good with these weekly planning bullet-point lists lately. I’ll try to put together something more organized for next Sunday.
