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]

Red and Orange books? Do you know the full names, I might want to get those books. :p

[mh]

Mmmmmm yeah, I think the first time shaders really click is something great, even if it's as basic as "I can do fullbright colours with a single texture plus lightmap - no need for an extra 'luma' texture" (still unimplemented to this day ), or putting MDL animations entirely on the GPU, or whatever. I think fixing the sky warp was the one that did it for me. Going back to the fixed pipeline feels like wading through a sewer.

Draw call batching was another "eureka!" moment. I'd always been disgusted by the in-memory MDL format GLQuake used, so I changed it. Turned out I could draw one with a single DrawIndexedPrimitive (or glDrawElements if you prefer). Cue instant x 1.5 speedup and sound of my jaw hitting the floor. That set the tone of my work for the next good while.

My slightly weird obsession with input code was totally new and unexpected, don't know where that came from. I'd always been vaguely aware that there was something badly wrong with the stock lightmap code, but it took a while (longer than it should have done) to pinpoint what was going on. Recent research into timers and timing has been stressful (and quite frustrating at times - pun intended) but an extremely rewarding learning experience (with some insights into interpolation that I didn't see coming along the way).

That, I think, is what it's all about. Work hard, learn, try to understand what you're doing, build on knowledge (your own and others), and share the useful stuff so that others can benefit.

[mh]

Red and Orange books? Do you know the full names, I might want to get those books. :p

Bottom two here: http://www.opengl.org/documentation/boo ... g_language

The Blue Book (Reference Manual) is one I've always had a soft spot for too. I like a good reference, and while there's nothing in it that's not available for free online, it is incredibly convenient to have a paper copy.

Studying pipeline diagrams is enlightening too, getting to know where the functions you're using fit in, where bottlenecks can occur (and understanding why they occur).

[dreadlorde]

Thanks, mh. They've been added to my giant list of books to read. :p

[revelator]

thanks for the links

i hope i can comprehend the stuff in it everything helps.

[r00k]

Oh I think they offer the red book here for beginners and student... http://www.opengl.org/documentation/red_book/

Highly recommended reading! This current edition of the Redbook is a must have for any OpenGL developer.

Earlier versions of the Redbook are available online. These earlier versions are useful for getting started with basic OpenGL coding but they are not adequate for more advanced rendering and techniques. We requested the publisher to post a copy of the early version on OpenGL.org - but in the meantime, there are several "unofficial" hosts that vanish and pop up at new sites regularly!. (Let us know if you discover that these links have changed.).

[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.