Makaqu

Looking in retrospect, Fightoon’s models are really awful. The legs are nice, but that’s all about it.

The hands are horrible. Making some good hands was a nightmare. Except for the thumbs, none of the fingers could be modelled individually, due to performance constraints. A pair of hands with all fingers modelled individually would require roughly the same amount of triangles as rest of the whole model (back then I even knew the exact number in my head, as I used to calculate that a lot). Using the skin texture to simulate individual fingers didn’t work well at all, as there’s no way to make the lines in it match the width of the cel-shading outlines, and as there’s no way to make the gouraud shading work separately for each finger. Normal mapping and per-pixel lighting is how modern engines solves this, but this isn’t an option for this engine.

Still, I think that with enough optimizations and more modeling work, we could get either individual fingers working at an acceptable framerate, or at least more natural-looking hands.

The chest and the shoulders have a truckload of problems. The fact that they doesn’t look natural enough was caused by the difficulty in animating them well. The amount of mobility that a real human shoulder has is insane, and replicating that without making half of the poses become blobs of distorted triangles is difficult. I could have taken the easy route and modelled the arms separately from the chest, like many official Dreamcast games does, but I didn’t want the characters to look solid like robots when animating.

The feet. Their shading doesn’t look well in a number of positions. I’d hate to spend more polygons in them to fix this, but maybe that’d be necessary.

The models’ heads are too experimental. They were developed enough to be functional, but they lack a lot of polishing to become of quality. The mouth lacks some more triangles to be really expressive, the eyes have a lot of complications of their own, and the overall shapes of the heads still looks too alien (they looked like lizards when that project started).

Overall, what I’d like is to have models with enough detail and functionality to animate and look well at any resolution, needing only a few more triangles in some key points to smooth their shape out at higher resolutions.

I have some ideas in my mind for making a different game, and will need to develop these things further.

Thinking about long term plans for this engine, the idea of doing an Android port is looking promising. There are a few Quake ports for Android already, so it’s not unknown territory, and the hardware specs for Android devices seems to be raising really fast, so it shouldn’t be hard to achieve a good performance.

Also, the idea of distributing original games powered up by this engine through the Android Market seems highly interesting.

I’ve found a little silly bug preventing some loops to be unrolled, so the ordered dithering code got a bit more optimized.

On the other hand, I’ve found a way to make the dithering scale well in any resolution. Doing so reverted most of the speed gain from the unrolling, but the point is that there’s no need to keep multiple ordered dithering algorithms anymore, which makes things simpler.

The smoothness of the ordered dithering can also be customized now, which means it’s possible to go from completely sharp to really very blurry. I don’t know if this could be useful for anything, and it’s not in my plans to implement yet another cvar in the engine just for this.

I’d really like to implement ordered dithering in most of the drawing subsystems of this engine. I haven’t got any solid plans for this yet, but I’ve got a feeling it may be really easy to implement it in the 2D image drawing subsystems, due to the way I’m planning to rewrite them.

Now, to the 2D image drawing subsystems. The basic idea is to make them automatically integer-scaled in the screen, and to have some kind of alignment going on to make up for different video aspects. A container system may also probably be needed, but I don’t want to make the 2D image drawing subsystems too sophisticated unless this makes things simpler in some other way.

Having everything (except the console background) integer-scaled by the same factor should allow for some heavy optimizations of the ordered dithering in a simpler way.

I’ve taken a quick glance at the console dithering code again, and re-enabled some lines of code that makes it extra smooth. Seriously, it can be hard to distinguish between that dithering and hardware interpolation. The thing looks so beautiful it makes me want to implement and enable it by default. There are a couple problems though.

First, complexity. This extra dithering looks crap in resolutions lower than double of the dimensions of the source image. In cases like that, the previous dithering algorithm looks better. This would imply in the code having at least three different scaling algorithms (non-dithered, dithered, and extra-dithered), and it just feels like the kind of thing that would make the code needlessly more complex and therefore harder to maintain.

Also, if all of those methods gets implemented, it would be best to make them independent for each axis - which means that stretching a 320x200 image to 360x400 would be done using regular dithering on the Y axis, and extra dithering on the X axis. Note that dithering (at least in my implementation) is done perpendicularly to the stretching, so the dithering for the horizontal stretching is done vertically, and dithering for the vertical stretching is done horizontally. Allowing the user to disable dithering completely should also be possible.

Second, speed. The current code is too slow to be actually useful, and I’ve got to find ways to optimize it for speed. I love how PrBoom does this kind of ordered dithering insanely fast, but after trying to figure out this functionality in its source code for a while, I figured out that trying to devise my own optimizations may eventually consume less time.

All of this is too much work for a non-essential feature, but now that I’ve gone halfway through implementing it, it would feel like a waste to just throw it away.

Anonymous asked: What is the current stack needed for compiling Makaqu for Dreamcast? I'm looking for the correct devkit version, libs, as well correct Makaqu version.

Makaqu 1.3 is the latest working version for the DC, but it has a bug in the DC controller’s x axis. To fix this, open the file common/src/menu.c and change the lines

qboolean dont_bind[256];
char    *bindnames[256][2];

to

qboolean dont_bind[K_NUMKEYS];
char    *bindnames[K_NUMKEYS][2];

And you’re done.

As for the devkit, you’ll need to install the DC Dev ISO R1, and change some things in it. I’ve detailed most of the process, if not all of it, in some previous posts in this blog.

Some good news. I’ve got a dedicated CRT monitor for my european Dreamcast, and I’ve also got a SD card reader for it. This should help a lot when I get around to developing for it again.

I should be able to easily dump screenshots, logs, config files and VMU data, as well as running a lot of Quake mods from the SD card for testing. Previously, disc space was a huge concern when testing, since it’s really hard to include a lot of mods on a CD-R and still get it to accommodate a lot of sessions on a multi-session disc (some of the CD-Rs I’ve used for testing got over 30 sessions burnt into them).

Running from a SD card also gets the nice benefit of not stopping the CD audio when loading data. However, this is more of a benefit to players than to developers, and I don’t think SD card readers are common amongst the majority of DC homebrew enthusiasts, at least not yet.

Anonymous asked: I'm not sure how to set it up so I can use it, I try to activate it and it says that it's missing files

Try using the version 1.3 (on Windows) or 1.2 (on Dreamcast).

Besides this, which files are missing? All you should need is to add the file PAK0.PAK (and optionally the file PAK1.PAK) from your version of Quake to the ID1 subdir before playing it.

Sorry for the late answer.

Dithering becomes really easy to implement once you get the hang of it. However, even though the current algorithm implemented in Makaqu works well, its results aren’t as smooth as they could be.

The main problem lies in the textures’ borders. Skyboxes are comprised of a single tri-dimensional texture split into six different images, so ideally the error diffusion for each of those images should also be spread over to the adjacent ones. Since this doesn’t currently happen, some edges of the textures of the skybox may be not smoothed out properly enough to be unnoticeable.

Also, the current algorithm wraps the error diffusion around the image’s left and right borders, so some colors on either side can get wrong. This can be noticed in this image, where this bug generated a greenish line over the  mountains at the right of the sun.

Fixing the second problem is easy, but fixing the first one is tricky. Makaqu accepts textures of almost any size for its skybox, which is a feature meant to save RAM by allowing usage of lower-resolution textures in some sides of the skybox. Due to this, if the error diffusion is to be spread through the adjacent images of the skybox’s texture, it will also have to be scaled.

This scaling of the error diffusion, along with the need to read the dimensions of every image in the skybox before loading any of them, can make the code quite more complicated than it is.

Other sorely needed goals are to support dithering on run-lenght encoded images, and to optimize RAM usage during the conversion, by loading only the currently needed pixels of the original image into the RAM for processing, instead of loading all of them at once.

After that is done, the loading of 8-bit indexed color images should be improved. 8-bit color images that uses a palette different from the game’s one should be converted to 24-bit color and then re-converted to the game’s 8-bit indexed color palette, with dithering applied.

All of this is just for skyboxes. I haven’t thought of any other usage for this code yet, but I know that using it on anything that needs transparent pixels or lighting would bring up several other problems that would have to be fixed.

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.

I’ve got the renderer partially working again. BSP scenery isn’t textured, and no entities are showing up, but the viewmodel is working correctly.

This happens because I’m reenginering the engine to make it set all rendering paths for each entity upon parsing their updates from the network messages. This will make it simpler to add new effects and rendering optimizations into the engine.

So, I’m currently having to trace the code from any points where entity updates are received, to all points where some relevant parts of those updates may change the flow of the rendering code. There’s also a lot of code being rewritten or cleaned up along the way.

Despite the previous post, I haven’t gone back to the 1.3 codebase.

I’ve finally got the engine to compile cleanly again, but the 3D renderer is crashing as soon as R_RenderView_ is called. Time for bug hunting.

I’m thinking about going back to the 1.3 source and re-implementing some of the changes I’ve done since then, except the BSP entity translucency.

BSP entity translucency has proven to require too much reenginering, and I’m not being able to keep up on it. This has keeping me from doing more important things, like getting the Dreamcast version working properly again.