Makaqu

I’ve just fixed a problem with the framerate display.

Back when I was coding Makaqu 1.0, I wanted the framerate counter to update faster, so I set it to wait only a half second before updating its value. As a side effect, only half of the frames ended up being counted, so the value in the framerate display from versions 1.0 to 1.3 indicates only half of the actual frames rendered.

In short, Makaqu is actually twice as fast as its FPS display used to indicate.

Well, I can’t deny that discovering this made me smile.

Now that the DC controller’s analog input has been fixed I’m going to polish the current set of features enough to release the version 1.4.

If I recall correctly, the only extra feature that still needs to be added for this version is a small pop-up menu for selecting console autocompletion results. However, I’ll still look through everything to make sure I’m not forgetting anything critical.

There’s a really bad decision I made when coding all previous releases of this engine: I wanted to make it easier for anyone to port my changes to their own Quake engines, so I tried to keep my code changes as minimalistic as possible.

Time proved that this was very pointless, as I can’t recall seeing more than a couple of my changes ported to other engines, despite all the improvements and bugfixes it features. It was also terribly counter-productive, as it kept me from refactoring the code to make it more organized and easier to work with.

For the 1.4 release the code structure should stay mostly the same, but expect it to largely change in the following releases.

The input code should be one of the first to be rewritten, along with the console code. I suspect there may be more undiscovered problems in both, and they’re also much less flexible, abstract and self-contained than needed.

The 2D renderer is also a priority, as there’s a lot of GUI functionality that depends on it, and the current GUI code is also an unspeakable mess.

Also, the 2D renderer should be one of the first portions of the renderer to support hardware acceleration, so that’s another reason for it to be a priority; I need it to be fully functioning by the time I start implementing hardware acceleration in the 3D renderer.

Fixed the X axis bug in the Dreamcast version, it was caused by a memory leak in the dont_bind and *bindnames arrays, which are used by the “Customize controls” menu.

Also, the default vibrations actually seems to be working well with my official Jump Pack; the lack of vibration I noticed before actually seems to be related to a hardware problem in my controller.

On a side note, the fact that the analog stick can control both the menu cursor and the camera angles while the menu is active is a bit annoying. Now when the menu is active I’m probably going to prevent input updates to the camera’s angles, or disable cursor input from the analog stick, or make both behaviors optional.

And finally, in CRT televisions the brown tint for the menu background fading doesn’t look as good as either the dark red tint or the darkening alphamap effect. Since the dark red tint was never used in any official port of Quake, I’m probably going to set the default fading to the darkening alphamap one, at least in the Dreamcast version.

So, now that I’ve got this engine working in the DC again I can confirm something I couldn’t test for before releasing the previous builds: the hard-coded vibration settings doesn’t work for official Jump Packs; they only work correctly on my unnoficial Jump Pack.

For the next release I will test some different settings until I come up with some ones that works on my official Jump Pack. I’m not sure about making the default vibrations fully customizable, but there’ll be at least a menu option to select between the current settings and the new ones.

I had also forgot how smooth this engine plays on the Dreamcast, despite the very low framerate.

About the X axis bug on the analog stick, it seems to be menu-related, as it works correctly if bound from the console. I’m currently investigating this.

dc_vibe.c doesn’t compile under an unmodified DC Dev ISO R1 install:

src/dc_vibe.c: In function `Vibration_Stop’:
src/dc_vibe.c:59: warning: implicit declaration of function `purupuru_rumble_raw’
src/dc_vibe.c: In function `Vibration_Update’:
src/dc_vibe.c:64: error: `purupuru_effect_t’ undeclared (first use in this function)
src/dc_vibe.c:64: error: (Each undeclared identifier is reported only once
src/dc_vibe.c:64: error: for each function it appears in.)
src/dc_vibe.c:64: error: parse error before “effect”
src/dc_vibe.c:90: error: `effect’ undeclared (first use in this function)
src/dc_vibe.c:94: warning: implicit declaration of function `purupuru_rumble’

To fix this, copy
C:\cygwin\usr\local\dc\kos\kos\kernel\arch\dreamcast\hardware\maple\purupuru.c
from a DC Dev ISO R4 install over
C:\cygwin\usr\local\dc\kos1.3\kos\kernel\arch\dreamcast\hardware\maple\purupuru.c

… copy
C:\cygwin\usr\local\dc\kos\kos\kernel\arch\dreamcast\include\dc\maple\purupuru.h
from a DC Dev ISO R4 install over
C:\cygwin\usr\local\dc\kos1.3\kos\kernel\arch\dreamcast\include\dc\maple\purupuru.h

… and open
C:\cygwin\usr\local\dc\kos1.3\kos\include\kos.h
from the DC Dev ISO R1 install, and right after line 62
#    include <dc/maple/mouse.h>
insert this line
#    include <dc/maple/purupuru.h>

Now open
C:\cygwin\usr\local\dc\kos\kos\kernel\arch\dreamcast\hardware\maple\mouse.c
from the DC Dev ISO R1 install, go to line 39 and change this number 6
cooked->buttons = (~raw->buttons) & 6;
to a 14
cooked->buttons = (~raw->buttons) & 14;
so the third mouse button will work.

And finally, start Cygwin, type this command line
cd /usr/local/dc/kos1.3/kos
and then type this one to rebuild KOS
make

That’s all the changes needed for a DC Dev ISO R1 install to compile this engine.

I will include these instructions in the next release, as well as the required files from the DC Dev ISO R4.

Currently doing some research for another project while organizing my system to install the DC Dev ISO R1.

Well, I just found out that I don’t have the previous version of the devkit installed in any of my computers.

All I’ve got is a backup, but gotta install the DC Dev ISO R1 first.

Just tested on the Dreamcast, and Draw_TransPic is really giving a bad coordinates error, for both scrambled and non-scrambled binaries.

Gotta recompile it with the same version of the DC Dev ISO I was using before, to make sure whether this problem was introduced by me, or if it’s a compatibility problem with the latest version of the devkit.

Reordering the palette upon loading to eliminate the backwards ranges between colors 128 and 223 could really speed some things up.

Got Fightoon working again with the current build. The SV_TouchLinks fix I’ve implemented a while ago was causing Z_Malloc errors when loading the railway-bridge stage. What’s interesting is that only Fightoon seemed to have a problem with it.

Anyway, I’ll implement the necessary memory management improvements before reimplement the SV_TouchLinks fix again.

Going to implement custom menu-background coloring now. This, along with some of the other changes, are modifications that were hard-coded in the versions of Makaqu that were used for Fightoon.

After reimplementing all of them the right way, it’ll be time to make the engine more stable.

Implemented:
- r_skyspeed1, r_skyspeed2 (controls the scrolling speed of each sky layer);
- Fightoon’s status bar (sbar 5);
- a version of Draw_CachePic called “Draw_CachePicSafe”, that just returns a null pointer instead of crashing the game on non-existing files.

Also fixed a possible cause of crashes in the drawing function for stippled water.

Implementing the con_enable and con_mute cvars.

The con_enable cvar is pretty straightforward, and con_mute will prevent the console from drawing any messages, including the ones that shows up at the top-left corner of the screen during the game. However, those messages will still be logged into the console buffer, so disabling con_mute will allow the user to read them.

Both cvars will be available at the Developer menu, and con_mute may still be improved a bit.

There seems to be something wrong with the cmdlist and cvarlist commands in Makaqu. I’ve just coded an autoshift feature for the underline character, but it stops working after cmdlist or cvarlist are used.

Besides this, autocompletion was also improved; “u_set” will autocomplete to “menu_setup”, and so on.

Time to track work progress in a blog instead of cluterring forums around the web.

Anyway, I got ten different branches of the Makaqu source from which I have to diff so I can code the new main branch. Working on this now.

Stippled sky is in, it’s basicly stippled transparency for the scrolling sky overlay. This should result in less loss of detail at higher resolutions than the alpha blending from the previous versions.

There’s also a new menu option to control this. HUD options were moved to a new Display options menu, which also received the Framerate (FPS counter) option from the Developer menu. The option to load sounds as 8-bit was moved to the Audio options menu as well.

All in all, the menu system could still be improved a lot, as well as the 2D renderer.