View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000262||GZDoom (All)||[All Projects] Bug||public||2017-02-13 15:35||2017-02-14 08:47|
|Summary||0000262: "Attempt to write to buffer of hardware canvas" fatal error when opening the menu|
|Description||When I press ESC while in game, the program gets the fatal error "Attempt to write to buffer of hardware canvas".|
It happens with sw renderer on Linux, though I believe it happens also on Windows if vid_hw2d is disabled.
|Tags||No tags attached.|
|I have absolutely no idea how this happens. Is it something new and if so, since when?|
|It happens since menu scriptification. I can't check which commit broke at the moment.|
|You can solve this by adding a canvas lock(true) at the top of DCanvas::DrawTextureParms and an unlock() at the bottom. That's how I fixed it in QZDoom.|
That would solve it on all backends, except DirectDraw, which has quite a complex locking mechanism and requires somewhat involved logic to switch between 3D and 2D.
I am really wondering if it is finally time to dump this code, we have already done lots of changes to bring the engine forward, this is really the last remaining piece of cruft for ancient hardware. Or may this break too many users on really old hardware? Currently the minimum system requirement is Windows XP SP3 which should be recent enough to assume that those machines have a basically functional 3D graphics card with first generation shader support.
I'd expect some people who actively try to make the engine work on Windows 98 not to be thrilled by such an outlook but this is a piece of code nobody here is willing to maintain anymore
Fixed. This was caused by the Ticker method calling a draw function, which is not allowed. In the 2D subsystem of the engine these events require strict separation.
@dpJudas, please remove your hotfix again, it will only hide genuine problems from anybody using the system later and not result in stable execution.
Okay, I changed my hotfix into an I_FatalError assertion checking if the canvas has been locked. Unfortunately this assertion triggers still after your Ticker fix was merged into QZDoom.
Call stack is as follows:
About the DirectDraw code: I know half the code in that target is more or less dormant because all places call Lock with a true to that 'buffered' argument. That's one of the reasons I decided just doing the lock always would be harmless, even if it wasn't the cleanest way of fixing this problem.
About removing DirectDraw: Since Windows 98 did support Direct3D 9 the only ones affected would be people with hardware having no GPU capabilities at all. But even half the Direct3D 9 code is a convoluted mess that cannot be touched because it is fallback code to dinosaur shader models that I personally have no way of testing. It was the primary reason I could not finish that viewport patch, because changing how this code works in any way whatsoever involved abandoning the legacy support.
|2017-02-13 15:35||Edward-san||New Issue|
|2017-02-13 15:46||Graf Zahl||Note Added: 0000561|
|2017-02-13 15:56||Edward-san||Note Added: 0000563|
|2017-02-13 19:56||dpJudas||Note Added: 0000570|
|2017-02-14 05:41||Graf Zahl||Note Added: 0000572|
|2017-02-14 06:23||Graf Zahl||Note Added: 0000573|
|2017-02-14 06:24||Graf Zahl||Status||new => resolved|
|2017-02-14 06:24||Graf Zahl||Resolution||open => fixed|
|2017-02-14 08:15||dpJudas||Note Added: 0000574|
|2017-02-14 08:31||dpJudas||Note Added: 0000575|
|2017-02-14 08:34||dpJudas||Note Edited: 0000574||View Revisions|
|2017-02-14 08:47||dpJudas||Note Edited: 0000575||View Revisions|