Random idea: When doing a local multiplayer game in Mark V (basically a listen server), could you make it honor the sys_ticrate setting? "force_ticrate 1" or something.

This would be handy for testing how your mod is going to actually run on a server, which will actually use the ticrate settings, as opposed to just running it on your own computer, where it will run as fast as your FPS allows, which alters the physics....

This could be useful to mappers too, for testing their maps -- the gravity physics behave differently when connected to a server with a ticrate, as opposed to when you're playing it on your own computer. For example, when a mapper creates a jump that is just make-able in the "single player" (local) environment, that jump can become impossible when playing on an online server (examples: playing online -- depending on ticrate -- you can't jump up the stairs out of the shallow water pit on e2m6, or out of the lava under elevator on e3m7). In FvF I actually change the default gravity from 800 to around 700 in order to make the jumping more like it is in the local Quake environment.

Anyway, being able to force Mark V use the ticrate setting locally would allow mappers and modders to test their stuff using the physics that will apply when someone plays online. Normally to do this, we have to set up a dedicated server then connect to that on same computer.




And I just wanna make sure you didn't overlook my additional report about aliases being discarded above: #657

I understand why one alias would be discarded (interpreted as a server stuffcmd alias), but why's it also discarding every other alias which was set after that point? 

Ticrate is an endangered species to Mark V.

At some point, Mark V will have fps independent physics, Spike's network compression and, likely, prediction available as an option.

Aliases: I took a shortcut and any aliases created on a remote server are purged. Including ones typed in the console while on a remote server (and then forgot I implemented it like that). Since aliases don't save to config anyway in regular Quake, someone would manually have to add them their autoexec.cfg (or what not) anyway. So this reminds that there is a little bit of unfinished business in that sense. 

I don't suppose there is a changelog that one can keep tabs on? 

That is an interesting question. The answer works like this ...

There are 2 types of projects:

1) Outside-In. Seeks popularity and attention. Wants to be easy to follow.

2) Inside-Out. Seeks quality. Meritocracy. <----- (you are here)
Interested in high quality participants and higher levels of engagement.

Each build has a list of changes in the build post so it is documented. Making things easy to follow isn't a characteristic of an inside-out project.

So is the name "Mark V", yields useless search engine results ;-)

Pre-calculated strategy to limit participation to the most knowledgeable A+++ contributors. Even the dozen 1 or 2 post contributors have contributed invaluable knowledge and insight.

/But when the WinQuake through GL build happens, I'll be sure to let you know. 

Think I'm wrapping things up roundabout now and am getting close to a code handover. I expect to have some further work to do based on feedback from that, but right now I'm pretty damn pleased with how things turned out.

A bunch of perf testing comparing with both the original version of the wrapper (in the original DirectFitz) and that in Mark V (which I wasn't aware used a markedly different version until quite recently) shows improvements on both. It's not going to be earth-shattering with lightweight (ID1) content, but should pull ahead more as the polycount goes up.

For the record, here's what's new/changed/improved/etc:

* Combine multitexture modes.
* Fog is per-pixel only.
* glCopyTexImage/glCopyTexSubImage for framebuffer water warp.
* Half-texel offset corrected.
* Polygon offset corrected.
* Scissor test.
* Shader-based gamma and contrast.
* Stencil buffer.
* Texture matrix.
* Vertex arrays.
* Vsync corrected.

The FitzQuake codebase I've worked on also includes sample code for the following (in what I hope is going to be relatively easy to port):

* Dynamic lights on moving brush models (Mark V may already have this, I haven't checked).
* Underwater warp.

These are both implemented using Baker's standard of clearly #defining the code changes so you can quickly and easily find them all.

As a nice bonus they also work in the GL build.

So I've some work left tidying up the interface and making it more conformant with what Mark V is currently using, but hopefully sometime over the next week I'll be doing a first code drop! 

On moving brush models sounds interesting. 

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