Forgot to mention it, I'm on Windows 7 Home Premium x64.

This is probably common knowledge, but where do I upload saves and screenshots? Sorry for the inconvenience, please bear with me. 

I haven't used a free upload service in a while, if I recall this one is okish:

https://uploadfiles.io/

I'm on Windows 7, but I don't have a 144 Hz monitor nor a GTX970 

@Baker fantastic job, but would it be possible in the next release to rise The step left / right icons at the same level of the fwd icon. In my opinion this would lead to an increased playability. What do you think? 

 

Go to Screenshots and Beta post and at the top you will find login information for Quaketastic which is an ftp site you can use to upload forum related files. It has a web interface and you can scroll to the bottom of the page to login and upload. Welcome to func. 

Sorry for taking so long, but I just uploaded a screenshot, a save and a video, all titled decal to Quaketastic.

@Baker I only have a 60Hz monitor but still play with 144 FPS, because I belong to the (supposedly small) demographic of people who think that having more frames per second than your refresh rate looks smoother. I also disable V-Sync in all my games and limit my FPS (via NVIDIA Inspector, Bandicam or ingame) instead to get around the input lag and still fix possible physics, etc. issues.

@dumptruck_ds Thanks for the introduction, I love watching your Trenchbroom tutorials on YouTube and as you can see, I'm fairly new around here. I usually hang around the ZDoom Forums and lurk (have no account yet) on Doomworld :) 

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.