I ended up putting it in this forum because it mentions "other projects" so...
The gist here is that I have been working on a framework to build 2.5D-esque games in the Godot engine after, ahem, kinda getting a bit fed up with gzdoom fighting me on some stuff I wanted to do. That kind of spiralled out of control into what is almost a new engine on top of Godot... This thread will I guess serve as the place where I babble about whatever I'm doing in it at the moment.
I suppose the place to start is the video I recorded a few days ago showing how things are going:
This all started, as per the last thread, as a UDMF map loader which then generates a whole-level mesh, packs a texture array with the textures the level needs, and spits it all out. The triangle count of even a very complex level is trivial for all but the weakest hardware nowadays, and let's be honest, this is tech from 2022, not 1996. Think of it like a source port for an engine that never existed. As such I am leveraging more modern things like texture arrays as mentioned. Textures are loaded from a wad, the TEXTURES lump is parsed to compose any made of multiple patches, and then they are all pushed into an array of 256x256 textures - if any are smaller than that, they are simply tiled to fit. This simplifies a lot of things, and still preserves the same texture offsets as if nothing had changed (however, non-power-of-two textures are difficult to support using this method). It might seem like a waste, but the memory usage of, say, 500 such 256x256 textures would be ~131 MB for 32 bits per pixel, which, again, is trivial (even a number of raspberry pi models can deal with that if properly configured). This does, however, exclude mipmaps, which is something I'll play with in the future. For right now, it's perfectly fine.
After the basic importer, physics came together easier than I had thought, although my expectations were pretty dire. In the end I kind of hijacked Godot's built-in 2D physics engine and use a virtual 2D rigidbody moving through the world for each object, then line colliders for both impassable walls and crossable lines. Based on the internal height value of the physics controller, it will add and remove collision exceptions with lines it's about to cross over to give the illusion of a full 3D physics environment. Amusingly, this means objects are also infinitely tall until I add exceptions for them to cross each other, just like the good old days.
Relatedly, raycasts were a bit of a chore too. I am using more built-in functions to help out, in this case the convenient plane raycast functions to get hit points for walls and floors, stepping through sector-to-sector to find out how far the cast can travel before it hits something impassable. Object collection is a separate step after that, and is based on the cell map (basically a ripoff of doom's blockmap), a grid of 256x256 unit cells that hold information about what sectors and objects are inside of them for better ability to look up nearby objects, etc... The line from the world raycast gets a subset of cells that it crosses and checks the objects in each one for overlaps, then either returns the nearest or a list of all overlaps depending on the input params.
Let's see, what else... sector movement is still very early but any sector that will need to move or change in some way is excluded from the global mesh generation and instead is spawned as a dynamic sector, which can have its mesh updated at any time on request with any updated underlying sector data. Mercifully though, due to how the physics stuff works inside, it kind of Just Works with the physics when sectors move, barring if one moves out from under something too fast.
Now... as for the implementation of level interaction itself, I am not sure. It's a bit of a difficult problem because I am trying to work within the confines of existing level editors, but that has some inherent issues. Limited numbers of arguments for line and thing specials for example. Hell, it would be nice if I could just name things based on strings instead of having to rely on memorizing numerical IDs. I am damn tempted to fork an existing editor and twist it to my purposes, or even worse, start my own. But that's getting a bit ridiculous. But I think my ideal would be a set of general purpose logic objects that can be chained together right in the editor, rather than any sort of text scripting. I have no issues with scripting myself but I always like being able to just lay out a set of objects to make stuff work and not have to leave the editor at all to do so. That could make the decision by the engine as to what sectors to mark as dynamic easier as well - if a door needs a door controller object in its sector(s), then it's very simple.
Oh and I made a console! Which I am very proud of.
But anyway, that's all for now I think. I've probably missed a few things, I'll post about them as they come to mind. I just figured this would be interesting to some nerds out there, and I think it helps to write stuff down as I do it too.
