Re: Be careful of Sphere 1.6 screenshots
Reply #5 –
The screenshot mechanism is outside the graphics driver, totally inside the engine. It's using the same call as GrabSurface() uses, and then saving it.
I thought about this issue a while ago, and I noted a place in TurboSphere where I almost made this same bug appear. I based TurboSphere's old SDL_GL_Threaded screenshot code directly on Sphere 1.6's.
This is all based on but a skim of the code, but here are the two hypotheses I have:
* When you hit F12, it sets a flag for screenshots. This flag is checked when FlipScreen is called, and if it is set, we save a screenshot. This flag should be unset afterwards. For some reason, it isn't. This is the bug I saw in TS, but I find this the less likely reason, because...
* Some keyboards and laptops have keys that kind of aren't keys. For instance, some HP laptops have a enable/disable-touchpad button, some keyboards have bizarro media/application keys, which in SDL 1.2 trigger mismatched keydown and keyup events (no keydown, but still a keyup), and have no keysym. SDL2 fixed this, but before I switched I had to work around it.
I've seen the same thing but with different behaviour on old Apple eMac keyboards' eject and F13, F14, and F15 keys (which all trigger two keydowns and no keyups! Bad Apple!).
The screenshot key code is not as similar as you would expect to the other input code in Sphere. It is an ancient thing, added long ago. It's possible that your machine has one of these evil keys, and the normal input code can handle them, but the screenshot key code can't. Every time it polls the key, it's in some screwed up internal state, and claims that F12 has been pressed. This would also explain why I haven't seen this issue personally--my machines don't have keys that behave this precise way.