RMQ Engine ... Sheesh!

[taniwha]

*sigh* That was sarcasm pointed at your out-of-a-hat statistic .

Actually, I know how you feel: I've always been way behind the leading edge myself, so always felt left out when new cool stuff came out (still do).

[goldenboy]

Germans don't detect sarcasm very well.

[mh]

There's a balancing act in all of this and it doesn't even have to go all the way to D3D11. Let's take a specific example: you want to do some post-processing effects. Your options are:

- Use a framebuffer object, but that rules out older hardware.
- Use glCopyTexSubImage2D but you've just doubled your bandwidth requirements (and it will run like shit on the older hardware you wanted to be inclusive of, so people will want to disable it).
- Write two different codepaths but now everything you do you have to do twice.
- Junk the idea.

Which one do you choose?

It's worth noting here that GL_ARB_framebuffer_object dates back to 2008, and it's predecessor (GL_EXT_framebuffer_object) to 2005. That's 4 years old and 7 years old at the time of writing. Is requiring 7 year old functionality too much? For some it seems so (my mind was boggled last year by someone's description of Doom 3 as requiring high-end hardware; no, it doesn't; it requires 8 year old hardware and 8 year old hardware is almost right at the bottom of low-end). But yet in order to do the interesting things that people like to see (and can occasionally be very demanding about wanting to see), you have to pick a line and say "below this I will not support" - otherwise all you've got is another variant on what's already gone before.

What's ironic about all of this is that Quake, when originally released, was actually on the cutting edge of hardware requirements. People had to send their 486s up to the attic, fast floating point support was required (it's easy to forget in 2012 - or even back in 2002 - that once up a time this was very much a high-end feature), and GLQuake required bleeding-edge top-of-the-range 3D acceleration. The "must run on somebody's mouldy old TNT2" culture is a very recent phenomenon.

[Spike]

with arm devices and their tendancy to lack fpus, we still have the issue where quake is running on subpar machines.
the problem with post processing effects in general is that you need glsl for any real effects, such hardware does generally support pbuffers/fbos. doing it without glsl is just silly.
intel users must die.

highend users will usually want to be able to switch everything off if they're playing deathmatch too, so all I can say is two birds with one stone.

[taniwha]

Yeah, QF runs nicely on my eeepc (intel graphics) in fixed-function mode, but abysmally using glsl But that's just another reason to not throw out the old renderer but develop a separate one . However, that's not very different from using two different code paths.

[Spike]

two codepaths is quite nice for a geforce3/4 where glsl is quite slow.
glsl for water/sky so it doesn't look horrible and/or with less overdraw, glsl for gpu-based vertex blending.
fixed function for drawing the bulk of the world.
two code paths, both active at different times with the same gl context.
Yes. Its more code.
I would not have reimplemented rtlights without glsl if bigfoot had not assured me he would use it... Which I think he still has not.

[taniwha]

The sad thing is, glsl surfaces actually looks /worse/ on my eeepc: the interpolation is all wrong (probably driver bugs, though. go mesa! ).

[mh]

GeForce 4 is 10 years old so it's not so much whether or not you think you should have 2 codepaths but whether or not you want to support 10 year old hardware.

[revelator]

while probably one of the best gfx cards nvidia ever birthed its getting rather old
if looking for a new card i can say i been quite satisfied with my 560 gtx and it should'nt be that expensive these days.
Go for the 2 GB version which allows you to play games like crysis2 with max settings,
the 1 GB version chokes pretty hard on resolutions above 1680x1050 with everything on ultra
cause it runs out of texture memory. Besides that its a solid performer.

[mh]

I'd say it's doing more than just getting old - 10 years is an eternity for gfx cards. It's amazing that there are any GF4s left that still even work.

[leileilol]

I think it's less about 'supporting the old' (which I only try to do for the fun of it (OA on PCX2 anyone?)), but more about 'supporting the current and shitty' - *COUH*GMA*COUGH*

[revelator]

Derail tour but yeah probably more a question of supporting laptop gfx which more times than not leave a lot left to be desired.
I still got 4 old geforce 4 cards and they all still work though i dont use them for anything but toying with an old PC it shows that the card was pretty solid

[Spike]

I've had both nvidia and amd graphics cards in laptops, they tend to support everything you'd expect them to support for their time. They might overheat, sure, and run slowly, but they do support everything.
Its mobile devices that don't support everything, or lack optimised glsl, etc. If you've no ARM port then its only intel that you really have to be paranoid about.

Regarding the PCX2: PowerVR... the company that were kicked so badly they had to focus on mobile instead. My how much their devices have grown in performance... *cough*

[revelator]

Mobile my bad its early morning here and im picking crusties out of my eyes

[mh]

Intel have supported GL2/2.1 for a long time now, but of course with Intel "support" is relative.

Last year and earlier this year I did a lot of work with an Intel 945. This dated back 6 years or so, and has fairly solid GL1.4 or 1.5 support, can't remember which. GL_ARB_vertex_program and GL_ARB_fragment_program were both available, VBOs were available (although as a software T&L part they would have been emulated) and Quake-style rendering can be done with quite modern-looking code.

There are still advantages to using even VBOs in this case. For one thing it means that you get to avoid a lot of horrible shuffling of data around in memory before you actually get to draw stuff. The rules with software T&L are quite different to hardware T&L though - you do need to be mindful of your VBO access patterns and not just randomly jump around in the buffer (you can get away with this in hardware T&L without penalty), and both tend to crash in different places if you do different classes of bad things (going past the end of a buffer with hardware T&L is generally fine, with software you'll crash - if you're lucky). Using streamed rather than interleaved data can be advantageous (as can padding the position component to 4 floats for SIMD ops). For smaller maps (ID1 scale) you can get away with a glDrawArrays call per surface (store the glDrawArrays params in your msurface_t struct and it becomes really easy), for bigger maps it piles up (by then you'll be bottlenecking on the server more than in the renderer though). Not having GL_ARB_map_buffer_range means that dynamic VBOs are broken and for any kind of dynamic data it's best to use plain vertex arrays, but couple them with vertex and fragment programs for handing water and sky, make at least some attempt to group surfaces by shader type, and you never have to touch any surface vertex data at runtime and can get quite fast performance out of it (I was hitting ~280fps timedemo demo1 at 800x600 windowed towards the end).

An interesting quirk was that 4x aniso was maybe 5% to 10% faster than regular trilinear. No idea why, but it was measurable and repeatable.

The software vs hardware T&L differences highlight one thing I said earlier - that's a bridge beyond which the rules totally change. The kind of code optimizations you do for one are often somewhere between useless and harmful for the other, so if you take code that's optimized for the capabilities of one and try to run it on hardware that has the other, the best you can hope for is that it won't run as well as it should. Unfortunately GL doesn't offer a means to detect if you're running a software T&L implementation (and relying on detecting extensions is useless because - as we've seen - vertex programs and VBOs can be both emulated in software without any issues). That's a burden that needs to be shifted to the player - yuck.

If you really must run on both classes of hardware, you have a coupla choices. You can write separate codepaths for each, or you can pick one and accept that the other is going to suffer.