Makes perfect sense. No not worth the effort IMO. 

Maybe it's just me, but Mark V D3D9 starts to visually stutter on the default host_maxfps "72" when I'm moving and "mouselooking" at the same time. I normally play on 144, which is double the default, despite it causing physics bugs, so that's why I didn't notice it right away. Is there a special CVAR I could tweak or something I need to configure in the NVIDIA Control Panel? Or is it a bug? Doesnt't happen with Quakespasm btw, but that uses OpenGL.

Specs:
CPU: i7-4790k
GPU: GTX970
RAM: 16GB DDR3 800MHz Dual Channel (1600 MHz)
Main-/Motherboard: GigaByte B85M-HD3 R4

Thx in advance :) 

Sorry for the double post, but I don't know how to edit my posts. Do I need to register? Please forgive my ignorance.

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

Wild guesses:

Only mentioning it because Windows 10 is known to install miscellaneous apps/features without user consent.

I wouldn't normally post wild guesses.

1- Search "Xbox" in windows taskbar's search bar (Bottom left of your screen where Cortana is)
2- Click on the Xbox application icon to open it
3- Find the settings icon (a small gear) on the taskbar to the left side of the Xbox application's window and click on it to open the settings menu
4- Find the Tab labeled " Game DVR" and select it
5- Slide the switch to off to turn off the Game DVR feature.

Other miscellaneous:

"List of things to try
Turn off game dvr
Turn off Windows game mode
Windows advertising stuff.
Turn off in windows update allow downloads from other pcs " 

I loaded up Hipnotic and in the first level shot both sides of a thinner wall and didn't see a decal on each side.

c:\quake\mark_v.exe -game hipnotic -hipnotic +start

I believe you, but can't replicate it. Do you have a save game you could provide? Like look at the decal and type "save decal". After saving a game it would be in the hipnotic folder, in Mark V you can just type "folder" it will take you there and be called "decal.sav". 

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.