Yeah, I hear you.

Original QMB as witnessed in JoeQuake or similar engines, would actually override a custom flame.mdl with its own.

Allowing for no possibility of using a replacement model for flame.mdl at all.

One possibility among many is that I might at some point do the flame drawing more aggressively to not require my "sawed off flame.mdl" method --- the flame would acceptably draw over the part of the model that shouldn't be shown.

At the same time, one problem with the QMB flames method is it is tailored to pak0.pak flame.mdl. 

It is probably easy to resolve in the engine.

In a few weeks, I'll probably have my hands on a NVIDIA "gaming laptop" or 2. All my machines are AMD, including the Mac ones. :/ 

I had no idea how dirty you are ;) 

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