This bug occurs in the new file-type version. I am haven't tried reproducing it in the released versions.
Steps to reproduce:
- Start NL from the IDE and load a level pack.
- Go to the preview screen and start the level.
- While the game switches between the preview screen and the game screen, click a few dozen times as fast as you can.
- Then wait a few seconds, while the screen remains black.
Then I get an EAccessViolation, because some code wants to read an already freed resource. This occurs in TGamePreviewScreen.CloseScreen, on the line
GameParams.NextScreen2 := gstPlay;
or the one following it.
The call stack is very interesting, too:
TGamePreviewScreen.CloseScreen(gstPlay)
TGamePreviewScreen.Img_MouseDown($4A8448,mbLeft,[ssLeft],429,264,nil)
TCustomImage32.MouseDown(mbLeft,[ssLeft],429,264,nil)
TCustomImage32.MouseDown(mbLeft,[ssLeft],429,264)
TGameBaseScreen.CloseScreen(gstText)
TGamePreviewScreen.CloseScreen(gstPlay)
TGamePreviewScreen.Img_MouseDown($4A8448,mbLeft,[ssLeft,ssDouble],429,264,nil)
TCustomImage32.MouseDown(mbLeft,[ssLeft,ssDouble],429,264,nil)
TCustomImage32.MouseDown(mbLeft,[ssLeft,ssDouble],429,264)
... [and several dozens of lines like these]
It seems that we try to make sense of mouse clicks, as if we were still in the previous menu. I am baffled how this could causes so many stacked MouseDown events in one thread, but here you are...
Can confirm this happens in the backwards-compatible versions too. Most likely was introduced either when the windowing bug was fixed, or when the inability to switch between fullscreen and windowed without a restart was fixed. Have a good idea of why, will look into a fix.
Just pushed a commit which should fix this. I'll also release an experimental with this fix (as well as the fix for the ultra-fast RR change when paused, and with your new skill panel code) soon.