Correct. NumLock doesn't produce a RAWKEY event, but the key itself does with different values.
e.g. (This info is taken from the "learning" mode of AllKeys NumLock is ON (default), pressing "0" on the numpad gives $8100000F - RAWKEY - NumPad + 0 and $8100008F - RAWKEY - NumPad + 0 (upstroke) while NumLock OFF and pressing "0" gives $81000047 - RAWKEY - NumPad + Insert and $8100008F - RAWKEY - NumPad + 0 (upstroke)
So, i think the way to go is to check for the special Codes when numlock is in use and report that instead of a "global" numlock setting.
Not sure how that impacts on performance, but at least it would be something to work with?
@capehill
If you need here are all the RAWKEY combinations from Allkeys for the NumPad keys.
NumLock doesn't produce a RAWKEY event, but the key itself does with different values.
Ah, I see. You're right, when a numpad key that varies with the NumLock state is pressed, it's possible to deduce the state- if you get a '0' from the numpad then NumLock must be on, and if you get an 'Insert' it must be off.
That won't work with numpad keys like '5' and '+' that don't vary with the NumLock state though, and of course someone has to press a numpad key before you can update the state. That might be good enough, depending on what you're looking to do with the NumLock state, but it's not a general purpose way to know the current state.
@Capehill May i suggest a little thing ?:) : For the release versions remove debug output on serial , as it slow things very much when for example you start opengl/opengles2 apps because of massive output on serial about functions and stuff.
I.e. keep the debug symbols in, but remove serial output fully (for my local builds of SDL2_gl4es i doing that, so it give pretty much better FPS everywhere).
My builds have 2 set of libs, normal libs (.a/.so) that shouldn't have serial debug unless there was some mistake and their _debug variants for developer use. All these are unstripped of debug symbols too.
@Capehill Oh yeah, sorry all fine. I just all the time use my own builds from your repo, so didn't noticed that release version all fine. Tested now one from os4depot, and yeah , no debug output and all fast. False alarm :)
Did i understand right, that both libSDL2.a and libSDL2_debug.a have debug symbols in, i.e. unstripped ? Just libSDL2.a build without DEBUG output on serial. That correct ?
Because my version of libSDL2.a when i strip symbols and build without debug on serial are 1.2mb , instead of your which is 5mb.
Not sure if that related to SDL2, or to OGLES2/GL4ES differenes, but what i noticed now, is when i build ScummVM over GL4ES, and run for example GRIM Fardango game, in the output i have:
Quote:
INFO: OpenGL Red bits: 8 INFO: OpenGL Green bits: 8 INFO: OpenGL Blue bits: 8 INFO: OpenGL Alpha bits: 8 INFO: OpenGL Z buffer depth bits: 24 INFO: OpenGL Double Buffer: 1 INFO: OpenGL Stencil buffer bits: 8
If i build it over ogles2 directly, and run the same game , then while all works as before, output is:
Quote:
OpenGL Red Bits: 0 OpenGL Green Bits: 0 OpenGL Blues Bits: 0 OpenGL Alpha Bits: 0 Z buffer depth bits: 16 Double Buffer: 0 Stencul buffer bits: 8
I asked Scummvm's coder maybe he have a clue, and he said that "We get these values directly from SDL. I don't know why it fails to read. It's either a problem in SDL or OGLES2." Maybe you have an idea about ?
Please check with glSnoop and try testgles2. Red, green etc should work. GL_DOUBLEBUFFER triggers GL_INVALID_VALUE. It doesn't seem to be supported by OpenGL ES 2.0.
Yes, the getters are not really important: it's only debug stuff. For the setters, we try to set things up and if we get a usable context, then, we make use of it.
It's not that clean but it works, so except that you get strange debug information, it's not really a problem. :)
Anyway, now some interesting stuff coming.
If i compile scummvm with usage of FBO, then when i run GRIM Fandango i have that in debug output:
Quote:
OpenGL Red Bits: 0 OpenGL Green Bits: 0 OpenGL Blues Bits: 0 OpenGL Alpha Bits: 0 Z buffer depth bits: 16 Double Buffer: 0 Stencul buffer bits: 8
If i compile scummvm with DISABLED FBO, and run GRIM again, then debug output show me that:
Quote:
INFO: OpenGL Red bits: 8 INFO: OpenGL Green bits: 8 INFO: OpenGL Blue bits: 8 INFO: OpenGL Alpha bits: 8 INFO: OpenGL Z buffer depth bits: 24 INFO: OpenGL Double Buffer: 0 INFO: OpenGL Stencil buffer bits: 8
What did it mean ?
I do test on win32 for sake of test, and there when we with FBO, we even have just that :
As far as i can see, we back again to the same old problem called "when we hit alt+enter to swith to full sreen mode, then pure hit on the enter swith it back, while should't, and keys seems keys/mouse stop reacts correctly after". You definately fix it before, as i remember i report it and we do test it till it will works, but seems it back again and at least with scummvm and latest sdl2 build is surely there again.
Also, there seems another issue (not sure if os specific or not):
In brief, since some SDL versions, there issue with opengl renderes in scummvm (not sure if it all other platforms, but not win32) : when you swith to fullscreen, then you limited by move the mouse cursor in some square area, not in full screen. As i read its about SDL_SetWindowMouseRect().
SDL_SetWindowMouseRect: this function was not implemented on backend, so I wonder where the rectangle could come from? If you can get serial logs, I will take a look.
FBO-related: I don't know why there are differences. GL errors might explain 0 values, but since getters are not checked it remains a mystery without glSnoop logs.
Alt+Enter issue : i fear its on our side and we need to check this out more carefull. Why i think its on our side: because once i build scummvm with SDL_debug, there is _NO_ such bug. Alt+enter always works as alt+enter, and pure "Enter" never reacts like alt+enter does not matter how offten i swith to/from fullscreen/window. But once i use release version of SDL, then bug is here.
The difference is probabaly dprinf only , which an point us on some fight-for-resoures or something ?
@Raziel With alt+enter ? Yes, as i wrote in 2 posts above we have it before, and deal with it. But now issue is there again, but what is mystery, is that with SDL2_debug.a there is no such bug, but with pure SDL2.a from the same release archive, issue is there. Meaning that it can be some "fight for resources", where dprintf() auto-fix it in debug build (or just because of some delay, dunno).
EDIT: reproduced issue, it seems to be caused by combination of SDL_ResetKeyboard and syncing modifier keys during window re-creation.
1) SDL_ResetKeyboard clears ALT bit in "modifiers" table and "soft releases" all pressed keys 2) Sync sets ALT bit on (if still pressed by user) 3) When user releases ALT key for real, event is ignored because it's not considered to change keyboard state (see 1). ALT bit remains enabled and this is problematic 4) User presses enter, this is combined with false ALT bit
It's another thing how to fix it but luckily it was simple to reproduce so it can be debugged freely.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
