The code is really really ugly. I thought the released Quake 1 code was in bad shape, but this is another level beyond.
It fully respecifies the texture object for dynamic lights! That's not clever; the old insistence on using GL_RGBA (or worse, GL_RGB) is already dramatically slower than it should be, but this is just silly. No wonder there are so few dynamic lights in the game; that's something to change.
I suppose it's the earlier version of GLQuake that it's based on that worked that way.
No multitexture. That's fixed now; we have multitexture and almost everything using vertex arrays. The intention is to complete the move to vertex arrays, then try some of my VBO tricks I've used in RMQ. The longer term goal is to make this a platform I can try out new ideas for the RMQ engine on, but bloody hell, there's a lot of work involved in getting it there.
The various surface types, with all the abslight stuff, is horrible. I've put them all in a shader. RMQ also optionally uses shaders (if they're available) for sky and water polys only; unlike DirectQ they're not user-selectable, but that's OK (I regret making them user-selectable in DirectQ). I might move more stuff in it to shaders too; the ability to set up any texture blends you want exactly how you want them, and with no interminable lines of glTexEnv, is something that it's damn easy to get used to.
Speaking of surfaces; I don't know if Hexen II is supposed to have fullbrights and overbrights like Quake is, but from looking at the colormap I guess it is; they're in now. These are handled in a shader too, and I've used the alpha channel of the texture to stash the fullbright info so that we don't need to load a second texture. This isn't an option for RMQ as it needs the alpha channel for it's "fence textures".
2 x overbrighting does not provide enough lighting range for most Quake maps. They really need 4 x overbrighting but that would give bad stair-step lightmaps. I might look at using 64-bit lightmaps; I've already tried them out in the first release of DirectQ and they work very nicely indeed. These are also an option for RMQ. (Thought: using a shader allows for any arbitrary overbright scale; you're not restricted to 1x, 2x or 4x like with fixed).
I've changed the protocol to allow for floating point coords and angles; this is now incompatible with the original protocol, but it's only an experimenal engine so I can get away with that kind of thing. It does smooth out rotations quite nicely though.
I'm going to do interpolation. I'm not happy with the interpolation code in almost any Quake engine I've ever seen (the software Quake code I wrote comes closest to pleasing me) and I want to try my hand at something that works well and seems good to me.
Part of the problem is that the Quake models (especially the v_ models) are not interpolation-friendly. That's probably not an issue with Hexen II, but it is something that should be fixed. My muzzleflash hack in DirectQ is a decent enough solution, but I live in fear that it's not going to work as a general solution, and that someday someone is going to make a model that it doesn't work on. It's held up well so far though. Fitz also has a workable solution, but none of these can replace a model that's properly designed to begin with.
Note to content creators: if you're creating a new v_ model, please please please make it interpolation-friendly.
Think that's all for now.
Monday, October 11, 2010
Thoughts on Hexen II
Posted by
mhquake
at
2:19 AM
Subscribe to:
Post Comments (Atom)
2 comments:
I guess 'coding' is a labor of love and the game companies hate that. To them, it's like, "let's just get the game playable and out so we can make a profit", while to dedicated coders like you, it's "I'll release when my engine is -optimized- and not a bit sooner; you gamers 'll just have to wait! Hm, maybe some bits and bobs of cleaned Hexen II code will find their way into DirectQ... or not.
when it comes to fte and hexen2, its a reimplementation rather than a port.
Its just cleaner that way (especially for the renderer, which is vastly different in the first place).
abslight is implemented the same way that lightstyles are implemented - if set, the lightmap info is filled in with lighting values for the entire object, and obviously cached, so without it using different shaders.
Post a Comment