Makaqu development has stalled. In the worst case, I’ll just have to wait another six months before being able to work on it properly again.
Anyway, an insight into my designs for this engine: When I look at it, and wonder what it should become, I usually think something along the lines of “what if Id Software could have just froze time for as long as they wanted, and kept working on this engine until they were fully satisfied with it before Quake’s release in 1996?”.
First, the hardware and operational system requirements would have to be about the same.
Second, scalability; more specifically, the way Quake was originally designed to handle it. For example, Quake supported high-res modes up to 1280x1024 out of the box, with no need for extra hardware. Its software renderer was intended to be really powerful and efficient, not just a drawback solution. Also, the way it look is not just defined by its limitations, but mainly by its style.
These are some of the main points I keep in mind when working on this engine, and they kind of dictate my design decisions. For example, the sky in Quake was intended to be comprised of two layers of scrolling textures, but the scrolling of one of its layers was quite jerky in the original code, and this jerkiness was almost certainly not intentional, so I smoothed it out. On the other way, Quake (the game) was never originally designed to have fog, so I never thought seriously about implementing it. Makaqu’s poorly-implemented fog is just a random experiment.
Aside from these, there are other guidelines I tend to develop for designing what this engine should become. A broad one I’m leaning towards adopting is to not implement features to override currently working features. Case in point, texture replacement.
The whole point of replacement textures is just to override the game’s original content. To do that, the original content must be somewhere, and must have been designed to be used in the game. And this is why the whole usual concept of “texture replacement” seems flawed to me - because it isn’t really designed to help replacing, but to override the original content.
I’m quite against the idea of the “when going to use that one, try using that other one instead, and fall back if it doesn’t work” approach. This doesn’t look like scalability to me - instead, it seems to be just an extra layer of code that doesn’t actually make the original feature more scalable. And since it doesn’t actually benefit or replace the original workings of the engine, I don’t see much reason to give priority to it.
The same reasoning makes me want to disregard the idea of porting Makaqu to the Dingoo A320. The lack of a floating point unit in the Dingoo would make an efficient port to be non-trivial, and this would hold me back from implementing actual improvements on this engine.
