Leaderboard

... and some last words about this bug : actually the reason why I couldn't reproduce it is simply because in my saved settings the profiler display is almost always enabled (the 3rd one, the one with % numbers), that's the f11 key, and this key would have fixed the green screen bug too if you had used it because by default it uses opengl text, and so it calls glColor to set the color of the text to white, this time it's normal behavior since the text is monochrome, the non standard behavior is for color pixels of the game bitmap. It works also for the f1 key (reset) because you get some texts at the bottom of the screen to tell about the cpu(s) being reseted, and so it calls glColor too... So if you had had a simple profile display enabled in your settings you would probably never have seen this bug, but yeah most of the time you install to a new dir so it's back to default settings all the time... Everything is solved !

And finally went to the bottom of it, there is a weird difference between the opengl implementation in windows and in linux, I don't know why, this thing is supposed to be standard, not made by microsoft normally... anyway what happens is that the draw color, set by a super standard function, glColor affects the pixel operations in windows, but not in linux ! When you know it, it's very easy to work around it, just set the drawing color to white when the opengl drawing starts, which means just 1 more function called when the "play game" option is selected, almost nothing. With this I can finally remove the 2 workarounds there were for this very stupid bug. It's committed, but it isn't worth a new binary just for that !

I got curious and did some more inquiry about this : finally the draw color & blend mode don't seem to matter, because they are not directly used. These functions are queued and executed directly by the video driver, so there is really some difference between what windows does and what linux does here, but not sure what. Linux also uses the opengl driver by default. So it's just a mystery, probably related to some low level driver stuff here. The good news though is that the behavior is correctly emulated by wine, I get the green screen when running the windows binary in linux through wine, it makes things easier to test at least ! So the only workaround which seems to work is the one which I used so far : finish the drawing with a white line so that the color is reseted and does not affect opengl blit operations. This was a really crazy bug for something which shouldn't have created any problem (it's just a basic drawing primitive, nothing should go wrong with that !). Anyway I stop here.