2 Obscure WinQuake fixes

[Baker]

[mankrip]

Holy f* damn. Thanks.

I'll try to get my old laptop working again to test this. This sounds exactly like the Bug I Could Never Solve™ in Makaqu.

[Baker]

[mankrip]

After looking in my code, I remember the bug #1. It only happens when frame interpolation is implemented, so that's why it doesn't crash vanilla WinQuake.
I've worked around it by removing the code for non-clipped triangles.

#2 is more like a tradeoff. The engine stops crashing, at the cost of numerous triangles going missing.
I've looked into it for a while and couldn't figure out what may be the exact reason for the access violations yet, but given that it's near the end of the drawing, it would most likely go away if I rewrite the MDL triangle drawing code to implement perspective correction.

I'll do more tests to see if there's anything else crashing my current code in comparison to Makaqu 1.3.1.

[Baker]

I'm going to do some more work catching situation #2 again and digging around to see what the errand situation is.

I'm rather confident that I can improve (or possibly perfect) fix #2. I'll see what I can come up with.

[szo]

Where does the crash happen, what backtrace does gdb give?

Is the only way to reproduce the crash is letting the demo loop to run a long long time?

(I'dl like to know whether hexen2 has the issue, and if it does I'd like to fix it there.)

[Baker]

I've found maybe 4 different crash points One for sprites (standard sprite draw, tries to write at row -1 on rare occasions) Possibly 2 that relate to MH's interpolation animation (write at row -1, haven't figured out root issue with the second one but I can stop it). One other one that I can't recall.

One effective method to neutralize these (whether or not fixed, but by doing so the ability to easily catch them) is marking the start and the end of the surface cache and check writes against that range. I'm not getting slow-downs by doing this, probably because the C codes optimizes well.

What I have done to trap these guys is run demos in higher resolutions using the C code and give it low cpu priority (results in larger host_frametime amounts). Some of them rear up quickly (Quake demo2.dem can get issues real quick), but some of them will not necessarily cause crashes immediately despite trying to write out of range.

I'll document it better the next time I have the opportunity. Hitting the sprite one made very irritated after I had managed to fix/evade 3 circumstances, another one showed up

[mh]

If it's related to the frame interpolation code, then it's probably because I never fixed up the condition for doing a trivial_accept. The quick and dirty solution is to just never do a trivial_accept.

[Baker]

[mankrip]

[szo]

[Baker]

[leileilol]

I discovered the crash happening in Quake 1.01 (yes this crash goes way back, errormessage spewing something about surfacecache) after trying a mod that spammed bubbles exactly at the view, where swimming backwards would trigger a crash. I kept reproducing this crash, kept debugging and managed to fix it around 2012 as well (without any knowledge of szo's fix).

Also, much like Hexen II, the mod was also programmed by Mike Gummelt. XD so props to him for coding stuff that triggers obscure engine crashes easily in '96!

[Baker]

Yeah, I remember you pointing out this sprite bug a few times.

[mankrip]