Console Completion

I'm going be away for a while, so no updates for a few days.

Here's the latest - enhanced console completion, featuring an output (in ASCII order) of all matches, indicating whether each is a command or a cvar, as well as the ability to cycle through them with subsequent presses of the TAB key.



I've also done some tidying up on the external texture loader, removing some "just to get it working" code (i.e. passing everything in as qbooleans rather than using proper flags), cleaning up which textures get mipmapped and which get repeated or clamped.

I've decided to adopt the Darkplaces standard for sprite/alias skins. It's what most people are used to, and it makes sense - when you consider that there is a "s_light.spr" and "s_light.mdl" in the ID1 progs directory, it's amazing that others persist with leaving the ".spr" or ".mdl" out of the name.

I might do a fallback to attempting to load without the extension, just for compatibility.

I'm also toying with the idea of environment-mapping fullbrights.

Save/Load Game System Updated again!

So it wasn't a wrap, I had two excellent suggestions which were trivial to implement, as well as a few new ideas of my own, so here's the new version.



The name of the BSP and the date/time of the save are displayed in the info box, there's a counter, and pressing Delete or Backspace will delete a saved game.

I also added support for padding out (and copying in where characters are meant to be consecutive) to external charsets. Still haven't found an external charset that suits me though, but I'll keep trying. This one looks OK ish.

A few other features: I don't allow custom names on game saves, mostly because it's easier not to, but also because it messes with the sorting (currently descending name order, the last step is to sort by date). I've extended the auto-generated name to be able to support over 1,000,000,000 new names though - if you run out of names you're likely to have bigger problems than not being able to save your game!

Progress and next steps

I've cleaned up the whole listbox code and made it much more robust now, so I think I can call this one a wrap. It also supports PGUP, PGDN, Home and End keys.

Started messing with underwater fog - the usual MHQuake correct underwater fog colour will apply. I've rewritten the code for this in a test engine I did some work on before this one, so it will be reusable here. It's a fairly neat method that does away with the whole awkward "world volume" system I had in the past. After some thoughts about how it works, I've decided to fog the entire world if the player is underwater, otherwise translucent water surfaces can look very odd. I'll probably use a different fog equation for overwater than I use for underwater, though.

This will be a nice break before I get back to working on the whole menu system, which will be a major undertaking, as I'm deeply unhappy with Quake's menus as they stood in the original.

New Load/Save Menu

Here it is, then:



As I suspected, the listbox code is coming back to bite me a bit. I'll need to work over it and clean it up.

Save/Load Game System

The new save/load menu interface is almost done, all that's missing is a bit of tidying up in the UI. Key features are:

• Removal of hard limit on number of displayed save games: the only constraint is how much memory you have in your system.
• Display of additional info about each save game: Time, Kills, Secrets and Skill.
• Display of save files in a scrollable list box.
• Enhancement of the load and save commands to display current save files if issued with no args.
• Enhancement of the load and save commands to support long file names and spaces (this one was a no-brainer to implement).

The listbox code is a bit messy at present, it works fine and seems bug-free, but I wouldn't like to come back to it in 6 months time and try figure out what's going on.

Mapshots have been added, but the code to draw them has yet to make it in. Interestingly, my new FOV system (written to support widescreen monitors) means that I can take and render mapshots at 256 x 256 and still retain the full FOV from the native monitor size. Meantime, here's something else from the menu I'd been meaning to bring back into my codebase for a long time:

Video Startup Issues

I'm working off a hunch here, rather than any verified data, but it's my belief that with Quake 1 most people will 95% of the time run in one of two video modes:

1. A full-screen mode that matches the resolution and colour depth of their desktop.
2. A windowed mode that's sufficiently large enough to get a good resolution, but still with the title bar and other widgets accessible.

By this logic, forcing the startup to 640x480x16 fullscreen unless otherwise specified has no place in a modern source port. If you have a 1280x1024x32 monitor, you're going to want to use it's full capabilities, especially with an old game that's capable of going like lightning on any modern hardware. And the non-technical person doesn't want to mess with command-line options, they just want to double-click the icon and get the thing running.

MHQuake will automatically start at your monitor's full resolution and colour depth unless you specify otherwise. It doesn't even bother to do a CDS test, as you're already running your monitor in that mode. The old -width and -height options are still there, but they've been modified to allow you to attempt any resolution: there is no vid_modes list any more. Similarly, -window on it's own will pick a good-sized window that's still within the constraints of your desktop size (typically the "common resolution size" one step below what you're running at, although this can be different for widescreen laptop monitors).

I haven't implemented resolution switching as I don't believe it's worth the effort: setting resolution is a one-time-only operation for most people, and as I said above, it's virtually always to a full-screen full-sized mode. This is all about making it easier for people to run the game, rather than putting technical issues in their way. This isn't 1997 anymore, and we no longer have to wrestle with workarounds for antiquated hardware with inadequate video RAM - even a previous generation Intel Integrated chip is capable of running MHQuake at close to 60 FPS full-screen full-size.

Coolness in the MHQuake Texture Loader

The new MHQuake texture loader is a biggie. It's orders of magnitude faster as it no longer needs to test if it can open each type of texture file (in each potential directory) before loading it. Instead, what it does is scan through the game directory at startup and build a list of all textures found in (nearly) all subdirectories (it excludes /sound, /save, /scrnshot and one or two others). This is a reasonably quick one-time only operation, and uses the Windows API to query the filesystem, rather than attempting an fopen () on the file itself.

When loading, it then looks up the original texture name in the list and returns the path at which the external replacement can be found, as well as the file type so that it can call the correct image loading function. The list is unsorted, and a brute-force search is used every time, but for 40-50 textures per map the hit is negligible. I might move to a sorted list with indexes for the first character of the name at some time before release, as doing it properly seems the correct thing.

The real beauty of this approach is a subtle side-effect that was unintended when I first wrote the loader. MHQuake no longer cares where you put your textures - it can quite happily load them anyway. If you're paranoid about Tenebrae compatibility, go ahead and put them in /override, or put your skyboxes in /env, /gfx, /env/gfx, /gfx/env, /textures, /textures/env, or even /elephant, and MHQuake will detect them and load them without having to painfully crawl through all possible paths. (I can also do recursive '.link' loading, although why you'd want recursive '.link's is something I have a hard time imagining...)

Why there is no Linux version of MHQuake

Reason one

Reason two

Reason three

Nuff said.

Thoughts on Lumas

There's no doubt that using lumas in your engine is the good and correct thing to do, as it restores a lot of the old ambience from software Quake that was so badly missing in GL. However, most people get the rendering path for lumas wrong, and use something like (Texture * Light) + Luma. This means that in cases where the light is very low, the luma looks fine, but in cases where the light starts getting stronger, the luma will begin to intensify beyond what it should be.

One solution would be to hack the texture by subtracting the luma texels from it. This can be either done by the texture artist, or by the engine at load time. It's not ideal though: if you depend on the artist, you still have to deal with cases where it hasn't been done; whereas doing it in the engine just stinks of Bad and Wrong.

The QRP folks have used a different approach, producing Lumas that are very faint. Some are so faint that it hardly seems worth bothering to have them. However, for better or worse, that's now the standard.

What MHQuake does uses two different methods. Firstly, it converts the luma to greyscale by simply setting each of R/G/B to the brightest of the 3. This gets a good level of intensity that looks well with all lumas. The second thing is that it restores the correct equation to the rendering path. I'm running it as something like (Light + Luma) * Texture. This is a bit more fiddly to code for (as you can't easily skip over cases where there are no luma), but it looks correct and works very well with everything.

Currently working on...

The whole savegame/loadgame system is being overhauled. I'm removing the limit on the number of save games you can have, removing the restriction on file names (I intend to allow any legal file name, including spaces!), and adding in a scrolling listbox (which is proving enormous and genuine - non-sarcastic-here - fun to work out the logic for) to display the savegames, together with Time/Secrets/Kills/Skill info, hopefully also save time (in your local time format), and a mapshot in the background of the menu.

So far I have the save game file scanning and storing completed, and am starting to get into the display code. I could steal it from elsewhere, but where would be the fun in that?

I forgot to mention that I also converted the project from Visual Studio 2003 to Visual C++ 2008 Express. I had the 2003 project set up so that it would convert to 2008 without any errors, but had a runtime crash with it. I fixed that recently, so I was able to complete the conversion. This is doubly nice, as you can now compile MHQuake yourself without having to pay any money for a development system, and you don't have the headaches of setting up 2005 Express to work with Win 32.

The MHQuake Development Blog

I've started this to track progress on my new MHQuake engine. It's better than using a properly hosted site for now, so this will be the place to go for updates and info. It's taken a while to get this engine properly off the ground, but it's now in a position where I'm satisfied with a lot of the core engine functionality (most of which is totally behind the scenes), so it's time to give more solid info.

What I have so far includes:

• Increased internal limits.
• Removed several internal limits completely.
• Full game changing (including conback).
• Enhanced video startup.
• Enhanced external texture support (completely removed any dependency on specific directories, as well as the need to test opening different file types - it's a thing of true beauty).
• Enhanced "map" command.
• Enhanced "playdemo" command.
• Enhanced MP3 support (should also work with any audio type you have a codec for, but this not tested yet).
• Somewhat different main render path (fullbright colour support has been totally overhauled to look and work exactly like software Quake).
• Z-Fail Skysphere/Skybox (like my posted tutorial).
• Amazing Revolving 3D HUD.
• New blood and death effects.
• Different translucent water.
• Completely rewritten memory management (greatly simplified too).

As you might gather, there's still a way to go. I haven't even started on a particle system yet, and it requires 4 TMUS! (Alternate render paths will be forthcoming.) But even if released in it's current form, there's enough new and different stuff in here; just not readily or easily visible.