Engine Philosophy Discussion

[mh]

I've been around since maybe a day or two after the original source release and even remember QER - showed promise but ended up being a showcase for two people's work and a CounterStrike clone (that Valve C&D'ed). I believe that I may have been the first to unlock the skybox code, and I'm reasonably certain I was the first to do any kind of entity alpha, but looking back the contribution I'm proudest of was the coloured light tool (and the LIT pack).

</old_man_getting_sentimental>

[revelator]

indeed colored LIT has probably been the longest living addition to any quake engine besides QER's interpolation code.

other good stuff was bumpmapping with virtually no speed hit by calculating the bump vectors by entity instead of by light (realm uses that) the idea was partially by me but i didnt have the knowledge so MH totally got me sold when he presented an engine with it working .

[mh]

Well the actual coloured light code has to be credited originally to the QER folks, but LordHavoc did the sensible implementation (including the LIT file spec) that everyone can trace their's to nowadays. I made it really sing though by providing LIT files for ID1 maps and a tool to generate them. Each needed the other to work; without a sensible coloured light implementation the LIT file pack would have been marginal, and without an ID1 LIT file pack in wide circulation a sensible coloured light implementation would have been marginal.

(This is leaving .rtlights out of the discussion of course).

Back on topic.

The one thing that really turned around my knowledge and appreciation of how GPUs actually work was learning Direct3D. This is something I'd recommend everyone do, even if it goes no further than writing a simple MDL or BSP viewer. Because when you think about it, at the most basic level a 3D API is really nothing more than something that takes commands, converts them into a format that the GPU can understand, and passes them on to the GPU for further work. There's no special magic in OpenGL (or D3D) on the software side. Take command, convert it, pass it on.

Even back in the old days when you used to find tutorials saying stuff like "ha ha you can't do this in D3D because it doesn't have a stencil buffer". Talk about misleading. It was never OpenGL that had a stencil buffer, it was the hardware. All OpenGL did was expose commands that let you use it. (D3D has exposed the stencil buffer for well over a decade, by the way.)

So OpenGL is kind and caring and forgiving and lets you do all kinds of crazy stuff whereas D3D is cruel and punishing - you only get what's on the hardware and if you try to do something that's not supported in hardware you'll crash. So learn D3D and you'll very quickly learn the boundaries of what is and isn't supported in hardware (and you'll be a better OpenGL programmer for it!)

[Irritant]

I think the thing that made the OpenGL light click on for me was the Quake 2 Graphics Mod, by Ben Lane. As far as I know his engine was the first to successfully implement GLSL. I had banged my head against the wall with fixed function OpenGL for some time trying to get proper per-pixel lighting to work. Learning GLSL opened up a floodgate for me, once I got the substructure implemented in my engine, I kind of went crazy, finding every tutorial I could use and trying them out.

The Red and Orange books were a godsend as well.

To this day rendering tech is my main interest, I'm always looking at things to try out...make it prettier...faster....I love getting a new game and seeing something new that I want to implement into my own engine.

[dreadlorde]

[mh]

[mh]

[dreadlorde]

[revelator]

[r00k]

[Baker]

Just throwing this in here ...

Engine modding, if you are going to try to get it right, really requires making very large lists.

I'm rather happy about Quake Expo looming. I feel the need to achieve several things each day in order to stay on target with my project. Sometimes a sense of urgency is a great thing.

I keep a "big list" and a "small list". The "big list" are things that a user would easily notice ... the "small list" is more quality control. The "big list" is "only" about 35 items (about 1/3 are hefty modifications with the top 3-4 being major headaches).

The "small list" evolves ad-hoc and has grown to consist of literally at least 100 minor modifications.

A couple of months ago, my mindset was basically that I evolved enough that I didn't have to worry so much about "quality control" any more. That was SOOOO wrong.

It caused a reboot when I finally reached a point where I felt like I no longer had full control of the issues remaining in the source code and did a continual rebuild incrementally + polish + rinse and repeat cycle over and over again.

I guess I have found that smashing difficult issues as they come along (provided you have enough info/expertise to do it ... which is not always the case, and certainly not the case with me at all times) and concluding that reaching a stop and continue point where you have felt that the new "version" contains all the strengths of the previous version but with less issues or more flexibility or easier to maintain code is paramount.

Killing bugs and rewriting code to be high quality is not something that any end user will ever notice, but you know it. I'm not sure that it ranks high on what anyone doing engine coding REALLY wants to be doing --- new exciting stuff is more fun --- but at the end of the day it feels better that you were nice enough to yourself as to have been courteous to yourself tomorrow that when you wake up the next day, everything was cleaner than the day before.

I see in places some code I obviously wrote in 2007. Occasionally it is rather embarrassing to think that someone else might see those odds and ends in the source code. [I also find it a bit weird the number of things I was actually able to do in 2007 ... the code isn't as bad as I make it sound but at times I didn't really get what was going on, but that didn't seem to get in the way often.]

I guess one reward of really refining and fixing up existing code, especially over most of the codebase, is that you feel it is a better reflection of what you consider an accurate depiction of what you would typically do quality-wise. Kind of like how a mapper likes to release maps with all the textures perfectly aligned and play tested.