There's something noble about using D3D11 to replicate 8-bit software rendering effects from 1996. This was really fast and easy to do, so why not?
Monday, April 16, 2012
One For The Ultra-Trads
Subscribe to:
Post Comments (Atom)
There's something noble about using D3D11 to replicate 8-bit software rendering effects from 1996. This was really fast and easy to do, so why not?
14 comments:
Hi! I have to confess I've never been huge fan of DirectQ, though always kept an eye on it. Completely because of fact it can't give the awesome look DarkPlaces can. I am a visual effects addict. But recently things have changed dramatically: I have bought nVidia 3D Vision. And it doesn't work with OpenGL games (which, as far as I know, is only a marketing trick, but nevertheless). So your DirectX ports of Quake 1 and 2 are only way to play them in 3D. Works very well, but my addiction cries for an eye candy! Do you have any plans to compete with DP in this or it's only a playground which you won't use to push your skills to the limits? I am eager to her the promising answer :) Best Regards and thanks for DQ!
Damn, still left some typos.
Awesome! DQ was already pretty good at emulating the software Quake feel, i'm sure this will make it so much better yet!
About eyecandy, I'm not sure. There's something intellectually pleasing about keeping hammering on the foundations, and it's showing in the engine. However since DP is the only 'serious' graphics port of quake, I don't know... having DirectQ be able to work with rtlight files would be nice. Or perhaps dynamic shadows for dynamic lights.
But I'm sure your todo list already has plenty of stuff on it!
One graphics feature that might not be too much of a hastle could be blob shadows? The 2d stencil shadows are great, but soft blob shadows are nice in their own way.
With regards to eye candy, I think the project page states his intentions fairly well: "DirectQ is a port of Quake to native Direct3D 9. The primary focus is on replicating the original look and feel of software Quake..."
MH used to say that DirectQ wont' support modern eye-candies like DP does, but RMQ engine which is also creating by MH might do if Golden_Boy, Ijed or other RMQ authors wish such features.
Eye-candy, eye-candy, eye-candy.
I appreciate the desire for it, and I empathise in a very large way because up until a few years ago I too would have been keen on it, but my own opinions have shifted a little (lot!) since those days.
I'm not out to recreate DarkPlaces (if I was I would have just forked DarkPlaces and worked on that), and there's really no need to as DarkPlaces already exists and already has an optional D3D9 renderer.
Regarding the overall picture, there are two schools of thought here. One says that engines should compete with each other so as to push themselves to even greater heights. The other says that engines should complement each other so that people can pick and choose one that suits their individual needs (which may even vary depending on which map or mod you're currently playing).
I actually think that both schools are valid, but for the purposes of DirectQ's looks I subscribe to the second (for it's performance I subscribe to the first).
RMQ is an interesting case because it's not a general-purpose engine. It's purpose is to actually become obsolete as other engines start picking up features required to run the mod, but until then it's to run the mod so it generally is restricted to features actually required to do so.
Again, I'm not out to recreate DarkPlaces with that, and it looks like DarkPlaces is at least going to get BSP2 support sometime soon(ish) so that obsolesence may be coming closer. If so the RMQ engine may yet serve a role as an experimental setup for things that the team want to try, but all of this is speculation/future stuff.
Alright, MH, I got your point. Thanks for an asnwer! Thanks to you I have learned about DX9 renderer in DarkPlaces, somehow didn't met this earlier. Though it doesn't work flawlessly - it works in the end, and I play Quake in 3D. Awesome!
just when I though DQ couldn't get any better...
I love you.
>Again, I'm not out to recreate DarkPlaces with that, and it looks like DarkPlaces is at least going to get BSP2 support sometime soon(ish)
LOL! We've asked Havoc many times since 2006 to add underwater caustics, but even this little request is not done yet. So I don't think DP will support BSP2 at least in this year.
But even if it will support BSP2 map format - how slow RMQ maps will run under DP? Big and detailed maps cause slowdowns in DP, sometimes down to 2-3 fps even with RTLights turned off!
And newer versions of DP do not seem to be faster or more optimized. That's why so many people are asking you, MH, to add some effects in your engine - not everyone can buy the newest graphics card to play remake of the 16-year old game with 10fps. Nobody wants to have another DP-like engines, but many people do want something comparable with DP in visual matter but with acceptable performance.
The main bottleneck in RMQ is actually it's QC, not it's rendering, so I'm not sure if a faster DP renderer would be of much use for it.
The RMQ engine itself can draw most scenes in 1 to 2 milliseconds, then needs up to 20 or milliseconds to run the QC. So optimizing the renderer for RMQ content is really wasting time at the moment, so long as it's just about fast enough there are other areas that are far more important.
LordHavoc, like myself and everyone else, has his own vision of "the way thing should be" and it's his right to stick to that. For what it's worth, there are serious problems with underwater caustics that are not resolvable in Quake architecture without heavy reworking and performance loss, so I can guess that this may be at least part of the reason why he doesn't want to do them.
I can list these problems separately if anyone is interested, but they're all related to objects being partially in water and partially out of water.
Regarding BSP2, LordHavoc has been in touch with the team to discuss it, and the latest DP autobuild has it, so it's safe to say that it will be appearing in future stable releases. That's one of the reasons why I designed the format to be as non-invasive as possible - so that it's so much easier for other engines to pick up.
every engine must fill a niche for anyone to use it. once it has a niche, you can expand that to convert more users.
DP fills two niches - modders and graphics. FTE aims for modders but without being 'otherwise awesome' struggles for willing modders too, and is generally buggy due to lack of stuff for me to test it with at the intial time of implementation.
DirectQ fills three niches - performance, driver compatibility, and faithfulness. There's no reason you can't attempt to fill other niches, just so long as you don't compomise the ones you already have.
The thing is though, if you don't aim to at least partially support each group (gamers, modders, and mappers), you'll hold the entire community back when your engine is popular.
Graphics is very good for advertising, but most people will switch it off as the first thing they do.
FTE has blob shadows (r_shadows 1 - actually it has a lot of things that noone knows about!). It shouldn't be too hard to port them over to DirectQ if you really wanted to. The code is basically just clipped decals.
DP supporting BSP2 will not make RMQE obsolete. It just doesn't have the performance at all (not even with rtlights and everything else off). DirectQ is more likely to do so, or would be if it were not windows-only.
Even FTE would stand a better chance, if I ever managed to fix all the bugs. :P
Also, while I'm babbling, benchmarking annoys me. FTE gets rather nice timerefresh results, but lower timedemo results (by the way, directq/rmqe 'cheats' in that the bf command runs out too quickly, especially in timedemos, which can be up to 1ms extra per frame in fillrate). I just wish I had the patience to track down the bottleneck(s) properly. :/
Benchmarks are just too subjective. :|
Hah, you found the bf thing. I don't think it's "cheating" per-se; it just keeps behaviour consistent with faster updates of cl.time when in timedemo mode. ;)
Of course that means that timedemos are not consistent with other engines, but then again timedemo is a fairly piss-poor benchmark; really only useful for benching an engine against itself after some code changes.
Definitely agreeing on the niche point. An engine needs this as a reason to exist; it needs to fulfil some need in the community that isn't being met by other engines. The trick is finding the right niche for a new project. The experimental Quake 2 engine I have, for example - that doesn't have a niche. It's GL3.3, but doesn't offer anything that isn't already there; the only purpose it fulfils and the only need it satisfies is my own need to experiment with a GL3.3 renderer.
I've a mini-rant about GL3.3 that I really must write up...
DP does have BSP2, although there is some minor spec tweak to be done that was wanted by Lord Havoc - nothing big. Spike is correct about DP performance as relating to RMQ though, this is an area where RMQE flat out beats DP. As for more eyecandy in RMQE, I personally think that fully dynamic world lighting is not needed in RMQ and that any resources would be better spent in the area of improving the quality and range of static lighting. The lighting of mapmodels is an example, blob shadows would be cool but decals actually can be used to create those in RMQ (for static assets). Simply *brighter* light would go a long way, since right now outdoor lighting in Quake is not capable of even approximating the brightness of real daylight. I have started to use dedicated outdoor textures because of this - brightened and desaturated versions of the normal textures. Fullbright in Quake simply is not bright enough, this is really a horrible problem and it is starting to be the #1 problem for me along with the horrible lighting of models and the low lightmap resolution. These are the top reasons for me to want to use more advanced tech for any future games. Not mentioning proper collision on models etc.
In comparison to these, realtime lighting is of minor concern.
i have a request that might fit your (our) intentions. ambient occlusion.
not sure if it's possible with d3d9 but 11 (atleast i think).
it would be a subtle touch like soft shadows that has no big impact on the look but would get the cleanness a litle out of these big polygons ;-)
Post a Comment