mh - Dabblingsquidward found that the decals in the Direct3D9 renderer through walls and this doesn't happen in Direct3D8 renderer 1036 build or the Open GL.

I'm think of trying to get out a comprehensive update of Mark V within the next 10 days after I can review NightFright's deal, get full Sepulcher in there.

If you have the the time and the opportunity to take a look at that in the next 10 days that would be awesome, but if not that's fine too.

http://www.quaketastic.com/files/decal.mp4 (video)
http://www.quaketastic.com/files/decal.sav

@(@mh) Dabblingsquidward

mouse - I really need to change Mark V to use RawInput, it may resolve the mouse issue you experience. Main problem is only so much time. 

I'm not going to be able to look at anything for the next approx 5 days (touring central Europe and drinking lots of nice beer can have that effect) but I am very interested in investigating any kind of state-related glitch such as this, so I'll be jumping on it first chance. 

touring central Europe and drinking lots of nice beer can have that effect

Enjoy yourself and have one for me! 

We have one of the highest densitys of brewerys in Germany! 

I have used several versions of the "Authentic Model Pack".

http://www.quaketastic.com/files/models/auth_mdl163.zip
http://www.quaketastic.com/files/models/auth_mdl17.zip
http://www.quaketastic.com/files/models/auth_mdl172.zip
http://www.quaketastic.com/files/models/auth_mdl171.zip

I can't get any version of Mark V from 1036 forward whether Direct3D/OpenGL/WinQuake to crash.

I load map E1M2 using pakz.pak after renaming it to pak2.pak.

My success rate has been 100% with no issues in any version.

I'd sure like to fix the issue you are experiencing --- but without being able to replicate it, I don't have any method of taking any kind of action :( 

Reminds me that I never looked at the decals issue... 

I have analyzed my file structure and found something that is probably the ultimate cause for the issue.

I am using an autoexec.cfg in my id1 dir with the following entries:

r_shadows "3"
r_waterquality "32"

What causes the problem is apparently the r_shadows entry. If I comment it out or even only change it to "2", the crashes will stop.

Please create a file as described above and test the issue again. I am sure you will experience my problem this way. 

The r_waterquality 32 has nothing to do with it.

The crash appears to be related to:

// 3984 is WinQuake asm maximum verts possible

#define MAX_LERPED_VERTS_3984 MAXALIASVERTS_3984
#define MAX_LERPED_INDEXES_12000 12000

If I increase the 12000 to 24000, it doesn't crash.

I am guessing that 12000 should instead be 3984 * 6 (23904), only because FitzQuake normally supported 2000 verts and 12000 must have been 2000 * 6.

This is my speculation, how mh's r_shadows 3 works is something I understand in a broad sense, but not in a detailed sense.

/End speculation, but the above seems to be fix the issue. 

I should have tried to run everything in a "clean" environment without any config files or other mods right away, my sincere apologies for that. :/

At least it seems certain now that it's not the new models alone that cause the crash, but using them in combination with this shadow option.

I guess it's still something that should be addressed since r_shadow 3 works just fine under normal circumstances. 

I suspected that it was going to be something like this, but when I did a scoot through a debug build about a month or so back I didn't see any evidence of the index list overflowing.

Strictly speaking the maximum number of indexes should be max triangles * 3, not derived from max verts, because any individual vert may be potentially reused an arbitrary number of times.

Even more strictly speaking GLQuake's MDL meshing function which converts a highly compacted triangle soup to strips and fans will mean that the generated mesh will potentially bear little relationship to the original in terms of counts. What I'm saying is that using the software Quake maximums as a limit on anything that comes out of the meshing function is asking for trouble. 

Anyway, in Scourge of Armagon, the SG & SSG leave one bullet hole decal every shot, these are rendered through walls in Mark V.

This is a problem with how polygon offset is implemented in GL and D3D9. (Don't believe 20+ year-old articles claiming that D3D doesn't have polygon offset; it does, it's just called something different.)

In D3D8 polygon offset is completely different, and probably doesn't actually work at all (at least in the context of MarkV), so hence that the problem doesn't seem to happen.

In D3D9 what GL calls "polygon offset" is called "slope-scale depth bias" and if you compare the GL spec with the D3D9 documentation you'll see that they're controlled by the same formulae. GL has the addition of an implementation-defined constant value which for D3D9 I assumed to be 0 (IIRC, I had good grounds for that assumption). Gotta love implementation-defined GL behaviour; what's the point of a standard if individual implementations can just do what they want anyway?

Another possibility is that I may be missing some state. In order to enable proper draw call batching in D3D9 I implemented lazy state changes where state doesn't actually change until a draw call is made; state change requests are tracked and only if a state change was actually required is a draw call batch finished, flushed, and a new one begun. It's possible, for example, that there may be interactions between polygon offset and depth testing that I hadn't considered.

That's something to work with. I'll update further as I find out more. 

Maybe I'll have to something to go with it soon. 

A workaround might be to disable polygon offset for sprites in the D3D9 build. Only temporary, of course, and it would cause z-fighting, but that seems less objectionable. 

I don't notice any z-fighting disabling polygon offset just for D3D9 -- perhaps because the decals are small, but the decal can slightly protrude off an edge.

Thought I might be able to be clever and switch it to glDepthFunc (GL_EQUAL) but didn't cause the "clip to surface" draw behavior.

But those decals are tiny.

/Causes me to wonder if hipnotic is the only mod that uses them. Almost certainly can't be the case, but I don't believe I have ever run across another mainstream mod that used them. 

A rather heavy update is coming in the next 2-3 days. I've stalled a bit on doing an update because I want the update to have what I want rather than do it in pieces.

(I've also had trouble merging code together with QuakeDroid ... some of merging it hasn't been entirely pleasant.)

Amongst other things, I have controller support which is causing me to debate whether or not do 2 player/4 player split-screen now.

(Except that would push things back maybe a week and I really want to do an update this week ...) 

THEN prioritize your split screen addition. I suggest this for selfish reasons. I've basically switched to using Mark V as my go-to engine over the past few weeks. I'd like to do a video on Mark V as part of my tutorial series and would love to do that over the upcoming weekend. (if the release is ready and stable ofc)

My 2 cents. I'll be doing a QuakeDroid video as well when that is updated. 

Split screen is a significant enough feature. If you're going to do it, if you're going to do it right, then it's worth a release in it's own right and IMO you shouldn't hold up what might otherwise be a significant essential release for the sake of it. 

Good to hear about a new release coming in for a landing!

Controller support is pretty cool. I'm in a phase of playing some couch/TV Quake, and Quakespasm is great for that but it's a little tedious to not have a level-select menu there.

Of course the complete set of "controller support" features would include a menu-y way to also choose the mod and any necessary game switches like hipnotic/rogue/quoth/nehahra... just putting that out there. :-) I know there are reasons that this has not been done by most engines, especially as a top-level menu item. 

Just fyi, my short list of things I consider must have in the release is fixing the unpacking bugs that you pointed out in a couple of .zip files that were packed differently than traditional .zip file releases. 

Ah interesting, yeah please let me know if you make changes in that regard (or just point me at the relevant sourcecode). I want to make sure my little batch file installer continues to work.

If you want to see the current list of things that it works around, you can have a look in https://github.com/neogeographica/quakestarter/tree/release/1.8/installers

There's three kinds of situations where I do something to change/fix files after doing the Mark V install:

1) The special case of making sure that quoth2pt2full gets put in a folder just named "quoth".

2) If the install puts things under id1, I move them into their own mod folder instead. Various reasons for that, but this is not necessarily a problem with the installer (unless there was a start.bsp, like with QUMP for example).

3) If the install fails to extract all the necessary stuff, or extracts some things with a truncated filename because of assumptions about folder structure.


Cases of #2 with a start.bsp: mapjam6, qump, rmx-pack

Cases of #3: arcanum, apsp3, dm4jam, func_mapjam1, func_mapjam2, mapjam6, nehahra, warpspasm 

Very helpful.

I think what I'm going to do is get an update out with what I have done now (I have 2 qmaster items I need to wrap up) and then next do a release with robust installer that handles edge cases and then go from there.

@mh - Yeah, I think I'll just get out what I've got rolling and due to the scope of 2 player/4 player split screen, do it separately. 

if the release is ready and stable ofc

The next release is going to need tire kicking before I'm satisfied that it is "stable".

But the next release should be incredibly robust and might even solve real old mysteries like killpixel's issues with WinQuake version lag (I hope).

I'll be doing a QuakeDroid video as well when that is updated.

Ironically, there is no way to do a QuakeDroid video myself. My phone ... which I love ... is an Android version that can't support video without rooting (which I'm not willing to do).

So a video of QuakeDroid would be nice because I simply cannot do it myself. :(

I went WAAAAAYYY out of my way, to make QuakeDroid as potent and usable as possible ... especially the console (<-- !!!) and the menu.

In past mobile Quake engines including other Android Quake engines, the console is microscopic, the menu non-interactive, poor ability to tune settings, etc. etc. 

controller note - a few days ago, I had the DirectQ source code open was about to more or less take the DirectQ controller support and put it in Mark V.

Then I had a funny thought, could the original Quake joystick code work if sufficiently enhanced. The answer was surprising.

I took the original joystick code and bashed it into a form almost indistinguishable to the very nice ericw/Quakespasm controller code, except it uses the original Windows API functions for axis/button reading. 

When the fov cvar is changed, which player will it affect?

Quake has several client-side cvars that were never designed to automatically handle multiple clients. chase_active, cl_forwardspeed, crosshair, r_drawviewmodel, and so on. And they're usually not binded to any keys, so there's no way to track from which client their value came. Also, some mods uses different default values for them, so if you create multiple copies of those cvars with different names for each player, those mods will be broken. 

You'll be able to look through the source code when it is released.