I'm holding off on a lot of the bigger plans until I see what falls out of the 1.8.4 release, but I just thought that I'd like to give an indication of some kind as to where you can expect to see things going in future.
Some of these are potential candidates for a hypothetical 1.8.4b (or 1.8.5).
- Luma handling. DirectQ uses a different luma blend mode to most other engines, which in some cases - depending on the textures you use - can result in a multiply by 0 for the final colour. The trouble is that there are a LOT of released texture packs that assume that the "standard" (but actually incorrect for native Q1 textures) luma blending mode is used, which can cause things to look bad. In the spirit of not crusading off a cliff I'm going to do something about this; most likely switch to the "standard" mode for external textures.
- Gamma handling. DirectQ currently applies the same 0.7 gamma as GLQuake does to native textures, but does not apply it to external textures. This has needed to be fixed for quite some time now, so it will be soon.
- Window creation. Since I have now unified the splash screen with the main app window, a bug of sorts has emerged. I use CW_DEFAULT as the initial (on creation) window size and position, but that's wrong - it should be CW_USEDEFAULT (the "cw" in CW_DEFAULT refers to the floating point control word, not CreateWindow). This isn't currently causing any problems - I suspect that MS anticipated that people might do this and have code to check for it and correct it - but it's still wrong. My oops.
- Renderer restructuring. Those of you who have downloaded the 1.8.4 code will see that there are remnants of an initial attempt at integrating the HLSL VBO paths into the fixed pipeline VBO paths, but that it didn't get finished. I now have a much better idea for this whole thing which involves treating interaction between the renderer setup and the actual rendering as a protocol, and using Quake's well-defined protocol functions for building the lists of items to be rendered. They can still be very lightweight lists, but the gain in flexibility will be quite good (it should get faster too).
- Performance. Believe it or not there is still ample extra performance to be extracted out of this. One plan is to put the map into a static VBO (instead of building it dynamically per frame), the render restructure will give a few more frames, and there is colossal room for improvement with both MDLs and particles. Dynamic light uploads are also a bigger bottleneck than they need be.
If you have anything on your own wishlist for 1.9, now would be a good time to mention it too. It's fair to give advance warning that requests involving per-pixel lights, bumpmapping and/or real time lights will be quite politely ignored. :)
7 comments:
Is there going to be fog in 1.9?
First big thanks for your work, you give us a solid and fast engine.
About the feature requests, i have a fews, in importance order :
- it's very difficult to type in the quake console without an English keyboard. It would be nice if the console match the os layout such as QWERTZ (GER) or AZERTY (FR) and not only QWERTY.
- in the menu, adding the ability to bind each weapon individually instead of editing manually a config file.
- and finally to complete the crosshairs customization, the ability to change their size, like darkplaces is doing with the cvar crosshairsize.
I hope my list is reasonable. :)
scr_crosshairscale 0 to 1 (or above) - might not apply filtering too good, but it's there. ;)
I can make this so that crosshairsize also works.
Good suggestion regarding the keyboard layout; must see what APIs are available for this.
Fog will come back sometime for certain, just not certain when at the moment.
Not too certain about the weapon bindings - the way Q1 handles this with impulses might cause mod incompatibilities.
Damn it... if only Bethesda would release the source code for Fallout 3. Oh, the optimizations you could make to -that!- Your Quake Engine, DirectQ is just so FAST, and oozes with class and style; no bugs, no crashing, superman-fast speed, and all in a nice, neat single 'exe' file.
Fallout 3, even with the latest patch applied, is CRASH! Oh, it's running now, I'll do some exploring... CRASH! Start it up again; just let me knock off this pesky Raider with VATS... CRASH!
Start it up again, more of the same... CRASH! Holy coding crisis MH, it's crashed AGAIN and corrupted my display system; I'll need to reboot.
Arrggh! Beg Bethesda to give you the source code for Fallout 3, PLEASE!
Coranth: That would never, ever happen, to our chagrin. For what it's worth, Fallout 3 has to do a *lot* more than DirectQ, but Bethesda's always been in the strange position of making decent-to-great games on uneven tech.
Here is a short list of stuff I'd like to see at some point in time..
Most of it is in the realms of proquake convenience stuff that you probably don't care too much about, but hey.. you asked for a wishlist so here it is ;)
bug-fixes:
- texture filter bug (using numbers works ok tho)
- HLSL + AA = fail?
- green armour flash when picking up yellow or red
gfx:
- transparent gunmodel (v_weap) ala qrack
- nearest neighbor (point) filtering on 2d stuff
(text & crosshair)
convenience:
- rcon (vital for admins)
- teamscores + matchtime in hud (ala proquake)
- copy console buffer to clipboard command
- longer chat messages
- show_speed (movement velocity)
- iplog/identify
- synthetic lag (ping +n ping =n)
- quick funky chars from console
(ala proquake/qrack (CTRL/ALT/SHIFT combo's))
- cycle command (ala fitzquake)
@Peg: So long as the ProQuake "convenience" stuff isn't too hacky and evil I'm largely amenable to doing it. Unfortunately a lot of it is, but let's see how far we can go before I start to feel like I've been covered in slime. ;)
Post a Comment