Saturday, October 23, 2010

Some more fixes and tidying up

Console backscrolling has been fixed so that it no longer shoots you back to the end of the console buffer each time a new message comes in. Because DirectQ can use the Home and End keys for command editing (going to the start or the end of the command you're typing), getting these to interact with backscrolling is an interesting problem. I eventually decided that if you're already at the start of the line and you press Home, it goes to the start of the console buffer, and likewise if you're already at the end of the line and you press End it goes to the end of the console buffer.

There may be some usability glitches to be worked over as successive versions evolve. My objective is to have what DirectQ does when the player presses a key be what the player expects to happen. It needs to be remembered here that this includes new and inexperienced players as well as Quake old-timers. The Home/End behaviour for console line editing is what people expect from exposure to Windows edit controls, so changes to that are really non-negotiable.

I've added IP log support. This is really just for the multiplayer crew and is considered a semi-essential feature by them. In the end it proved quite painless, but there are a number of things to be unhappy about in the default (ProQuake) implementation, not least of which is that it grabs 2 MB of memory to itself at startup, and needs a command-line option to configure a different amount. This goes completely against the ethos of DirectQ where there are no memory limits, only the memory that is needed gets used, and the player never has to specify anything on the command-line. Unfortunately it also uses a rather messy tree structure with some special case checking involved, whereas a linear array with qsort and bsearch would have been a lot cleaner and more maintainable. It'll take quite a bit of work to fix, in other words.

I'm also implementing more of the ProQuake messaging system for the multiplayer folks. It'll probably never be really "complete" (just ditching protocol 15 and replacing it with a new extensible protocol based on that would have been preferable; the messaging system as it stands is a mess) but it will build up a little more than it currently is. Unfortunately for this it puts it's tentacles into all kinds of other places in the code, so implementing any part of it is a lot more work than it should be.

Speaking of protocols, I have some more enhancements to the RMQ protocol coming up. I want full floating point range throughout the engine for all coords and angles; there's no excuse for retaining the quantized versions in a modern protocol (these were especially evil for rotating brush models). Client angles are now the last to move over, and this gives a subtle but noticeable improvement in smoothness. I also want time transmissions as milliseconds so as to avoid accumulated floating point precision loss. For the last few versions DirectQ has been a test bed for these changes, and this is going to continue.

I'm coming to more decisions regarding fog handling, but I haven't coded anything yet. I am satisfied however that the visual discontinuity when moving from an empty leaf to a liquid leaf is sufficient to justify changing fog colour. The specific scenario I'm thinking of is when you're in a map with red fog and you go underwater (or when you're in a map with blue fog and you go into lava). There is some interaction with the "v_cshift" command to be considered. In an ideal world this command either wouldn't exist (not so great as there are useful things a modder can do with it) or would be more flexibly implemented. More on that later, perhaps. A way to let mappers specify their own fog colours for liquid would also be useful, but I have no thoughts on that just yet.

How to handle maps where no "fog" key is set is an interesting dilemma. There is sufficient ambiguity as to what the mappers intention is in this situation, not to mention a large enough pre-existing body of work, to ensure that no perfect solution can exist. I'm reasonably happy with my current ideas on this one, which I've outlined earlier, but no doubt there are going to be some who feel this approach isn't satisfactory.

The decision of whether or not to provide a default fog colour for maps depending on worldtype is made: I won't. The reason is that the mappers intention might have been to use the default grey fog, and I have no way of knowing. This is a case where the existence of previous work turns things the other way. The fact that it's possible to stuffcmd a "fog" from QC without specifying a colour strengthens the case for this decision, as it's clear in that situation that the intention is default grey.

I guess all of these underline how poorly thought through the implementation of fog in GLQuake always was, but hindsight is definitely 20/20 here.

1 comments:

=peg= said...

Aaaah, You just earned yourself a few pints of beer from me, cheers! ;)