The next one is going to add two new submenus off the "Options" menu: one for "ProQuake Options" and the other for "User Interface Options". At the risk of going back to the old overloaded menus, let me explain what's happening here.
"ProQuake Options" is a gathering place for all options that I've ported from the ProQuake code. It's convenient to have them all together, and it makes it clearer what the purpose of these options is. Right now it's probably looking a little bare, but hopefully it will grow over time. Thinks: this one could probably alternatively move to Player Setup as it's mostly Multiplayer-specific.
"User Interface Options" is one that is not strictly necessary, but it does give better organization and grouping. I'd always found it slightly weird that these options were split between the Video menu and the Effects menu, so now they've been pulled together. Doing this also gives a little more onscreen real estate for anything I might want to add to either menu in the future too.
The old "Sound Options" menu is still Missing in Action. I've a stated intent to port Quake II's sound code, but at present it's low on the priority list - mostly because what I've currently got works just fine within the bounds of what ID Quake did. It will happen though as soon as I get the necessary impetus together, and at that time Sound Options will reappear.
This gives a much more sensible grouping and if you want to configure something via the menus it should be immediately obvious where to go: Video, UI, Sound (in the future), Effects or PQ (which may yet move to a more logical place).
If you've already set up your config the way you like it none of this is relevant to you, of course.
I've more or less finished the MDL work, and it's working nicely. The code did turn into a slight mess as it grew, so I'm thinking that it probably needs another pass over it to complete a final clean-up. In the end I went with the Fitz method of handling viewmodel interpolation; it's not perfect but it is the one that relies on the least assumptions and as such is least likely to cause trouble in the future. I do have another plan cooking for this, but it's going to require a little bit more work, so I'll hold it off for a few releases.
There are some other things I want to work on too, but I'll leave talking about those for later.
2 comments:
Out of strictly morbid curiosity, why not ioQuake3's sound code?
I'm not really familiar with the Q3A sound code for starters, and I'm completely unfamiliar with what ioQuake3 may or may not have done with it. That's going to translate to a potentially large-ish increase in time to port it, debug it, fine tune it, etc.
Quake II's code, for all that it's clunky and old, is at least reasonably close to Quake's, while containing a few extra critical features, to make the job relatively painless.
Post a Comment