Following on from my last post, here's a few other things that I'm planning for 1.9:
Fog
I got rid of fog in DirectQ because of limitations with newer gfx cards (they no longer support the old hardware fog so you basically have to do your own in shaders now). For 1.9 I'm going to be bringing it back, and - yes - doing my own in shaders. I want to do a really good HLSL fog mode, with nice simple features such as fullbright colours glowing through fog.
I'm not certain what the status of non-HLSL fog is going to be, fundamentally because I'm in a position where I'm unable to test it properly. It might remain absent, it might be there but be very basic, and it might become more functional in subsequent releases.
Renderer
I did a small amount of experimental work on the "renderer-as-protocol" idea today and it's looking like a viable way forward. This is needed because I want to move (almost) everything to HLSL for r_hlsl 1 mode; partially to support fog properly, but also for extra performance and flexibility.
Some existing bugs and glitches will be cleaned up.
Multiplayer Features
I want to build a server browser that downloads the server list from QuakeOne.com and lets you select a server to connect to from that via a menu.
Some more ProQuake features will definitely be there. I had hoped to also include the team scores features in 1.8.4 but the need to just get it released ended up being too great. They're virtually a definite.
External Textures and other Content Replacement
Charsets are long overdue being added to the list of items supported for external textures. There's still a sufficient amount of evil and ugliness in my code here that I want to clean out.
Half-Life BSP support fell quite a bit backwards in recent releases. I don't view it as being a critical feature owing to the lack of current mods that actually use Half-Life format BSPs, but I'd like to fix it up for the sake of completeness.
MD3 support is almost a core requirement these days. I've also written MD2 support for my Q2 engine that should be easily "drop-n-go"ed into DirectQ. The way I have my model renderer set up should mean that all I really need for these is loaders.
I'm still intending to do a particle system. Optional and disabled by default, of course, but I want one to be there. It's quite low on the priority list though.
Eye Candy
Effects such as bloom and heat haze might be added. These will be r_hlsl 1 only, and be optional and disabled by default (of course). The post-processing code that I currently use for underwater warps was written to be quite flexible in this regard, and the renderer-as-protocol setup will make things much easier to do.
I have an idea for shadow-mapping that seems like it might work well and with minimum Pain and Suffering.
No commitments to any of these, of course.
Multithreading
Some ideas here. I had an earlier version that ran sound updates in a separate thread but it proved unstable. It's something I'm continuing to read up on, and will hopefully be able to get some good results with.
That's all folks (for now)
Basically the 1.8 line has a good, solid and performant renderer that's moved in the right direction but still needs a bit of a working over in order to get more flexibility in. Having achieved that it's time to seriously start considering the addition of eye-candy and other frivolous things. The core of DirectQ will (and always will) remain classic and faithful, but these kind of features are also good things to have.
Holding off on them until the guts of the engine were in place properly was definitely the Right Thing to do; too many times in the past I've created a mess by jumping for the sexy features too soon. 50% of experience is knowing when not to do things.
On the other hand protocol and multiplayer features are things that don't immediately jump in your face, but that are of benefit to most people. There is always room to improve these from the rather basic Q1 implementation, but I'm a firm believer that changes should be slower and more incremental here.
I'll continue to post updates as more changes come to mind, and I'm always interested in feedback on what I've posted so far, as well as new ideas.
Thursday, June 3, 2010
More hypothetical "stuff to expect in the future"
Posted by
mhquake
at
7:03 PM
Subscribe to:
Post Comments (Atom)
8 comments:
I am eager to see really beutiful port able to compete with Darkplaces. Hope you will not lose your inspiration, pal :-)
As far as I understand, you have fixed Tenebrae to work on modern PCs. Is it reasonable to take its source code and maybe improve it or either take parts from it to your own in order it to be able to render per-pixel lighting as Tenebrae does?
Sorry if I don't get it - I am not a programmer and can't say how hard it is and how much sense does.
I always very much enjoy the way you are sharing your thoughts about the development of the engine with us.
It´s great fun to read about this stuff.
DirectQuake as it is now has almost everything that i need in a Quake-Engine.And it´s all working stable and smooth.
I couldn´t agree more with your plans to keep all the Eye-Candiness that might come in the future off by default.
Support for custom charsets (although not vital) will be a nice little improvement to an allready incredible engine.
I can quite safely guarantee that absolutely nothing from Tenebrae will work with my code. ;)
I could make it maybe twice as fast without too much effort though.
That would be awesome, really.
I see, that there's very little number of Tenebrae users these days, as of it incompatibility, obsoleteness etc. The only reason I like it is the way it renders. Why no other engine does this, how do you think? Is it so hard to be coded?
Not really difficult, it's just grinding out code, and the things that Tenebrae does are quite well understood these days so there's nothing special about it. The big problem with anything is that Quake's content doesn't support more advanced rendering techniques too good. The authors of Tenebrae made the decision to either provide their own (or generate it on the fly) which means not caring too much about being compatible with content in mods and suchlike.
Ah, I see. Well, I am not personally into mods, original Quake single player is quite enough for my nostalgic pleasure :-) So it would be cool to have it improved.
Can it be updated to support ogg or mp3 music? I saw the thread today on Inside3D forums, I guess, and there was said that it's quite easy using DirectX. Does Tenebrae being using opengl somehow prevents this or these things doesn't depend on each other?
In fact, as I've already said, if, for example, you would implement such lighting techniques in your engine, which is for sure much more modern and easily supported, I would gladly switch to it.
I love eye-candy in old games. Much more than multiplayer feautures most Quake-ports are most focused in, leaving visuals on the last place. That is why DP, I guess, is the only one real choice (except outdated Tenebrae) for eye-candy-loving fans like me.
Only problem is that for every one person who loves feature A there's another who loves feature B, and feature A & B don't always play nice with each other. :(
Sure, I see. Well, finally, it's up to you - no one else would do it, anyway, as far as I understand. I wull patiently wait and hope :-)
Post a Comment