DRD Team

Gez wrote:One thing I wonder is if the people who have that crash also have it with plain old ZDoom.

because zdoom doen't have openGl rendering.

But it happens in a part of the code that comes from ZDoom and is used by the software renderer. That's why it could be fixed in GZDoom by simply not calling it when using the OpenGL renderer.

Therefore, it should also happen in ZDoom. If it doesn't, then the crash happens there because of some earlier interference from the OpenGL code, which would make it quite weird and very hard to effectively track back.

I'm more inclined to believe Graf about the self-modifying code thing causing access violations because of something that the driver is doing with altering permissions with the code space - which might also explain why it works when the executable is UPX packed because it's possible that it forces the executable into 'data' space that probably isn't being touched by the driver. (Though, this is only a theory, I do not know for sure).

Perhaps there's more than one instance of self-modifying code in the renderer? Perhaps there's more instances where code itself might possibly modify other code?

If any of this is true, any Duke/Build source port that isn't carefully written and includes OpenGL support might suffer these problems too, because as I recall Ken Silverman used a bit of it. (Didn't we get it from him, anyway?)

As Graf suspected, I can tell you that I did not have this problem in regular ZDoom, nor in GZDoom in software rendering mode.

TT