Canvas Size

[Baker]

I'll tell you, metlslime really did FitzQuake right with the canvas size implementation.

I'm working on some custom sbar code and standard Quake and most modded engines have it all wrong.

When drawing pictures on the screen and menus, you shouldn't need to worry about the 2D size. The 2D size should be set to 320x200 or maybe 320x240 and you should be able to use that coordinate system natively.

Still, 640x480 is more intuitive.

But the standard Quake way leads to all kinds of contortions. It is annoying as hell.

sbar.c even has Sbar_draw which translates coordinates to Draw_String and such.

Annoying as hell ...

Sigh.

[mh]

One thing it does wrong is completely wreck your ability to batch up primitives in the 2D render. It also doesn't restore the fullscreen viewport before calling SwapBuffers, and both of there can cause issues and glitches on some drivers.

Finally, there is considerable driver overhead from recalculating transform state so many times per frame. It's not that big an issue with something as simple as Quake on fast modern hardware, but it is there nonetheless.

As an alternative it can be implemented in software by calculating scaling and offset factors for each type, then applying those to the 2D coords when drawing. It means some CPU overhead, but it's a tradeoff that's worth it.

[Baker]

You know, the above being said ... since hardware doesn't have infinite pixelage a "vector-based graphics approach" to raster graphics is going to be "scrunched".

My plans, foiled. Before writing one line of code.

I thought about how stupid the console text looks in stock GLQuake doing -width 800 -height -600 because GLQuake will use a conwidth/conheight of 640x480 and the text gets all distorted.

[metlslime]

It also doesn't restore the fullscreen viewport before calling SwapBuffers, and both of there can cause issues and glitches on some drivers.

Interesting, I didn't know that could cause problems. Of course, knowing how many other things have turned out to cause problems on some hardware, I'm not surprised.

As for the rest of it; I'm not sure if it's worth it to transform everything in software unless the dozen or so state changes are really expensive, or if you're doing other stuff (like batching) that could be much faster. Quake usually doesn't have that many 2D images to draw (other than console text, or end-of-episode paragraph.)

[Spike]

consider wall torches. not that many verticies in them, but you get lots on a map at once. if you're already interpolating the verticies, then doing an extra addition per vertex is likely to be faster than using a seperate matrix transform and thus a new glDrawElements batch.
Regarding 2d images, quake does all the transformations in software already, well, other than scaling, but seeing as you'll be changing the projection matrix anyway, it makes sense to just use the projection matrix as required.
One slowdown with vanilla quake is that each and every console char is a separate draw call. It shouldn't really matter too much.

[mh]

One slowdown with vanilla quake is that each and every console char is a separate draw call. It shouldn't really matter too much.

Oddly enough I've found one driver (VMWare's) where it actually does matter very much and bringing down the console will drag you down to maybe 6 FPS.

Interesting, I didn't know that could cause problems.

It shouldn't, but there is hardware out there that will only swap the last viewport rect.