Quake Video Code Rant

[Baker]

I was in the process of writing split screen rendering and reworking the 2D graphics handling in Engine X.

Then working through some of that stuff, it occurred to me that the video code in Quake with 15 variables doing nearly (width, DIBWidth, window_rect, and on and on and on) the same thing is just terribly disgusting.

You can't get "control" over the engine with confusing variables maybe used by a single function redundantly scattered all over the place.

I think I understand why Spike scrapped software renderer stuff for FTEQW going forward. Having to work through the code just to find the 85 software-renderer relics (not that FTEQW would have those) that don't do anything or don't matter to OpenGL and having to maintain that overhead ... yuck.

/End Rant

[mh]

Been there, done that, made the same rant. Many times over.

Wait till you move on to how it interacts with the input and sound code. More globals storing the same info, dibwindow, mainwindow, yadda yadda yadda.

[Baker]

I'm hoping I can unwind all that spaghetti, by tomorrow morning.

What I would like to do is have some flexibility to define viewports at will and get a true framework going with the 2D graphics. [And the menu and the sbar].

With ProQuake I had to stick with expectations, maintain builds, ensure backwards compatibility. With Engine X, I can do whatever makes sense.

I noticed from day 1 things relating to both the "canvas management" and the menu.

[Off-topic, but speaking of nasty stuff I read the whole Nehahra thing. Many things I didn't know ... that skybox/savegame thing. Well, those were the early days.]

If I can truly get a handle on the disgusting redundancy of the window definition cvars, I'll should have some major speed gains in accelerating some of the things I want to wrap up.

[mh]

I tend to view Nehahra as being a crushingly disappointing missed opportunity. Here was a chance to get a good baseline set of standards to move forward from, but instead it turned out to be a collection of some of the grossest hacks imaginable. But like you said: early days.

[Baker]

I tend to view Nehahra as being a crushingly disappointing missed opportunity. Here was a chance to get a good baseline set of standards to move forward from, but instead it turned out to be a collection of some of the grossest hacks imaginable. But like you said: early days.

I didn't really know how gross until I read your blog item. I'm glad LordHavoc and Spike have been guarding the fort with the "decent standards" thing over the years.

[Spike]

'decent standards' is anything you don't mind maintaining for ages, including future extensions. :)

Baker, all those variables in the video code would not be so bad if they were correctly scoped. Quake's main fault is that it uses so many different globals, and globals are bad. They're easier for asm though.

FTE no longer has a software renderer because noone cared enough to maintain it. When the code around it is changing, it gets in the way. Plus, the removal of the software code permits merging the gl/d3d code paths into closer alignment with each other, instead of somehow trying to fit software rendering in there.
If FTE does ever regain a software renderer (and it would be nice) then it'll have to fit the same basic framework as GL/D3D - vertex lists.
But in all honesty, its easier to use gles for embedded systems, and retain intel driver support for pcs.

[TimeServ]

Well really FTE doesn't have a software renderer because I woke up one day and decided to remove the entire software renderer code because I was sick of looking at that and then committed that change in. So really I'm the one to blame for that. Spike just didn't feel like getting into a commit war and reverting the changes I guess.

[Baker]

Software renderers are fun, but I think to some extent they really are a novelty for the most part. It is fun to learn how they work, the pixel buffers and all that.

But maintaining a novelty build of FTEQW with so much capability that software just isn't going to have is a hell of a lot of maintenance overhead.

[And it's not like the SW build source isn't out there for prior builds.]

[mh]

I'm semi-fascinated by the possibility of implementing software Quake's surface caching using a set of dynamic textures in either OpenGL or D3D. I believe that's the architecture vQuake used back in the day, and I know it won't perform well, but it's still intriguing.

[Spike]

One of my failings is the inability to completely remove something I worked on. Not really a problem, as it will live on at least in the svn history, but hey, I'm too lazy to fix up that stuff each time I break it.
Besides, I couldn't ever figure out what the heck any of the code was doing anyway. Too many statements that just copy one global to another global, and far far too many spans.

[Irritant]

Software renderers are fun, but I think to some extent they really are a novelty for the most part.

Exactly, what is the point of maintaining a software renderer?

[mh]

In fairness Quake's software renderer has always been far superior to the original GLQuake, so a valid argument could be made for using it in preference. Modified engines have caught up, and fixed a lot of the things that are wrong with GLQuake, so that argument seems less valid these days, unless one has something against the concept of using a modified engine, or unless one has a really old machine that doesn't have even semi-reliable 3D acceleration.

Maintaining a software renderer in the same codebase as a hardware renderer seems more trouble than it's worth to me.

[Baker]

Exactly, what is the point of maintaining a software renderer?

About the same as keeping the CD player support in an engine

[Chip]

Exactly, what is the point of maintaining a software renderer?

About the same as keeping the CD player support in an engine

CD player support was the first to be stripped from my modified DP engine.

[leileilol]

In fairness Quake's software renderer has always been far superior to the original GLQuake, so a valid argument could be made for using it in preference.

In 2011 it's still not about preference. *cough*poor bsd on intel gma folk*cough*. This almost makes me want to have software rendering for OpenArena somehow i mean jesus christ...... don't underestimate that obscure-of-obscure gamer portion. entitlement issues are through the roof. It's one of the many reason Darkplaces has a software renderer now even.

As for CD support... i had that replaced with MIDI for a while, then reverted it back since you can't midi quake music and vorbis decoding on pentiums suck.