The bug has been in our code since the start (this particular code: in 2002) and was reported in 2005... so it's one of the oldest bugs that were ever fixed in openMSX, I guess...
So was it an Ashguine 3 bug as well, relying on certain VRAM initialisation, or did the bytes they do write cause the correct (invisible sprites) behaviour regardless of VRAM content?
Bug: screen border glitches and constantly flashes in red.
Tested on: openmsx-0.14.0-366-g5eeafd749-mac-x86_64-bin.dmg on Mac OS 10.13.6
Steps to reproduce:
1) Start openMSX in windowed mode
2) open the console and type:
set scale_factor 3
3) Close the console
4) Type CMD+F to go fullscreen
The screen border will flash like crazy in red/black/red. (around 20Hz, I believe)
I'm using the scale_algorithm "simple" and the renderer "SDLGL-PP". If I change to the rendered "SDL", this problem doesn't seem to happen, but then some garbage left on the outer border if I open/close the console on fullscreen.
Sylvester and Grauw, here's what our experts say:
< Quibus> I'm actually quite surprised that Ashguine 3 is the only game that suffered from this bug. I can't remember a single other issue that could be solved by this fix.
< wouterv> Quibus: it requires setting up sprite attributes that normally result in non visible sprites. I don't think it's something that a game would do intentionally
< mth> I'd actually call what Ashguine 3 does a bug
< mth> but it happens to be a harmless bug
< wouterv> it is. It uses uninitialized VRAM
sd_snatcher: thanks for reporting. It reminds me of issues like this: https://github.com/openMSX/openMSX/issues/1028 That is, we have several issues with full screen, but they're all inside the SDL 1.2 library we use (openMSX has no special code for full screen, it just toggles some flag in SDL, basically).
There's nothing we can do about it, but once we've moved to SDL2, I expect that these issues will be gone.
It seems to be the same problem, but manifesting different symptoms on different video drivers.
BTW, this glitch seems to happen on scale_factor 4 too.
Well, I found a workaround that avoids the glitch. If, before going fullscreen, the scale_factor is set to 2, then set back to 3 (or 4) only after the fullscreen is set, the glitch doesn't happen.
Maybe this workaround could be implemented on openMSX until the move to SDL-2 finally happens?
2) The F9 key will work fine if the console is closed. But when the console is open, only a square will be print on the console and the speed throttle won't be changed.
It also happens with other function keys, for example if you try:
