It's starting to take some good shape now and mosey towards release status. Still a while off, but it seems eminently stable with baseq2 functionality. Once again I'm using the Speed Demos Archive material for testing of functionality and stability.
Today I did a very worthwhile adjustment to how R_LightPoint works. I'd always smelt a rat about this function, suspecting that the colour it returned was not quite the same as the correct surface light colour, particularly with respect to dynamic lights. Then it occurred to me that - as I've shifted lighting to something more similar to Classic Quake and am therefore storing all lightdata in main memory - I could just read the data from the final generated lightmap texture instead of having to rebuild it from the raw lightdata. This means that I can skip the addition of dynamic lights in R_LightPoint and have a precise result. This is definitely something that's going into the main DirectQ codebase.
I've also added in stencil buffer shadows (if you have a stencil buffer available) for a nice improvement to the default shadows. The "gl_shadows" cvar can use floating point values between 0 and 1 to control the intensity of the shadows.
"scr_showface 1" will replace the "Red Cross" health icon on the sbar with the face picture for your chosen skin. I've hacked the sbar code slightly to shift the y position up by 4 units and also to add another 4 units between the stat icon and value. It might not be 100% mod compatible, but how many mods actually customize this in such a way that it would be affected?
"gl_modulate" and "intensity" are still hanging around, but the way they work has been changed. Only values of 1, 2 or 4 are allowed, and if you set them to anything else they will just pick the nearest of the legal values. They now take effect immediately, and the behaviour of gl_modulate with alias models has been changed slightly so that it's the same as the behaviour with the world (it was different in stock ID Quake II).
"gl_monolightmap" is still there but now has no effect. The whole R_BuildLightmap function has been cleaned out of the various optimized cases; what may have been required in order to get it running on a P133 in 1997 no longer applies in 2009, and cleaner, simpler code is definitely preferable in this case.
Anisotropic filtering ("gl_anisotropic_filter") has been added. The old gl_texturemode, gl_texturesolidmode and gl_texturealphamode cvars are still there but no longer functional. Texture filtering is now either anisotropic or trilinear.
Hardware gamma has been added, using the old "gamma" cvar to control it. It works the same as in DirectQ but without the independent red/green/blue sliders, as I want to keep things simpler for this one.
The correct video mode formats supported by your adapter are enumerated and made available. Integrating the refresh DLL with the main engine helped a LOT here. As a consequence of this, the first time you run the engine it may start up in a weird and unexpected mode (it will however always respect the value of vid_fullscreen). It makes an effort to adjust to a supported mode if your cvars are outside of the ranges. I might change the cvar names and supply a safe mode (something like 640 x 480 windowed) as a default, just to avoid this first-time-startup issue.
DirectInput has been added for the mouse. I know a lot of Quake players prefer to use DirectInput, so now it's in Quake II also. Use "m_directinput" to control it, default is 1. If it seems too fast or too sluggish, use "m_diboost" to apply an additional scale modifier (default 3).
I'm going to add in BMP/PNG/JPG screenshots, just like in DirectQ. These are so easy to code in Direct3D that it would seem crazy not to. It will be a string cvar called "scr_screenshotformat", with a default of "tga".
External texture support might be added. I'm in two minds about this one; it seems a nice feature to have, but is it really used often enough in Quake II engine mods? I think I'll do it anyway just for completeness sake.
I might also add in additional external crosshair support; seems easy enough in the Quake II codebase.
I'm also going to see about removing the hard-limit on the number of textures (I've already upped it to 2048, but I want it gone). Texture-wise, proper bilinear filtering (from the D3DX library) is used for resampling (if required), and 8 bit textures are uploaded direct to the hardware in 8 bit + palette format (for faster texture uploads, which roughly evens out the overhead from using compressed textures).
The other main thing is that I still haven't gone back to fixing up the "lost device" case. It's annoying enough to have to do it in the first place, so I'll save it for a time when I just feel like grinding out code rather than doing anything creative or productive.
Think that's all for now.
Wednesday, July 8, 2009
We Have A Fix On Target But No Lock
Posted by
mhquake
at
7:35 PM
Subscribe to:
Post Comments (Atom)
1 comments:
..I'm probably far from the norm, but I only use Quake or Quake2 engine's that support external texture loading. Darkplaces, Quake2Max, or EGL to name a few.
"External texture support might be added. I'm in two minds about this one; it seems a nice feature to have, but is it really used often enough in Quake II engine mods? I think I'll do it anyway just for completeness sake."
Post a Comment