I've noticed that with the latest Mark V, it doesn't carry over my video settings (from id1 config) when playing a mod.

I used to have Mark V read those settings only from id1. Then someone said, I when "I play a mod, it ignores my settings I changed when I play it next". So I had to iterate through the proper Quake way.

Which might describe what is happening in the above.

To get it to be ideal (both!) would be bit involved, but I do have a plan for that in version 1.3, it's elegant and simple. It also involves some slight evil, but it's awesome kind people like and some other engine coder will say "Ah, that's ingenious."

Story for another time ;-)

my latest NVidia driver update

Let me know. Is it new for the driver or new for the version of Mark V?

They say NVidia's latest driver does flicker, but I'm not going to assume that it also couldn't be the engine's fault somehow in some rendering circumstances.

None of the FitzQuake derived engines have a state manager. Which means there can easily be an errant situation where something crazy like a glBegin without a glEnd or two of them or such other possibilities exist.

1) If the problem persists or exists without the current driver ...
2) Or if a previous version of Mark V doesn't have issue ...
3) Or if a certain map ...
4) Or certain combination of options ...

Short version is that at some point Mark V will have state manager, which would reduce the chances of the engine being at fault greatly (but a few other situations would still be possible).

Let me know if it persists and if it happens with a certain map or a certain setting on. 

It happens to me too. It has started once I switched to geforce 1060 videocard. It happens in both old and new versions of mark v on any map. I hope it helps.

And there's one minor issue about mirrors. I want to make a small map about mirrors. I placed two mirrors on the opposite sides of the room (I know it's not the way it should be intended, but it looks soo cool), you can't see them both at a time, they reflect well, but one of them turns off once I stand close the other mirror (touching it with player's back). I supposed that the second mirror somehow got in the view (but it didn't) so I placed a clip brush in front of it, so I can't get close to it. But it happens the same way once I touch that clip brush. And it always happens with only one of two mirrors (the rooms are completely symmerical), while the first one works as it should when I touch it with player's back. I tried it in two different rooms and the problem always occurs with the south mirror. The problems disappears once I get 1 unit away from the wall. 

It seems that the flame cut-off system for the QMB particles doesn't work on replacement models. I'm using this pack and the flame polygons stay:

http://www.quaketastic.com/files/models/auth_mdl163.zip

Another minor nitpick is that only the main Enter/Return key works in the menus, the numeric pad Enter doesn't. 

backbuffer.clear(depthandcolour);
for (i = 0; i < nummirrors; i++)
{
scene.addclipplane(mirror[i].surfaces.backplane); //ensures the mirror can only draw what is actually reflected, and not things that cross the mirror's plane.
//fixme: set scissor region
mirror[i].draw_reflectionof(scene);
scene.killlastclipplane();
mirror[i].draw_diffusetransparent();
backbuffer.clear(depthonly); //anything in the real scene should not be obscured by the mirror
for (j = 0; j <= i; j++)
mirror[j].draw_onlydepth(); //mask the depth so nothing further within the real scene can overwrite.
}
//fixme: reset scissor
scene.draw();

assuming I typoed it wright and you already know which mirrors you want to draw, the above algorithm should allow you to have cubes with mirrors on each face or whatever.

if you can make the mirror-list calcs recursive like in FTE(r_portalrecursion > 1), then you can get mirrors reflecting other mirrors. Just beware that if one mirror can see two mirrors then any further recursion will likely be exponential (read: really slow). 

here's some obscure territory

Quake is originally designed for 320x200 resolution to be run on 4x3 displays (just like Doom). This means, that whole screen should be stretched vertically. The original game nicely adjusts viewport so that actual gameplay window is always at true aspect no matter what resolution is set - 320x200 will look exactly like 320x240. But the UI is not. It is designed to be stetched, so it only looks right on 320x200 and 640x400 resolutions and is "squished" on every other.

So what's the problem? Mark V removed id's aspect corrcection and treat every resolution identically. Setting up 640x400 and 320x200 result in stretched in height gameplay window.

The ideal solution would be to add an option to make correct UI scaling. Here's some example shots of original winquake and Mark V scaled to 4x3 and upscaled

http://i.imgur.com/ZnPksXb.jpg
http://i.imgur.com/mJLsJH5.jpg
http://i.imgur.com/dWRoC5M.jpg
http://i.imgur.com/fj0f4aI.jpg
http://i.imgur.com/n8lznjF.png
http://i.imgur.com/tmH5eHL.png

http://imgur.com/a/jAW3U 

Right now, I treat Open GL and WinQuake identically (it's biased towards Open GL treatment).

From your screenshots I do see what you are saying. Thanks for providing screenshots. 

At some point like what Spike hinted at, I would like to improve the mirrors.

There are certain 3D calculations, reworked drawing, even tool support (.vis) and possibly some recursion that could make mirrors better.

Blocking a mirror with a brush doesn't necessarily help because Quake map vis truly sucks and does a relatively poor job (play r_lockpvs 1 and walk around and be prepared for surprises).

I'd like to put mirrors on 2 sides of a room too.

Limits suck and you can hope for better in the future, but right now you can't have 2 mirrors that can see each other according to map vis.

And it is worse than that, because in the current implementation there should not be a location where 2 mirror planes can be seen from anywhere in the map.

That being said, it still gives plenty of freedom to do awesome stuff with mirrors --- even with current limitations. 

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