Wednesday, July 28, 2010

Good Vibes and HLSL/GLSL Comparisons

I've been a bit quiet lately but that's been on account of having my nose buried in work on the RMQ engine. Things are coming along quite well; obviously there is still a long way to go, even with a single subsystem such as the renderer, but other things are also getting done.

Removing and extending limits is a critical part of any project where the content is demanding, and I've been able to draw on the experience of some things I did right (and some things I did wrong!) with DirectQ for this one. Overall I think the code is a lot cleaner than DirectQ's. Of course a natural credit for this needs to go to both metlslime and the QuakeSpasm team as they provided such a great cleanup of a lot of things that were fundamentally wrong with the GLQuake source code (with DirectQ I started from scratch myself).

Some really good vibes coming through these days. For a long time now I've felt the need for some more serious testing on engine releases, and the experience I had sending advance copies of the DirectQ 1.8.666 executables to various people really brought that need home in a big way. Frankly, a lot of the bugs that came out in the released versions could have, would have, and should have been avoided if I had been more forthcoming with release copies at earlier stages of the development (I should have also released after porting the ProQuake netcode but before rewriting the renderer, but that's another story). Working with the RMQ team, I'm getting new code out to them on a quite regular basis - daily, often more frequently - and it's showing in the improved quality and stability.

They're also tolerant of some of the more serious mistakes I've made, like the time it crashed and burned on Linux for two days. That's pretty much all that an engine coder could ask for. Happy days.

It's also great to see some of the performance improvements and other stuff I've done being used by a talented mod team who are taking the opportunity to go nuts with them. The next RMQ demo (am I allowed talk about that?) should hopefully showcase some quite cool stuff.

On the other subject, I'm implementing some GLSL code in the engine. I had played with it a little some years ago, but most of my recent experience has been with HLSL, and it's interesting to do a comparison of the two. Of course my opinion may change as time goes on, but here's how things stand for now.

I've long been of the opinion that up to and including OpenGL 1.4 things were great and OpenGL was by far the superior of the two APIs. That opinion still stands, and if I'm working with OpenGL code up to 1.4 it's an absolute pleasure to use. I think the only things I would mark in it's disfavour are the need to bind objects before performing operations on them and the fact that some of the GL_ARB_texture_env_combine stuff is a little on the horrible side.

VBOs were where things started getting ugly. They could have been more tightly integrated with vertex arrays for starters, and the whole API could have had it's behaviour more clearly defined. In actual fact if VBOs could have just been implemented as a glHint things would have been a lot nicer (and probably more in tune with OpenGL's underlying philosophy).

My theory is that when D3D got vertex buffers (one of the first times, if not the first time, that D3D suddenly took a jump ahead of OpenGL) somebody in OpenGL-land panicked and the end result was a botched half-thought-through first draft of an API that's had to end up being patched through subsequent revisions. In other words a part of OpenGL suddenly became like what the really early versions of D3D were like.

GLSL certainly mixes the sour with the sweet. The whole operation of creatings, setting source, compiling, linking, attaching, etc shaders with programs (and even the fact that there are two separate types of object in the first place) leaves one with a bad taste. It's like Lotus Notes in a lot of ways - lots of people might think it's brilliant but unless you've been exposed to something that comprehensively pisses all over it, you'll never know better. The D3D FX framework is just intrinsically superior in every way.

On the other hand D3D tends to assume that if you're using shaders at all you're going to want to use them for everything - a common fault with many MS technologies. Mixing shaders with the fixed pipeline is just not fun in D3D; states will start going haywire, matrix transforms will give subtly - but significantly - different results, things that used to work (like fog for example) stop working, and getting the whole thing into coherent shape will take so much work that you might as well just rewrite it to use shaders everywhere. GL is a lot nicer and more sensible in that regard.

So what am I using shaders for in RMQ? Nothing much or nothing fancy; we want this content to be fully functional on as many engines as possible, so all I'm doing is supplementing and boosting some of the existing rendering paths. It'll end up being much the same as DirectQ in other words, just using them to improve the classic Quake water and sky warps and not much else.

Think that's all for now. Till next time.

7 comments:

Nyarlathotep said...

Tonight I will test Wine + Slackware. I'd have done this a while earlier, but grad school prep and Real Life have eaten a lot of my free time. You may be interested to know that DirectQ is hilariously broken on Windows Vista when using GeForceFX cards and the (final) 96.85 drivers - terrible performance, with lots of bizarre triangles-shearing-off-into-infinity glitches. I'll try to get some screenshots, and may end up recording a few snippets just so you can see what's going on. It's kerrrrazy. FitzQuake worked fine, so I know the hardware isn't bad...

mhquake said...

I would hazard a guess that's a combination of shaders being crap with GeForce FX cards (DirectQ will prefer to use shaders for drawing absolutely everything if they're available - try r_hlsl 0 to override this and see if the situation improves) and possibly needing a D3D9 update.

I don't expect Wine to work with the D3DX DLLs that come with it, by the way. They're quite unfinished, with far too many of the functions DirectQ needs being just implemented as stubs (and stubs that don't even fail gracefully for that matter). It would be a pleasant surprise if I was wrong, of course (especially with the new version of Wine).

I do know that it does work if you copy the D3DX DLLs from a Windows installation, however.

r_hlsl 0 might well be needed here too.

I do have proper hardware accelerated Linux myself now, but just haven't gotten round to trying it out yet.

mhquake said...

By the way, I've played with the idea of disabling shaders by default if it detects a GeForce FX installed, and might yet do it.

Nyarlathotep said...

Having ensured that Direct3D 9 was up to date and that DirectQ's autoexec.cfg contained the r_hlsl 0 line, I plunged in again... to exactly the same behavior. Out of morbid curiosity I removed the Vista-native drivers and installed the final released XP drivers. All problems went away, and r_hlsl 1 worked beautifully... though in the process I lost Aero (not a big deal, the card has 64-bit memory and chugged anyway) and OpenGL (which is rather less forgivable). I'm starting to think this system needs an overhaul, and that its current innards need to be turned into some kind of Linux taskmaster.

In short: Final Vista drivers for GeforceFX cards are garbage. If no one bitches, I wouldn't worry about it.

mhquake said...

No-one's bitched so far anyway. :)

I don't think too many Vista users download it to be honest, most people seem to be on either XP or 7.

Nyarlathotep said...

As the 5700 was being a finicky turd, I evicted it and am using onboard video. You're one hell of a coder - no one could have convinced me that I'd see DirectQ running at >60 fps at 1360x768 on an i865G (using dual-channel DDR400, no less)!

Issues getting Wine to work at all appear tied to my decision to use the x64 branch of Slackware. As the system has 2 gigs of RAM I'm planning on flattening it later today and using a plain-jane x86 install. When I get Wine a-working, I'll pass on my results.

mhquake said...

Heh, it was written to run well on onboard video and pulls a LOT of tricks to make sure that happens (the choice of D3D over OpenGL was one of them).

Those Intel chips are not actually bad parts at all, even though they do have a bit of a bad rep. It's more the case that code needs to be written to take advantage of their strengths, whereas most code is in reality quite sloppy, and if something runs OK on the latest powerhouse it's considered "good enough".