The GL3.3 Quake 2 engine is now running faster than DirectQ. It timedemos a few percent slower for sure, but when you factor in Quake II's higher polycount and overall greater scene detail it comes out a bit faster. What's really odd about this is that my previous experience has shown D3D code to be consistently 10% to 25% faster than the equivalent GL code, and what's even more odd is that this was benchmarked on AMD graphics.
It's obvious that something unusual is happening here, and theories abound. Either the AMD driver really loves this style of GL code, or something funny is happening in the DirectQ code. What might support the latter is that the current DirectQ code uses a few rendering techniques - such as geometry shaders for particles and the HUD/menu/console stuff - that may be suboptimal for the use cases I have.
Another possible explanation is that other parts of the Quake II engine are just more efficient than Quake (not having to interpret QC bytecode is one immediately obvious example), and this efficiency is starting to come through now that the old GL 1.1/1.2 bottlenecks have been removed.
Either way it's an interesting result.
Ambient occlusion - I've had a request to implement it in DirectQ. It's a nice idea but I don't think it's going to happen, for various reasons. Ambient occlusion is not just something that you switch on or off with a few lines of code - it needs heavy work on supporting infrastructure and framework, and requires a fairly generalized render-to-texture/multiple-rendertarget setup to exist in the engine first.
This ties in a little with ongoing discussion in the comments about DirectQ's performance versus DarkPlaces, and a wish for something with DirectQ performance but DarkPlaces looks.
What's important to realize here is that one of the main reasons why DarkPlaces can run slow is precisely because it supports all this extra eyecandy. Implementing it in DirectQ would very likely just result in a DirectQ that runs slow too. You can't have extra effects without performance impact as a tradeoff.
XP support - my ability to consistently support Windows XP is now limited to testing on a VM. That kinda sucks but it's also useful as performance testing on a VM can bring out factors that don't show up otherwise - in the past I found that it identified a bottleneck in drawing console characters that I was completely unaware of on a more mainstream platform.
Of course, with the move to D3D11 XP support will be gone, but I still want to retain something in the 1.9.x series - I won't be able to consistently support it, but at least it will be there.
A comment was made about "a version of DirectQ that doesn't crash on XP" and I need to address this. No released version of DirectQ crashes on XP; the cause of any crashes or other issues people may experience is nothing to do with XP and everything to do with other factors - misbehaving external content, bad config settings, weird hardware, conflicts with other software on the system, or whatever; it's important to state that every released version has been tested on XP and would not have been released if it didn't work.
I'm a little bit pissed about this kind of comment so I'll say nothing more on that.
Releases - I've confirmed one bug fix for 1.9.1 but another late-breaking bug has cropped up. I need to see if I can reproduce it before I can proceed with that. I was going to do a source-code-only public pre-beta release for DirectQ 2.0.0 and the GL3.3 Quake II engine recently, but I'm now holding off on that for another while as work continues. I'm still keen on the idea of source-code-only releases though, so it's something I'd hope to do sooner rather than later.
Thursday, May 3, 2012
Roundup of Various Items
Subscribe to:
Post Comments (Atom)
17 comments:
Another possible explanation is that other parts of the Quake II engine are just more efficient than Quake (not having to interpret QC bytecode is one immediately obvious example)
I would imagine the cost of the interpreter plays a pretty big role in the performance delta if John's past comments on the subject are any indication, yeah.
I'm still keen on the idea of source-code-only releases though, so it's something I'd hope to do sooner rather than later.
Source-only releases would be great.
Sorry for that comment. I realize you spend your own time and release this freely to all of us and for that I am greatful. Keep up the good work. I based that comment on one of your blog post earlier this year where I thought you said your XP system was dying and that you wouldn't be able guarantee support for it in the future. Sorry is I remembered wrong or misinterpreted what you stated. Without searching, I don't recall when that was. The only thing I haven't tried on XP to solve the 1.9.0 crash, is to go through the many painful hours of reinstalling XP SP3, downloading the slew of Windows updates and finally reinstalling all of the many NET Framework updates and VS C++ Redist. updates. All I know, is that it rarely, if ever crashed before the last couple of releases of 1.8.8. I hope you take this in a positive way as I don't mean to seem ungrateful for all of the hard work you do on this great port.
currently running windows 7 home premium, ati hd6900 series, amd x4 955 phenom ii, 4gb ram onboard sound
tried the releases on windows 7 x64 and 32 bit, windows xp, honestly didn't think of trying it in windows 8 consumer preview, maybe do another format and reinstall, or the very least on a vmware machine
but on all platforms i did not notice a crash or any glitch, perhaps just lucky with the right drivers or something (except that the catalyst panel always seems to crash on a reboot, much simpler to install the drivers only)
i look forward to any and all your future releases, you do great work
if you lived down the road from me, i'd buy you a beer
Regarding Q2 vs Q1:
q2 updates lightmaps less frequently, even with dlights supposedly, on account of how slow dlights were in glquake.
qc vs dll is irrelevent when running a demo, whereas q2 interprets the hud string every single frame, which is relevent...
(also, qc generally just sets state, rather than incorporating complex logic - rmq is the exception to that).
Regarding GL vs D3D:
From my perspective, this is caused by wglSwapBuffers being horribly slow. In opengl+windows, the most fps I can get with purely a swapbuffers call is about 3/4 of the speed of either d3d or glxSwapBuffers (in linux).
So yes, on windows you'll always get timedemos showing higher results in d3d.
gl also has a lot of unnecessary calls into the gl drivers, which then thunks through opengl32.dll etc, which is a lot of cache misses. gl3 features can reduce the number of thunks in the same way that d3d's vbos will.
If you take a peek at FTE, you'll see that the two renderers basically receive the same set of data.
OpenGL is faster for me, but other people (primarily ati users) claim that D3D9 is faster. But then the d3d renderer doesn't use that much hlsl, and has only preliminary support for rtlights (I got bored, okay?).
Regarding DP's performance:
that's because DP kinda sucks.
Compare it with FTE some time - both support rtlights etc, yet with all that stuff disabled FTE gets 3 to 4 times higher framerates.
I can't wait for an android port of DP. :P
Anyway mh, point is, with your skills+motivations, you'd no doubt find a way to keep it efficient even if you did add rtlights etc to directq.
If you're ever feeling bored, feel free to fix up fte's d3d renderer to support all that stuff. :P
Regarding directq stability, my only real issues are caused by dxsetup crashing and thus not installing the right d3dx dlls+settings.
I'm forced to compile from code if I want directq to run, and you use a different msvc version from me.
From my perspective, if your source releases compile with (cygwin-based?) mingw, then it would be much more useful/usable to me.
Source-only pre-releases would mean people who are willing to compile it would more easily be able to give you the exact crash locations.
Then again, you could compile a debug build and generate a core dump when it crashes (even with windows+msvc - fte has an example of that). Open it on your machine and then there's no doubt as to what is at fault as you can see the exact line.
Anyway, what I'm trying to say is that source releases are good, but at least try and make them compilable by tin-foil-hat wearers like me who don't want to bother with the upgrade treadmil with msvc's cost/instability record.
Just tested on a fairly vanilla XP SP3 build with no Windows updates installed, no crashing. I can do an SP2 build sometime (VMs rock) with absolutely nothing but the OS, DirectX and Quake to see how it behaves there.
Q1 vs Q2 benching was done with both timedemos and in-game testing. Q2 also runs it's server at a steady 10 fps whereas Q1 runs it at 72 fps, so that's more efficiency. The Q2 architecture is cleaner overall with better separation of client and server.
Q2 was modified to use CS_OWNDC | CS_HREDRAW | CS_VREDRAW, return 1 from WM_ERASEBKGND and creates it's context via wglCreateContextAttribsARB. Any or all of these may or may not be significant.
D3D11, oddly enough, has a massive lag after the first D3D call following Present. It doesn't matter what that call is, and in some cases it can take up to half of the frame time. It's still faster than D3D9 but I'd love to get to the bottom of that (or at least confirm that it's expected behaviour when using PIX and can otherwise be ignored).
what really fascinates is that you can know the code of both engines, the API and the driver layer and still not be able to predict behavior... huh
Ambient occlusion as in SSAO? no thanks! I don't get what people see in that stuff, it looks fake as hell and is pretty expensive. Like someone smeared some smudgy mess in every corner of the room, yuck!
It starts with SSAO, and it ends up with pixelated upscaled crap and shitty depth of field filters.
I have an idea! Lets add vignetting to darken Quake some more, then compensate that with RGB bloom and do some nice brownish colorgrading.
Did I mention anisotropic lensflares, godrays and starburst convolutions?
If you want it, bake it to textures. Otherwise pray some genius finds a fast enough way to do it in world-space.
Sorry if this is harsh, I'm just giving my honest opinion ;)
>wish for something with DirectQ performance but DarkPlaces looks.
Being one of that people who discussed with you, I can assure you that no one (except truly crazies) believes that's possible. But even with all eye-candies off DP shows several times worser performance compared with DQ. By the other hand, Unreal Engine 3 (for example) has a bit better look with much better performance, while CryEngine 2 has comparable performance, but looks much better.
But I understand that many people have asked you to do the things you don't want to, and to incorporate all the modern features is not DQ's goal.
DQ is my Quake Engine of choice. I for one don't want eye candy, I want the silky smooth frames rates that DQ delivers.
I have had a disturbing bug that is hard to describe without having the correct lingo. It is as if an invisible barrier appears and/or I get stuck/submerged on a slanted part of the map and take damage. (Getting stuck between brushes?) Restoring a saved game does not help. I have experienced this on several maps including Sludge Factory, A Roman Wilderness of Pain and Scourge of Armagon.
(DQ 1.9.0 Vista 64)
Please continue your great work.
The getting stuck thing is something that's known to me and that I've been able to reproduce in many other engines (including the id originals). At this stage I believe that it mostly comes from the map build process rather than the engine, and - if I'm right on this (I may not be but I believe there's a high chance that I am) - there's not gonna be much I can do about it.
I do have better detection of when this happens in more recent code, and a better workaround than the original engine had, but despite that it still does happen sometimes.
My thoughts on eyecandy are - I suppose - slightly odd. To me, there is a really crisp and clean look to the original maps (with the original textures) that gets lost when you start piling on the effects. Because of that I guess that I'm always going to be slightly anti-effects, but nonetheless pro a lot of other things that do improve this, such as gamma-corrected mipmaps.
The only thing really wrong is that some of the textures - where there is a one-texel fullbright for example - don't work well with standard linear filtering. The option is there to write my own filtering functions to do a little better, but I do fret over the performance tradeoff.
The big problem with Quake is that it was designed around a software renderer for low-poly scenes. There's no direct one-to-one mapping between code that works well with software rendering and code that works well with hardware rendering. Even with something as fundamental as hardware T&L, the code that you need to write to get the best out of it is often wildly different to the code that ypu would write to work well with software T&L.
This is pretty pervasive in DP. Much of what would be done on the GPU in any modern renderer is instead done on the CPU in DP - even something like IQM animation recently had SIMD code added so that it would run faster on the CPU. That's not what you do nowadays; nowadays you do it in a vertex shader and get all of that (and more) for free.
It's quite a wrestle to get Quake formats and content running to their best potential on modern hardware, and one of the goals of DirectQ is to do precisely that.
I have an idea! Lets add vignetting to darken Quake some more, then compensate that with RGB bloom and do some nice brownish colorgrading.
It's 'filmic' effects I find would be the most interesting and useful. I've experimented quite a bit, actually, with pulling RGB gamma and contrast values around in DirectQ and have come across some pretty interesting configurations there (going a bit heavy on green yields the most interesting effect). A personal "wish list" for filmic effects would be soft vignetting, dynamic color grading (ala more recent versions of Source, as seen in Left 4 Dead 2), film grain and perspective motion blur. HDR with dynamic tone mapping can also has some very practical benefits associated with it, so it's something else that might be interesting to see.
That's not to say I'm requesting these features in DirectQ, but I think they'd be interesting for someone to experiment with to see what kind of effect it would have with Quake's existing assets.
I made the post about the issue with getting stuck. If it is a map build issue then why is it not static? That is, some areas that were once accessible later become inaccessible.
I've run into the same issue, the only (temporary) fix I found, is restarting the engine and reloading the last savegame..
Btw, I don't think this issue is related to the classic e1m1 getting stuck on ramp near exit case.. It's more like the player is suddenly clipping against the wrong hull or something (sinking halfway into the ground and getting blocked by invisible geometry).
=peg=. Your last description is bang on. That is exactly how I would have liked to have described the "sticky" issue.
(I tried reloading save games, but not restarting and then reloading. Thanks for that!)
I have a slightly different experience with the sinking in the ground bug. It feels like suddenly a different set of collision planes becomes active. As if you were colliding with the geometry of a different map, while seeing the rendered results of the current one.
Obviously that's not whats happening, but it feels like it. And I can find myself running through a wall, floating over edges of cliffs, hitting some invisible wall midair, taking a left turn and getting teleported to the bottom of a pit in some other place in the map. It's pretty odd.
Random idea: instead of testing a collision box against the geometry, how about testing a few of them with slight offsets and averaging them together. Perhaps that could reduce the error margin. Just thinking out loud here.
I experienced the same problem of getting stuck on hipe1m2. At mid level something happened and I get stuck in a lot of places. I cheated and passed the level using noclip, but then on hipe2m3 got the same problem since the beginning of the map, so I suspected it was a bug of the engine because it happened even after loading the next map.
Actually I didn't try to load another level or loading a save, only restarting the engine.
Another thing that happened in hipe2m3, just before getting the gold key, on the lightning bolts that appear from the walls DirectQ crashes with the message:
"An unhandled exception ocurred."
I passed that part using noclip getting behind them, then killed them, but then i crossed the lighning bolts a few times and didn't crashed. On Quakespasm I don't get the crash.
I'm playing DirectQ with W7 32bit on a computer that doesn't have SSE2, so that may be a cause or not. I don't know.
BTW, Keep up the good work.
PD. Sorry if my english is bad.
last time it happened to me i was hearing water splash sound when jumping.
Post a Comment