Sounds like a very nice feature set!

Is the depth buffer range ability used for mirrors included? The vertex array support will be a welcome addition, as will all of the other new functionality, of course.

I did modify the DX8 wrapper, but if I recall the changes were mostly organizational or to have more precise control over certain steps.

Dynamic lights on moving brush models

Yeah, has had that for a very long time ;-) 

thankee baker 

Depth buffer range should be working correctly now, yes.

Dynamic lights is just a fix for a long-standing Quake bug whereby if a door, plat, train, etc moved, it still picked up dynamic lighting from it's old position, not it's new. Check out the secret at the start of e1m4 for example. Give yourself the RL and fire a few rockets at the plat in it's starting position. Then trigger the secret, let the plat go down, fire a few more at it in it's final position. You'll see what I mean.

I knew there was a high probability Baker already had this, but I included it in the hope that other engines would pick it up too (e.g. QS doesn't have it) because it's such a basic feature and genuine improvement. 

Reminds me of something I should mention now, in the event you are interested in doing this:

A mechanism for rendering verts interpolated between 2 frames (factor of 0.0 to 1.0 between the frames). I can't recall the details of the conversation and insideqc is immune to Google searches. If I recall, you stated this is impossible by any means in Open GL 1.x, but quite possible in D3D.

/Mention because if you have thought about it already, I suspect you would later ... 

GL_ARB_vertex_blend.

The extension exists but I've never seen any hardware, either for real or in the various registries/databases, that implemented it. I suspect because any hardware that would support it also supports vertex shaders, which can also do the job.

D3D since at least version 8 has also offered the capability to do fixed-pipeline vertex blending, and hardware/drivers do support it. I did write code that used it once but don't recall the details. It was easy enough though.

IIRC stock Fitz does a lot of multipassing on MDLs and even if you didn't go all the way to hardware blending it wouldn't hurt to blend once only in software & cache the results for subsequent passes. 

Actually on reviewing the GL extension it doesn't seem to provide "tweening" capabilities, being limited to blending matrices instead.

So this seems to be another of the ARB's "we don't need the telephone, we have plenty of messenger boys" moments of glory. Sigh. 

Isn't something necessary or anything, just wanted to raise the thought. There may be a lot to test anyway ;-)

Looking at the code there is a per vertex color component that comes from a table depending the lightpoint value (dynamic light color where player is standing). I don't know how that easily gets into a color array, haha. 

IIRC stock Fitz does a lot of multipassing on MDLs

I think the fitz0.85 MDL code actually gets away with one pass, if you have the extensions:

if (gl_texture_env_combine && gl_mtexable && gl_texture_env_add && fb) //case 1: everything in one pass

-
Looking at the code there is a per vertex color component that comes from a table depending the lightpoint value (dynamic light color where player is standing). I don't know how that easily gets into a color array, haha.

Yeah - what I concluded when planning QS's r_alias.c updates was that, if I was going to go to the trouble of lerping in a vertex shader, the color calculation had to go into the shader as well.
Otherwise, I figured having the CPU still calculating lighting on every vert per mdl per frame (and still uploading data to the GPU every frame) would mean low performance gains for a lot of programming effort.

So what I ended up doing is passing in "shadevector" to the vertex shader - that's the fake light direction calculated from e->angles[1] and quantized, as well as the color sampled from the lightmap, and the lerping fraction. Then the shader replicates the lighting calculations that the Fitz code does on the CPU (except using MH's reverse engineering of anorm_dots, instead of the table itself, for convenience). 

aye, lerping verts on the gpu is kinda pointless if you're not also calculating lighting based upon it too.

ideally, use drawelementsindirect and throw 512 ents at the gpu per draw call, with atlasing/texturearrays or whatever for textures and SSBOs for the vertex data. you should get some awesome framerates that way at least when compared to other engines trying to render 10+k knights at a time.
actually using it without breaking everything else is more of an issue. yay compat... 

Makes sense, in the past I've wondered how much that calculation matters for objects other than the view weapon or extremely close items. In fact, I've wondered for interpolation whether or not floating point (0.0 to 1.0) is overkill for interpolation. 

In fact, I've wondered for interpolation whether or not floating point (0.0 to 1.0) is overkill for interpolation.

Floating point is likely going to be faster than alternatives on modern CPUs. By which I mean anything in the past 10 or so years. 

http://www.quaketastic.com/files/screen_shots/DirectFitz_D3D9_WindowResizing.jpg

Knew you'd be pleased :) 

That is very nice. 

As it turned out the wrapper supported it anyway (aside from changing a window style to allow for resizable borders in the reset code), it was just engine code changes that were needed.

The version of the wrapper used by Mark V also lacks one function (other versions of it had that function) that can reset the mode without having to recreate the window, but that can easily be provided if Baker wishes to retain D3D8 for any reason. 

#define R_LIGHTPOINT_ON_BMODELS
Include brush models in lightpoint calcs so that if you stand on a plat, train, etc you pick up light from that bmodel rather than from the underlying world geometry.

http://www.quaketastic.com/files/screen_shots/DirectFitz_D3D9_r_lightpoint_bmodels.png 

I've been fiddling around with some batch files that could use Mark V and its install command as an "easy button" for getting some popular Quake SP content installed. I've come across a bug/quirk in the command behavior:

Sometimes a zipfile does not have any top-level folder, and also does not have any pak or progs, but does have things other than maps (so it likely does need/want to be in its own mod folder). arcanum.zip and mapjam6.zip are examples of this; they contain lots of content aside from the bsp files, but the installer just puts the bsp files into id1\maps and throws the rest of the zip content away.

There's a few different ways to fix that if you want to. FWIW my own preference would be for the install command just to always put installed content into its own mod folder (or have that option available). 

Also something interesting I just noticed with installing warpspasm.zip. I see that there an "FMOD.DLL" file in the original zip that gets extracted as a file named "dll" into the warpspasm gamedir.

Haven't really investigated this yet, but this may be because most of the extracted files are in the "warp" subfolder of the zip, but FMOD.DLL is not. So when doing path-munging to get the base file name, Mark V may incorrectly skip over too many letters of the path. 

I wonder if there is a tutorial somewhere to add a better modelformat to FQ?
Im thinking to add a (simple) MD3 loader based on JoeQuake or even IQM..

Would it hard to add IQM to FitzQuake? 

I added IQM to the RMQ engine, which was based on a much older build of QuakeSpasm that was nearer to FQ.

The big constraint of IQM in the context of Baker's stated goal to not go beyond GL 1.2 is skeletal animation: it's just far too slow to run this on the CPU. Even as few as 3 to 5 moderately complex models in view will pull your framerate down to a significantly low percentage of what it was. Stock FitzQuake is already CPU-bound and the last thing it needs is even more loading.

MD3 should be easy enough I think (I've never coded it up myself so can't comment more) and MD2 should be very doable (it can even share data structures with MDL). 

@mh -

true lightpoint

I would be interested in using your implementation of getting the light from brush models as a cvar or a worldspawn key to activate it. There are existing maps that this change alters the lighting in an undesirable way so it was removed from Mark V, but also I never quite 100% trusted my 2012 implementation. But I can remember pulsar wanting such a feature and activating it via a worldspawn key (name? "true_lightpoint" "1"?) would be ok for sure for a map wanting it.

dx8 build after dx9

Yeah if you have an enhancement for dx8 ... I expect the dx8 build to existing in the project as unused separate build since it's just 1 file

I've been slowly trying to wrap up implementation of the other platforms I want to have builds available for one example.

@johhny

Thanks for the heads up on how certain specific files that don't contain primary playable Quake content or that weren't planned for in the installer.

About batch files, this reminds me that I should make sure Mark V can play demos via file association ...

c:/quake/mark_v.exe +playdemo "c:/path_to_file/mydemo.dem"

... which in theory I wrote, but in practice I have never tested. And since untested things rarely work ... I would expect it to not work ;-)

Same for ...

mark_v.exe +capturedemo "c:/path_to_file/mydemo.dem"

... which allows bulk capture of demo to AVI. But I haven't tested it recently and as untested do not necessarily work right, it may or may not do so.

@steve - Mark V won't be doing IQM, etc. and isn't suitable for total conversions, etc. Why not use an engine like FTE which does fancy model formats and can even run in a web browser and is built to support total conversions? 

@Baker:
Why im currently using FitzQuake is because my current project is based on an abandoned psp project which uses a customized engine from crowbar and porting it to pc would be basicially just copy/paste/modify my own modifications (so it basicially becomes a stand alone game using fq).

Using FTE would be a nice alternative ofc, but i dont know anything about csqc.. 

If you could, could you also have your alternate truelight point throw the (msurface_t *) it hit to a pointer and the distance?

Without looking, I think lightpoint has to return at a minimum the color rgb (which I think it puts in a global). It would be preferable for it to also return the distance, the model (model_t *) and the surface (m_surface_t *) to globals as well.

No obligation, of course. ;-)

/I figure since your knowledge of the .bsp is a few tiers of above mine, I'd mention this. My understand of the .bsp is not too bad at all, but is not on the level that I could write map compile tools in a timely manner or spec out a new .bsp format ;-) 

@gunter - I made a stab at making the blood fullbright dark red, but the existing particle texture is not suitable :( Not even reversing the colors, etc. The textures in question are rather hard-wired for "subtractive blending". So that imperfection is likely to live a while, unfortunately.

@steve - I hear you. And empathize. There are csqc tutorials at insideqc, I suspect you already know this. If even mh has trouble fully implementing iqm at a good framerate, any mere mortal (including myself) has a 0.0000000000 chance (plus my interest in iqm for Mark V is also 0.0000000000).

If I were in your position, I'd start learning csqc and switch to fte. 

If you could, could you also have your alternate truelight point throw the (msurface_t *) it hit to a pointer and the distance?

Without looking, I think lightpoint has to return at a minimum the color rgb (which I think it puts in a global). It would be preferable for it to also return the distance, the model (model_t *) and the surface (m_surface_t *) to globals as well.

They're all trivially easy & I took the opportunity to clean up the code a little too.

Interesting thing: this should also work for putting shadows on bmodels (because "lightspot", used for positioning shadows, also comes from R_LightPoint) but currently it doesn't. I'll need to debug that a little.

There's room for substantial optimization in all of this code. With r_shadows 1 R_LightPoint is actually run twice for each entity; cull tests and a few other things are also run twice. There's a whole block of work that should basically be done once only much earlier in the frame.

Again, this stuff is such that it's not going to grossly impact ID1 maps, but start ramping up the entity count and it will make it's presence known. 

o.O
the engine supporting csqc doesn't mean it MUST be used, you can still get quite far without it (eg: smc, tenebrae etc).