Here's the playdemo/timedemo menu. Using the "Command Mode" option will switch the menu between playdemo, timedemo and record modes. You should note that the mapshots only appear if you have r_automapshot 1 set, or some valid mapshots already saved. Otherwise you'll probably just get a big dirty Q logo.
I seem to have a bug relating to my water surface shader on certain NVIDIA cards. I'm not certain how widespread it is, if it's a Windows 7 driver thing, or whatever, so I'm thinking of just leaving it be for now. It's not a crashing bug, just visual appearance.
Aside from all that, I think I'm coming close to a release soon...
Sunday, May 31, 2009
Posted by mhquake at 11:51 PM
Been a while since we had a new screenshot, so here's a work-in-progress of the new demos menu that will be in 1.6.
I had previously put out a request for desirable features for such a menu, but have decided that for this release what I'm going to include is a pure demo menu, and not enhancements to behind-the-scenes demo functionality.
Posted by mhquake at 1:33 AM
Saturday, May 30, 2009
Quite a lot has happened since the last update list, so here's the next batch:
- Moved alias model interpolation back to CPU (lighter vertex submission).
- Fixed "dying throes" interpolation bug.
- Added Maps menu.
- Restored offset centerprinting from "lost version" somewhere around 1.2 or 1.3 (...long story...)
- Removed limit on number of menu cachepics.
- Removed limit on number of alias verts (fixed vert loader so it only allocs the number of verts needed too).
- Fixed crash bug with game changing followed by map load; made progs loader significantly more robust in the process.
- Added optional (on by default) "classic" sky warp (ripped from darkplaces) - use r_skywarp 0 to revert to sky sphere warp.
- Added r_skybackscroll and r_skyfrontscroll cvars to control sky scroll speed.
- Split out warp surfaces to a new options submenu and added sky warp control options.
- Moved skies from fixed functionality to HLSL (there is no fixed functionality left in the engine now).
- Added 8 new custom crosshairs (some good, some rubbish).
- Added skybox loading to menu.
- Fixed multiplayer map selection so that it works off the same map list as the maps menu.
- Added TAB autocompletion to "map" command.
- Added TAB autocompletion to "loadsky" command.
Posted by mhquake at 4:20 PM
Wednesday, May 27, 2009
The DarkPlaces sky has now moved from immediate mode to a vertex and index buffer combination. Index buffers are fun, especially if you try to figure them out from the SDK documentation. Basically you need to do a
mentioned virtually NOWHERE in the documentation. In other words, it's buried in the description of another completely different member function.
Is it in the general discussion on index and vertex buffers?
Is it in any of the tutorials?
Is it in the documentation for
Is it anywhere else someone might think of looking?
No, no, no and no.
It's in the "Reference" section for the IDirect3DDevice9::CreateIndexBuffer Method. A place where someone who's starting off and looking for a quick and dirty leg up will NEVER look. Way to go!
I've ranted about the quality of this documentation before, but this one is worth raising as a classic example of what's wrong.
Skybox loading has gone into the menus now, which has been fun. It's not often that something totally new and weird and different has a chance to come up, but this was the first time I've ever needed to declare and use a
Regarding the DarkPlaces sky, this is now the default sky rendering mode for a number of reasons. Reason 1 is that it most accurately replicates the old classic software Quake sky warp, without the heaving and buckling effect that GLQuake suffered from. On it's own this would be a good thing, but reason 2 is for performance. Because I was able to multitexture it and draw it in a single pass, with use of an index buffer and a very lightweight vertex submission, it should run faster than the DirectQ sphere.
The old DirectQ sphere remains, of course, and can be reverted to by use of the r_skywarp cvar or the appropriate menu option.
All sky options (including skyboxes) use the same Z-fail technique, so geometry positioning is preserved as it should be.
Next I'm going to investigate the Q3A cloud layers and see if I can borrow anything worthy from those. I have something of a feeling that these could run faster still, and if so would be an acceptable tradeoff between "looking like software Quake" and performance. If so, they will likely become the new default.
Posted by mhquake at 10:33 PM
I've finally moved the skies from fixed functionality to HLSL; this was the last outstanding item, and there's no fixed functionality left in the game now.
In one way it seems a pity to be HLSL all the way, as a lot of people with older laptop cards are out of the picture so far as running DirectQ is concerned. However, the major advantage it provides is a much cleaner execution path with considerably less state changes. The way Direct3D handles TextureStageStates (the equivalent of glTexEnv commands) is something I'm still finding difficult to cope with; I'm sure it's perfectly logical and reasonable (and it looks far more flexible than OpenGL) but it's incredibly verbose and hard to see from the documentation what the exact effects of a particular state change are. I really should write a sample application to let me play with them.
For the record, the minimum required 3D card seems to be an Intel 910 or thereabouts. This is a 3 or 4 year old integrated laptop card, with no Hardware T&L and vertex shaders emulated in software (Direct3D does that and it runs quite nicely, as fast as fixed func), so it's still a low minimum requirement.
Pixel Shaders 2.0 are required; no getting out of that. I suppose in NVidia terms that's a GeForce FX 5 series, I don't know what the ATI equivalent is.
I mentioned it briefly in passing, but it's worth highlighting again. This release will finally give you the ability to specify your own custom shaders (I use FX files) for the engine. You can pop them in Quake\ID1\Shaders and they'll be used instead of the hard-coded defaults. Because of the way the engine is set up you will have to supply the same parameters, same inputs, same technique names and same numbers of passes, but what you do from there is completely up to you. The hard coded defaults are always distributed with the source code, so you can copy them from there and use them as a baseline.
Posted by mhquake at 11:41 AM
That was a pretty exciting and eventful block of work today. First of all I fixed the game change followed by map load crash for real, by allocating the various progs lumps in their own distinct buffers, and by making the progs header variable a non-pointer. These are all cleared to NULL on a disconnect or memory free event, so that it's possible to trace any attempts to read from them or write to them which shouldn't be happening (there are none, but it seems like the right thing to do).
I remain convinced that it's C runtime library changes that caused it; it didn't happen in 2003, even using the multithreaded libraries that came with that. Anyway, it's all history now, and the progs loader has an extra layer of robustness that it didn't have before, which is nice enough in itself.
Then I ripped off the DarkPlaces sky scroll. This is optional but enabled by default, as it more accurately replicates classic Quake. I've also added some more cvars to better control the sky. I'm going to stick all of these into a menu somewhere (must also add skybox loading to this menu).
While doing the latter I was quite amused to discover that the DarkPlaces R_Mesh_Draw function almost exactly replicates the parameter list and order of Direct3D's DrawIndexedPrimitiveUP (which I'm currently using). Direct3D adds a primitive type at the start and omits the firsttriangle parameter, but otherwise they are identical. One would almost wonder...
Posted by mhquake at 2:24 AM
Monday, May 25, 2009
I fixed the new-map-following-game-change problem. It seems as though the memory block allocated for the progs.dat is occasionally overrun; anyway, adding some extra padding to the end of it resolves all that.
This didn't crash on VS2003, so it's definitely 2008-specific. Either 2003 silently allowed it, or 2008 does Magic Stuff (TM) behind the scenes which causes it to suddenly become a problem.
I would switch to an alternative environment at this stage, but they're all very poor. There are two features in any IDE which I absolutely must have in order to be productive, and they are (1) proper intellisense/autocompletion and function parameter hinting, and (2) being able to tuck away all the little side-panels and other gubbins, and also bring them back when required without having to go delving into menus.
I've tried Code::Blocks, Dev-C++ and CodeLite (which seems to be a Code::Blocks spin-off or wannabee clone) but none of them satisfy my requirements. There is just too much visual clutter on-screen, resulting in a considerably smaller editor pane, and when even a simple "printf" call doesn't provide parameter hinting, I don't hold out much hope for API calls.
Eclipse is something I would be interested in trying out, but from the look of the screenshots it's going to fail on requirement (2), and I personally loathe Java enough (spend 10 years supporting the havoc caused by over 1000 client installs and you will too) to have serious second thoughts about even downloading it.
So c'mon folks, if Microsoft can get something as basic as this right, you can too! If you wanna bad-mouth them, at least grow a pair and show that you're better, eh?
Posted by mhquake at 11:18 PM
I seriously never thought I'd be writing this post, but it appears as though the Visual C++ 2008 blues are striking again. Summary: the project compiles and runs fine on 2003, with the very latest version of the source files. With the exact same source files, the 2008 version goes down in flames when switching to a new map after a game change. This crash does not happen on 2003. Very same source files.
OK, so what's the cause? As the source files are identical (have I said that enough times yet?) and fresh builds were done each time, the cause of this problem lies in the differences between the two environments. And what is the single major difference that 2008 (and 2005 before it) has? Enforcing use of the multithreaded CRT, that's what.
Anyway, I'm going to try a few things, but I certainly won't be spending too much time on it; if it's not resolved over the next day or two I'm reverting back to 2003 (again!)
Posted by mhquake at 7:41 PM
Sunday, May 24, 2009
No DirectQ this weekend as I've been listening to a lot of my old records following a recent turntable upgrade.
I love the sound of vinyl records, and have been gradually assembling a setup that will allow me to hear them at their best. If you go to certain "audiophile" sources, you'll hear a lot of rubbish about how the vinyl sound is all about "warmth", "bloom", "softness", and so forth. Likewise, there are those who in all seriousness believe that the minute you put the needle down you'll hear a great big CRACKLE CRACKLE CRACKLE and will have jumps and stuck needles to contend with forever more. All nonsense.
The vinyl listening experience is about dynamics, about precise attack and release of notes, and these are factors which CD just cannot replicate, owing to signal quantization at the lower volume levels (where most of the critical information above 10KHz lives). The difference is that vinyl sounds like it is going to make you genuinely boogie.
While I have what could be considered a fairly high-end setup, this is something that even the cheapest plastic turntable can do. Spending the extra money is worth it though, and will get you sound quality that CD just cannot touch.
As for the frequency response, the graph below shows a frequency analysis for a recently release remastered CD (the red line) and the same track copied from vinyl (the green line) in my current setup:
Notice the almost total lack of difference. The CD is a little louder (at the expense of compressed dynamics), but otherwise they are virtually identical. The vinyl has more energy in the midrange and lower treble, the CD has more energy in the upper treble.
While getting to this stage I've realised that the critical thing is to go for source compnents that are as neutral as possible. Frequency adjustments should come from the amplifier and speakers (preferable the speakers only) but keeping the source as close to neutral as you can will result in a much better end result every time.
Meanwhile, back to DirectQ...
Posted by mhquake at 12:49 PM
Thursday, May 21, 2009
Today I've been mostly testing out the Windows 7 RC. Quake-wise, it seems reasonably compatible...
I did a fresh install of stock ID Quake from a "Quake: The Offering" set as a baseline, then initially fired up WinQuake, which worked almost perfectly first time. There was some slight palette corruption on occasion, but this is documented in ID's "readme", and the solution is to issue a "bf" command at the console to clear it (must add that to DirectQ...)
Stock GLQuake (0.95, the version on the CD) was a mixed bag. After renaming the opengl32.dll in the Quake folder, I launched it, and it died almost straight away. I then decided to try out windowed mode, which worked perfectly. Following that, I went for a fullscreen mode with some application compatibility settings, but it continued to die. Fullscreen dying was expected, and even XP has issues with stock GLQuake, but I really didn't expect windowed mode to work.
The next test was a modified engine, so ProQuake was the first choice. Both fullscreen and windowed modes worked perfectly. qRack was the next candidate, and it went down in flames, failing both Windowed mode and Fullscreen mode. Then I remembered that it needs a PAK file, so suitably embarrassed I went and set the right command-line switches and everything worked beautifully. Suggestion to R00k - automatically load that PAK file from the qrack gamedir, please? Then I did DarkPlaces, both the SDL version and the standard version, and both worked fine. It did however give me an "Internet Communication" alert from the standard Windows Firewall - what's going on here?
Of course I couldn't resist adding DirectQ to the engines tested, and it passed with flying colours. It did however require a DirectX update, owing to a missing DLL, so it seems as though the version of the Direct3D 9 runtimes that ships with Windows 7 is out of date (it was also out of date on Vista). MS should really resolve this as a lot of people running older (but not that much older) games on Windows will be burned by it.
I think I'm currently compiling to the March or April 2008 version of the SDK, so it seems a little unreasonable to be shipping a runtime that's over a year old.
Back on topic, both DarkPlaces and qRack gave me an "Unknown Publisher" alert when I ran them; none of the other engines did.
Performance-wise, stock GLQuake and ProQuake sucked, very badly. We're talking about 50-ish FPS in Windowed mode, and not much better fullscreen (ProQuake only). Fiddling with vsync options seemed to have no measurable effect. DarkPlaces came next best, averaging in the high hundreds. DirectQ was a little faster, and qRack was the only one to exceed 200 FPS. I didn't time WinQuake. I suspect that DirectQ would have been fastest of all if it wasn't using 64 bit lightmaps, but this seems a more than fair tradeoff to me.
Bear in mind that we're talking about a machine that's close enough on 5 years old here, so overall things look reasonably well.
Posted by mhquake at 9:35 PM
Wednesday, May 20, 2009
We march on!
The "dying throes" interpolation bug has been FIXED FIXED FIXED! Especially happy to have gotten this, as it's been present in every engine I've ever done, right back to the start. I don't know what other people are doing, as nobody else seems to have ever acknowledged this as a bug - must be something weird, wild or wacky about the way I'm coding it. Anyway, did I say that it's FIXED?
The solution I used was to reset ent->pose1 and ent->pose2 both to 0 if an entity wasn't updated last frame, then check for this when drawing and reset the interpolation cycle if it's happened (but don't do it on viewmodels).
I've been visiting interpolation code quite a lot recently, and will probably do so again before I release. It's gone back to the CPU now (was run in a shader), and an aborted attempt at spline interpolation was made. In the end I decided that the data mangling required to get it was just not worth the effort, and that standard Q1 linear interpolation is just fine, thank you. Then again, we all though no interplation at all was "just fine, thank you" back in 1996, and look where that stands today.
A "Maps" menu! Finally added it in, pleased at that too. The aborted GL engine from last year used a bubble sort to sort map names; this one uses STL sorting so it's more friendly to people who like to have several thousand maps (it's almost 20 years since I last wrote a sort routine myself - don't expect me to bash out a QuickSort...!) Some brain-dead code in there from the evolution of the menu, but it's not that big a deal right now.
While doing this it's become obvious that my menu listbox code needs some pretty radical overhauling. It's not going to happen for this release, but I'll be bearing it in mind for some time in the future.
I've also taken the opportunity to restore some code from my notorious (to me, at least) "lost version". This happened somewhere around 1.2 or 1.3, where I had made a batch of really good updates, then switched to a different PC for a while and forgot to bring the updated code across. These updates had never been in any subseqent version until now.
Overall, 1.6 is shaping up to be the best release yet. I was very fond of the first two releases, there was something really nice and primitve/ramshackle about them, but this one just feels really really solid and together, far in excess of any prior version. It must be all of the ID1 map testing I did for the MHColour utility, and it seems as though it's definitely worth doing a full run through ID1 for each release.
Still on Visual C++ 2008 Express. Intellisense bugs are rearing their heads quite regularly now, but at least MS have acknowledged that intellisense is badly broken in this version, and are doing something about it for the 2010 versions (moving it to SQL Server Compact, from what I read). I'm planning on staying with 2008 for now, as the engine is stable (some of the multithread stuff I did for Direct3D also resolved the MT CRT issues I had previously), and I want to be able to work on a free (as in beer) platform.
Posted by mhquake at 7:54 PM
Tuesday, May 19, 2009
- Added centerprint logging (scr_centerlog - need to change this to a standard cvar name - default on).
- Cleared out gl_triplebuffer and vid.numpages.
- Adding fading to centerprints and console notifications.
- Fixed bug where brush and sprite static ents were not rendered unless a regular brush or sprite ent was also rendered.
- Tightened up on textbox input for content names and locations menu.
- Added customisation of base save and screenshot names.
- Exposed screenshot format cvar via content menu (TGA/BMP/PNG/DDS/JPG support)
It's been nice to expose that in the menu, and it's been even nicer to allow customisation of the base screenshot and save names (also exposed in the menus, of course). Meanwhile, some more serious bugs have been trampled on. The static entities one was present for the last few releases, but I had never realised it until I noticed that certain entities were missing while testing MHColour out.
By the way, even more small but significant speedups have been obtained. It occurred to me that since the leaf(s) containing a static entity have already had R_CullBox run, there's no need to run it on the static entities themselves. Another coupla percent gained.
Posted by mhquake at 7:45 PM
Monday, May 18, 2009
As promised, here's the deal so far...
- Added XInput code for XBox 360 Controller.
- Added FX loading from file (in gamedir/shaders, built-in shaders are available in source code folder).
- Removed messy "Apply" stuff from menu code.
- Added ability to show/hide/enable/disable menu options.
- Changed video mode selection from instant to requiring an "Apply".
- Added loaders for several "enhanced" particle types ("enhanced" system not implemented yet).
- Further updates of particle system, replaced types with individual particle parameters.
- Made new Multiplayer game config menu more tolerant of run-time game changes.
- Removed dependency on ID1 naming convention from viewmodel muzzleflash frame interpolation hack.
- Removed frame interpolation from bolt models.
- Fixed crash on changelevel where you give yourself the lightning gun before changing level.
- Fixed r_lightmap cvar.
- Removed efrags system (replaced with similar - but more efficient - system).
- Ported trace system from light.exe source code.
- Fixed rotating va buffers disappeared somewhere around 1.2
- Added proper bilinear resampling for texture upsizing.
- Made Heap_TempAlloc more robust against recursive calls.
- Worked around occasional weird crash in Draw_CachePic.
- Removed dedicated server functionality.
- Fixed memory leak in S_LocalSound.
- Fixed shader loading from resources (badly broken).
- Moved project to Visual C++ 2008 Express.
Otherwise a lot of good and useful updates, but mostly behind the scenes. I'm particularly happy with what I've done with particles, even though an actual "enhanced" system isn't in there yet (I had one but I removed it; some dregs - like textures in the exe as embedded resources - remain). Also, the most recent round of bugfixes have resulted in a much more stable program.
No news of a release date yet, but work continues.
Posted by mhquake at 11:29 PM
Current versions of DirectQ support running as a dedicated server, and it's nice to be able to do it, solely because it's a feature of the original engine (even if broken in stock GLQuake). But I'm wondering - why would you run this engine as a dedicated server? Most changes are client-side, and those server-side changes of importance (massive relaxation of entity limits being the primary one) require a compatible client to work correctly.
Also, continuing to support a dedicated server means that a lot of baggage is retained in the code, and for new features one has to give consideration to how they should be handled on a dedicated server. It adds more work to the testing cycle, which means that things take longer to get done. All in all, I'm really starting to lean towards seeing continuation of dedicated server support as something I don't need.
So I think that I'm going to be removing the dedicated server from release 1.6; I don't really see any overwhelming reason for it to stay. I can't think of any circumstance under which anyone would seriously want to use this engine in particular as a dedicated server.
If I was going to make a dedicated server today, I'd take the stock code, bump the limits as high as they can go (while maintaining protocol 15 compatibility) and rip out any code not used by the dedicated server. In other words, a pure dedicated server executable, that can be tuned and optimised for that particular purpose.
Posted by mhquake at 5:03 PM
Friday, May 15, 2009
I'm already getting requests for the next release, which is a good thing in a way (shows that there's interest). The current list looks kinda like:
- Restore the options for the various elements that are or are not used as colour sources (torches/fullbrights/other textures/lava/slime/etc).
- Add an option to intensify the colours somewhat (like in previous releases).
- The ability to enter a list of textures that should not generate colour sources.
So it's looking as though there will be a next release at some time, and probably soon (as none of these are particularly difficult). However, I'm making my stand now on the LIT pack - it stays as it is, and I won't be releasing any more versions of it. I want to avoid potential confusion that may be caused by having too many LIT packs around, and one is enough. The more subtle colours in it are a deliberate choice on my part, because I want it to appeal to old-schoolers, and I've even started leaning in that direction myself.
It's so fast to regenerate LITs anyway that I don't really see the need for more than one LIT pack release. In fact, depending on your connection speed, it may be even faster to regenerate them that it is to download a new pack. Nothing to stop someone else from generating and releasing their own pack, of course, but I'm done so far as that is concerned.
As for the program, I'll likely be generating a new SF project for it, and posting updates there. I'm still unhappy with what I see as the up-it's-own self-righteousness of certain aspects of SF, and the primitive crudeness of others, but it'll do in a pinch. Another option is to check out the current crop of free hosts, which I haven't done in a while. I prefer to stay unaffiliated to any of the major Q1 sites, nothing against them (they do a great job) but I've been on QuakeSrc in the past and - while it was good - being unaffiliated means that I can have freedom to do what I want when I want how I want without feeling anyway obliged. ("It's not you, it's me", in other words).
Posted by mhquake at 11:58 PM
After having exorcised the recent WinMHColour 2009 marathon, I feel like I've gotten a new lease of life for the engine itself. This is in part because I was using it for testing the generated LITs, and started getting a slight itch to work on a few bits and pieces in it.
So 1.6 - which has been underway for a few months now - is starting to take shape again. I don't think this is going to have anything radically new. Most of the work I had done so far has been behind the scenes stuff, with the exception of a half-finished particle system. In fact I'm leaning towards leaving the particle system disabled for the new release and continuing with tightening up behind the scenes.
No word on a release date yet, it's still too early. As soon as I have a substantial change list done I will be posting it, though.
Thursday, May 14, 2009
Wednesday, May 13, 2009
Tuesday, May 12, 2009
I've resolved the light-green slime problem by multiplying the derived green colour by 1.25 until it exceeds the derived red colour. This is done for all slime textures where red exceeds green. It will cause trouble for mods where this is intentional (e.g. using a slime texture with a name beginning in "*slime" to represent some kinda corrosive red substance), so it's not a perfect solution, but this unfortunately is one case where correct ID1 behaviour has a higher importance than correct wacky mod behaviour.
I want to test out smaller multiplication factors (such as 1.125 - larger look bad, already tested), and maybe modify the colour balance for torches a little, before calling it a wrap, but it's really looking like the program is done!
Next step after that is generating the set of ID1 LITs and making everything publicly available. All in all, I'm happy with the result.
A release 2 might happen; I'm thinking something along the lines of fixing up Hipnotic rotating brush weirdness and maybe adding Hexen II support for that one.
Posted by mhquake at 8:19 PM
Monday, May 11, 2009
I haven't resolved the slime problem with the "brghter contributes more" approach, so I'm thinking that a colour histogram seems to be the right road here. Viewing the histogram for the problem texture seems to indicate that there is useful data there; in addition, it also seems valid for other textures.
Meanwhile, here's the episode 2 test run.
Posted by mhquake at 9:23 PM
Some selected highlights.
The main thing that needs fixing is the "light green" slime - the colour of this texture averages out as an "olive brown", and it really shows. Not nice. I had some previous code that caused brighter colours to contribute more, so I may well resurrect that.
Otherwise I'm pretty damn pleased with this.
Posted by mhquake at 8:01 PM
Sunday, May 10, 2009
Phew! Today I added sprite models as colour sources, so all is pretty much complete. I'm finally back to the stage where I think I just need to do a trial run of generating LITs for ID1 and seeing how things go.
Here's e1m2 - compare the colouring around the slipgate with that in the other screenshot a few posts back, and see the improvement.
Posted by mhquake at 9:58 PM
Saturday, May 9, 2009
This isn't a serious project, but just something that I partially worked on while doing the most recent round of MHColour development. In order to best determine how textures should affect light colours, I needed a quick and easy way of getting at the data in the textures. Dumping them out to disk is the most obvious solution, but I was intrigued by the idea of seeing how much of a basic WAD Editor I could get up and running in a short time.
I have TexMex and MipDip, but I'm fairly dissatisifed with what I see as lacking functionality in both. The WorldCraft texture viewer is great for quick searches and filtering operations, but sometimes I just need to get at the exact specific amount of RGB in certain areas of a texture, and having all of this present in a single tool would have been a very useful thing indeed.
.NET is very much my "go to" platform for casual GUI work (although pure Win32 is a lot more of a viable option that one might think), and Visual C# 2005 Express is all I need to do anything (I've certainly never noticed any shortcomings in it). But one thing .NET seems to go out of it's way to make difficult is working with pure binary data. There is an underlying assumption that the data will come to the application in an already well-structured format (e.g. from a database), but when you have a raw binary stream to deal with, and you're formatting the data structures yourself, things get very awkward very fast.
The single biggest stumbling block is not being able to do arbitrary casts between pointers to different data types. There are ways around, but this is something that I've taken for granted for close on 20 years now, so it's a struggle every time. It's such a cool programming environment, and platform, that's otherwise simple, fun and a joy to use, that when one hits such a problem it's almost the equivalent of a kick in the face.
Anyway, in the end any further work on this proved to be unnecessary, as I had resolved the issues otherwise, so right now I just have a bunch of C# code for opening and reading a WAD file. But I'm still sufficiently intrigued by the whole thing that I might make it my next project after I release MHColour. I think there's a definite requirement for a cool WAD utility that lets you do interesting things with the texture data. But if I do write this, I think I'll be putting the heavy-lifting raw binary data code into a C++ DLL rather than going a pure .NET route.
Posted by mhquake at 9:21 PM
Thursday, May 7, 2009
Unlucky for some, but not for me.
I think I've resolved the matter of light textures without fullbrights in a manner that seems satisfactory to me. Obviously it would require a full lighting and testing of every map ever made to ensure that there are no remaining aberrant cases, but (equally as obviously) that's not realistic. There are always going to be some freakish cases which a general-purpose doo-dah such as this cannot be properly applied to.
The one item which I've just remembered that I've neglected for a good time is sprite model loading. You may remember that I had mentioned before that light colours for torches are now derived from the actual texture of the model used, rather than being hard-coded in (to keep mods which insist on having blue torches happy). Well I need to do this for sprites also; ordinarily I wouldn't bother, but ID1 uses a sprite for one of it's lights, so it's a requirement.
For now though I'm taking another short break - the days when I used to work on this until unreasonable hours of the morning are well behind me. The program may take longer to arrive, but I get to keep my sanity and health - a fair trade, if you ask me.
Posted by mhquake at 8:35 PM
Wednesday, May 6, 2009
I've resolved the problem with slipgate lights mentioned previously. Everything now looks beautiful and subtle, but not so subtle that you'll need to look carefully to see the colour. Rather it's a case that you can plainly see that it's coloured, but the effect isn't overpowering. Sweet.
The last thing I want to do is address certain textures that don't contain fullbrights but which should cast coloured lights. The ones I mean by this are those which have light patterns in them, or certain window textures (like the circular red windows in some maps such as e1m2 or e1m5). A previous version used the texture name as a guideline here, but this is not viable, as texture names need not indicate their content.
One thing you should definitely note is that a major part of how well (or otherwise) it works in certain cases is down to entity placement; most specifically brush models. A brush model will be lit in the position it is placed in when the map is generated; if it is subsequently moved to another position when it's entity is spawned the lighting of it will look wrong. The elevator to the nightmare entry in the Rogue start map is a good example here. I'm not sure whether this is a problem for me to fix or for the mapper/engine author to fix.
Another interesting effect is the red glows around map exits (and certain other areas). These come from deathmatch only brush models which are removed in SP games. However, the WinMHColour program doesn't know (or care) about this, so once again we get some false colouring happening.
The last interesting case (for now) is hipnotic rotating brushes. I don't know how these work, only that they're ghastly, but the effect here is that the brush is just not coloured at all.
I don't really consider any of these to be bugs of my program (although I could resolve the first one by calling the entity spawn function and moving the model surfaces to the correct location before lighting), but rather quirks of the primitive technology available at the time Quake was designed. A more modern solution would be to use some form of realtime lighting to resolve all of these in a very clean and easy manner.
Posted by mhquake at 9:03 PM
Time for one of my rants before I pick things up again.
I've previously had a bit of an attack on Firefox 3, but now I'm going to discuss a few related points in a more general manner. I remember back in the old days of the mid to late 90s (and even earlier), when resources were limited and software had to play nice. It certainly wasn't universal, but back then it seems as though most programs were somewhat more careful about how they consumed resources. A PC with 32 MB of RAM could only be so useful, and if there were a veritable metric fuckload of background tasks and agents running it would very quickly be brought to it's knees.
Sometimes I yearn for those days back. I have a reasonably beefy PC at work which is completely unusable for 10 minutes after I switch it on, owing to all of the rubbish that needs to load and do it's thing before it even lets me click on the Start button. I have a Java-based development toolkit that requires 2 GB RAM, and I'm not even certain that I'm getting any worthwhile extra functionality for the investment. FF3 has gone to virtually everything running off of interpreted scripts, meaning that even on a reasonably modern dual-core machine it can take whole minutes to load.
This is all time wasted before I can do anything, and it's my time. I remember when going to the magic 64 MB mark would make everything almost instantaneous. I'm fairly deeply suspicious that a lot of development houses have moved to a line of thinking that says "resources are more abundant now, garbage collected platforms mean that we can be sloppy, so let's be really really REALLY sloppy". End result is that things are now far worse than they ever were back then.
Another specific case. If you have a Windows PC with Avast 4 AV on it, try checking how much memory is used in the Performance tab in Task Manager. Now stop all Avast services and check again. Yup, Avast - a free AV that is applauded for being "lightweight" - uses the best part of 100 MB. I don't care if most of that is swapped out and likely never used, that's not the point. The point is that on an old 32 MB machine, you were unlikely to have 100 MB including the swapfile. Why does it need to use so much? What worthwhile extra functionality does it give me for those 100 MB that it couldn't have given me before? Or is it just a case that the developers are sloppy about their memory management?
Posted by mhquake at 11:23 AM