1. 13:35 3rd Apr 2013

    fifthelephant asked: Hi, Just wondering if you know about that the start menu button does not disappear if you're using windows 8 + classic start menu UI? Also, does your version also support increased limits like qbism super8? Thanks!

    I don’t have access to any machine running Windows 8, so no.

    I haven’t increased map limits and some other things in Makaqu because I wanted to keep the engine able to run in the Dreamcast’s 16 MB RAM. But the engine’s basic features (e.g. particles) have naturally evolved to need more RAM, so the Dreamcast port should be discontinued. This will allow me to do a lot more, including increased limits.

     

  2. 16:18 2nd Apr 2013

    Anonymous asked: How do i make a self boot dreamcast disc with 1.6?I dont see a guide anywhere on how to do that.

    The 1.6 version is Windows only.

    The latest version with a Dreamcast port is 1.5.1. To burn it:

    • Extract all the contents of Makaqu’s zip file,
    • Place your PAK0.PAK file and (if available) PAK1.PAK file into Makaqu’s quake\id1 folder,
    • And burn it like any other Dreamcast homebrew disc.

    A good toolkit for burning is BootDreams. It’s pretty easy to use. It can either generate CD images for Nero and DiscJuggler, or burn the disc directly using CDRecord.

    Optionally, you can add CD audio/music tracks to the disc. BootDreams also has an option for that.

     

  3. 15:21 24th Mar 2013

    Fixed the underwater screen warp for widescreen video aspects; now it’s pixel-perfect accurate in comparison to the underwater screen warp of a 4:3 screen with the same height.

    To achieve this I’ve removed all optimizations from the underwater screen code, making it much easier to understand. Now It’s just a matter of re-optimizing it again. The final speed should remain the same.

     

  4. 23:14 3rd Feb 2013

    The crash on the Hipnotic mission pack is caused by the MDL model renderer, both in the C and x86 Assembly versions.

    I’ve started some work on the MDL model renderer. The “metallic” shading was reimplemented as a color shading map table, and I’m going to reimplement the cel-shading outlines. A good point of turning this effect into a color shading map is that now it can be combined with translucency.

    Also added a r_particle_style cvar. Setting it to zero disables the particle renderer, and setting it to 2 turns the particles into squares. This is mostly for people who, for some reason, don’t like round particles.

    The square particles uses the same code used for drawing the round particles, so their position/size/aspect/etc. will also be correct (unlike the original particle renderer), but I’ve also added a limit to the size of the square particles, so their maximum proportions should be the same as of the particles of the original renderer when playing at 320x240.

    The current priority for the next release is to fix bugs, though.

     

  5. 00:41 2nd Feb 2013

    Fixed a couple more bugs already. The main one is when calling the function to remap backwards indexes of the images contained in gfx.wad. This caused crashes when I tried to remap the color index zero from them.

    Now they’re properly remapped, along with everything else that could use the color index zero, so I enabled the code to ensure that the color index zero in the Windows version is always set to RGB values 000000. I just don’t know if this will help to reduce the number of crashes.

    Also fixed a bug that caused the console to fill the whole screen with garbage text when starting to show up.

    I’ll take another look at the calls of the remapping functions, to ensure that they’re not causing problems elsewhere.

    Fightoon is working again in the Windows version, but it crashes if I skip the credits screens too fast. Something is not being initialized properly.

    And the crashes in the C code seems to be caused by the edge clipping functions when used on translucent BSP entities. However, translucent surfaces that are part of the world (such as… well, only turbulent surfaces support translucency in the world’s BSP model) works well.

     

  6. 03:10 30th Jan 2013

    Makaqu 1.6 released

    No Dreamcast version this time.

    There have been many changes since the last version, and there are several of them which I haven’t talked about, but the difference should be noticeable.

     

  7. 18:59 26th Jan 2013

    Custom screen aspect is done, except for the underwater screen effect. The difference on that effect is hardly noticeable thanks to the aspect of the 3D rendering itself being correct, so I’m not giving a priority to fix it now.

    A bunch of problems have been fixed in the console background, and now it scales perfectly with anything. I’ve also implemented dithering on it, using an algorithm similar to the one I’m using elsewhere, but with a different solution for the clamping: Individual non-dithered drawing loops for the top, left, right and bottom areas of the console background where the dithering should be clamped, plus a dithered non-clamped loop for the rest. It’s very fast.

    By the way, I’ve run two “timedemo demo1” benchmarks of the Windows version, one in a binary compiled with the x86 Assembly code, and one in a binary compiled with the C code only. The x86 Assembly version is just 6.66% faster. I guess a good portion of that speed can be gained back on the pure C code by optimizing the MDL model rendering, because.it’s far from optimized.

    And when running the pure C version, the “timedemo demo1” benchmark at 800x600 in 16:10 aspect returned a difference of about 0.8% between my dithered and non-dithered drawing functions. Less than one percent! That’s much faster than expected.

    And as indicated, I’ve got Makaqu to run without the x86 Assembly code again. The problem with the pure C version of the code is in the rendering of translucent BSP entities. I’m going to fix this, as well as making sure the Dreamcast version is running well, and then the 1.6 version should be ready to be released.

     

  8. 21:44 20th Jan 2013

    Widescreen support is almost done. All that’s left to do is to fix the alignment of the rendering rectangle (r_refdef.vrect) for viewsizes below 100%, and also to fix the underwater screen warping effect.

    The underwater screen warping code is kinda hard. Scaling the waves according to the screen aspect should be easy now, but I’ve still not figured out how to change the phase of the waves according to the position of the rendering rectangle. So, for example, if you pause the game and the viewsize is below 100%, the position of the waves will change if you enable the classic status bar background and change the size of the status bar, because doing so changes the position of the rendering rectangle. It’s a nitpick problem that doesn’t really affect the gameplay in any way at all, but it’s the kind of thing I like to fix.

    And in some bad news, if the Windows version is compiled without the x86 assembly code, it crashes as soon as trying to load any map. The same crash also happens in the Dreamcast version, so it should happen in any port I try to do, including a Linux one. And the main reason why I want to do a Linux port is to use tools like Valgrind to debug Makaqu. There’s a Valgrind port to Windows, but I’ve heard it isn’t stable yet. I’ve also heard very good things about the latest versions of Microsoft’s Visual Studio, but I haven’t looked into them yet, and I don’t know if its Express versions also includes the same debugging features.

    I’ve got a lot to learn about debugging. Besides the C version crashing, the regular x86 assembly version also silently crashes in my Windows XP machine too often (by simply disappearing from the screen, from the taskbar and from the proccess manager), and there’s a specific point in the second demo of one of the official mission packs where it crashes when looping through all demos for the second time. Trying to run Fightoon also results in a crash as soon as trying to load any map.

    I’ve been trying to figure out the causes of those crashes for months, while fixing all other bugs I find, and so far had no luck (or skill). So, the 1.6 release should still be prone to some crashes.

     

  9. 20:40

    The dimensions of most of Quake’s textures are multiples of 16 texels, because of the way the software renderer was designed. However, the textures of the names of the skill selection portals only contains 24 columns of texel data, because the brushes of those portals were sized to only use that much.

    The rest of the texel data contained in those textures has no use, but it does prevent my padding algorithm to work properly in them, so a column of wrong texels is displayed at the edge of the surface.

    So, the solution was to properly detect those textures (through a combination of their names, width and CRC), and copy the last column of valid texels to the first column of invalid ones when loading the map. It isn’t the cleanest solution possible, but it does have zero impact on the rendering performance.

    The cleanest solution that wouldn’t slow down the rendering would be to either replace such textures in the map’s BSP file itself, or to support replacement textures, but replacement textures are beyond the scope of Makaqu.

    I did include an ammo box with a fixed texture in most (if not all) versions of Makaqu’s PAK10.PAK file because some hardware-accelerated engines also featured the same kind of problem, but the filesize of that ammo box is also much smaller than the filesize of the start map, and replacing the start map wouldn’t fix the problem in custom maps that uses those same buggy textures.

    The only thing left to do in this dithering filter (besides implementing it on MDL models) is to pad the skybox’s textures, but since I’ve also got a number of other changes to do in the skybox code, I’ll probably leave the skybox non-filtered for now.

     

  10. 02:47 13th Jan 2013

    And finally, a comparison of the high-quality turbulent texture feature against the original turbulence algorithm, this time with the dithering filter applied.

    Now the quality difference is easier to see in static screenshots, but the impact on the framerate is even bigger, so I didn’t bother implementing high-quality turbulence for translucent surfaces.

    I’ll leave this high-quality turbulence feature in, but there will be no menu option for it; just the r_hq_texture_turbulence cvar.

     

  11. 02:33

    image: download

    SPR models followed a similar but simpler approach. Their textures were also padded, but instead of drawing anything on their padding area, all the pixels of their padding area were set to be transparent. For this specific screenshot, I’ve painted the padding area white, so you can see it. The padding of the bubble on the lower left of this screenshot is darker because that bubble is in a darker spot. Something else that may be noticed in this screenshot, as well as in a couple of the previous screenshots, is that the game is being displayed in widescreen. This is something I’m still working on.

    SPR models followed a similar but simpler approach. Their textures were also padded, but instead of drawing anything on their padding area, all the pixels of their padding area were set to be transparent.

    For this specific screenshot, I’ve painted the padding area white, so you can see it. The padding of the bubble on the lower left of this screenshot is darker because that bubble is in a darker spot.

    Something else that may be noticed in this screenshot, as well as in a couple of the previous screenshots, is that the game is being displayed in widescreen. This is something I’m still working on.

     

  12. 02:19

    With my method, a bug appeared on surfaces using textures that shouldn’t be tiled. By tiling such textures, the pixels of the edges of surfaces using them will display texels that belongs to the opposing edge of those textures, but their opposing edges weren’t made to match.

    To fix this, the first step was to detect which textures should be tiled, and which ones shouldn’t. A quick glance at the original Quake’s textures revealed that in most cases, textures that should be tiled have a square shape, while its non-tileable textures are usually shaped as rectangles.

    The second step was to repeat the index of the texels of the edges of the texture instead of wrapping them around, thus expanding the edges of the texture on the padding area instead of tiling them.

     

  13. 01:51

    Thanks to leileilol, I’ve found out this Quake 2 source code review by Fabien Sanglard, which includes code for implementing a dithering filter on regular BSP textures. Copying and pasting the code was easy, but soon I noticed there were several ways to make a better and faster equivalent.

    The first thing to notice, as can be seen on Fabien’s article, is that that algorithm offsets the texture in one direction and clamps it in the other, to make sure that wrong texels are not drawn to the edges of the surfaces.

    My first thought was to find ways to eliminate the offset (to make the code faster and to align the pixels properly), and soon I figured out that this wasn’t enough to properly align the dithered pixels around the center of their non-dithered equivalents: the dithering kernel also had to be rewritten. However, by rewritting the kernel I essentially allowed the dithering algorithm to also use negative indexes for the texels, thus requiring the texels’ indexes to be clamped twice, for both positive and negative values.

    So, I started thinking about how to eliminate the clamping completely.

    There were several drawing functions where I wanted to implement the dithering. Regular BSP surfaces, turbulent (water, slime, lava, portals) BSP surfaces, sky BSP surfaces, and SPR models. Particles doesn’t need it and MDL models still have a lot of changes to be made to their rendering and drawing functions anyway.

    When implementing it on turbulent surfaces and on sky surfaces, I’ve noticed that clamping the texels on them was unnecessary, since the indexes of the texels of those surfaces are always bitmasked, and the masking wraps the indexes around on both ways. So, these were easy.

    The indexes of the texels of regular BSP surfaces, however, are not bitmasked, because those texels comes from the surface cache, which is not tiled. Textures may be tiled into the surface cache, but the surface cache itself isn’t tiled.

    The surface cache is generated by tiling a texture into it, while simultaneously applying a non-tiled lightmap on the final texels. So, my solution to avoid clamping was to expand the surface cache, padding it around its edges. The padding itself was made by wrapping around the texture (to ensure continuous tiling with other surfaces using the same texture), and by duplicating the lighting of the texels of the edges. This whole process of padding the surface cache was the hardest part, due to a number of small details I’ve had to learn.

    Padding the surface cache requires using more RAM, so I’ve limited this to “mipmap level 0” (which, as fas as I know, means non-mipmapped) surfaces, which are the ones closer to the camera. This also means that mipmapped surfaces (levels 1 onwards) can’t use my dithering algorithm… but they don’t need it anyway! So, mipmapped surfaces are still drawn without dithering.

    That resulted in a dithered 3D drawing algorithm that is properly aligned, and smoother on the edges of the surfaces. And while doing that, I’ve reduced this algorithm to just two sums per pixel (plus a few other operations on the beginning of each span), significantly reducing its impact on the framerate.

     

  14. 00:02

    Now, to explain the D_DrawZSpans bug.

    The first picture shows the rocket launcher really close to a opaque turbulent surface. For the next pictures, textures were purposely turned off.

    The second picture shows what happens when turning the camera just a bit to the side, to make the rocket launcher go behind the turbulent surface a little more.

    The C version of the code, however, does behave correctly.

    This bug only seems to happen on opaque turbulent surfaces, so it doesn’t seem to be intentional. Also, I didn’t check to see if it also happens in the 1.3.1 version of Makaqu, which is really stable.

    But it does show that there is something different going on in the x86 assembly version of that function. It may be a bug, or maybe my code for turbulent surfaces is sending wrong data to it, or maybe both things are happening.

    There’s something else to be noticed in these screenshots: The C version of the code has been optimized a lot, and has gotten about as fast as the x86 assembly version. I’ve figured out how to optimize it, and now it outputs 64 Z-buffer pixels on each roll of its inner loop. So, removing the x86 assembly version shouldn’t make much difference, if any at all.

     

  15. 02:35 5th Jan 2013

    Right now, the lack of updates is actually because there are too many to write about in a single post. Some big changes are being implemented in the engine, and I want to talk about them in detail when they are done. For now, just two cents:

    1. Instead of 1.5.2, the next release will be numbered 1.6.
    2. I suspect some of Abrash’s x86 Assembly code may have small bugs or innacuracies. His x86 Assembly version of D_DrawZSpans (the function which draws the depth buffer of BSP models) behaves differently (i.e. buggy) from the C version when rendering solid turbulent surfaces in my current code. Things like this may explain why the Dreamcast version of Makaqu 1.5.1 is so much more stable than the Windows version.

    This doesn’t mean that my code is bug-free, but is a significant reason to either drop the x86 Assembly code or fix it. And since learning x86 Assembly isn’t on my list, dropping that code (or at least removing some parts of it) is something that may happen in the future.