Anyone having input issues with the latest update(14.497)?

[Ian Price]

Anyone having keyboard delays/misses with the latest update of GLB (v14.497).

I'm writing a text based adventure game that worked fine before updating and going back to 12.XXX works well, but sometimes keys repeat, delay or are missed completely. Anyone else seeing similar behaviour?

[dreamerman]

Earlier I wasn't sure about that as I also use some inkey and custom functions for checking key state, but I have similar feelings, it only appears when using LimitFps (even on 60fps), with normal uncapped framerate and keyboard checking each 16ms (around 60fps) it's working properly. Didn't test if it appears only with latest patch but I have one game prototype built with earlier version of GLB that's using LimitFps 60 with vsync and it's working good.

[Ian Price]

I'm not using LIMITFPS as there are no time dependent features, but I'm definitely getting some issues. It could indeed be related to INKEY$ as I'm using that for input. Dunno. KEY(n) doesn't appear to be affected.

Thanks for the confirmation

Actually I've just noticed that the latest logfile for the update states "KEYWAIT" fixed - I'm guessing that this has had a knock-on effect in that it has now broken INKEY$

[erico]

I think not too long ago I read a very similar problem on the forum, will try to find out and let you know.

[AmazingJas]

I too noticed massive problems with this, had to revert to an earlier version. I was using limitfps. Experienced it on both Win 7 and Win 10 machines.

[spacefractal]

you can do a workaround using you own version of INKEY$ using KEY(). Im have not seen what the code really does in the function (and Gernot might should send the lastest source as well).

[spacefractal]

Please Note, Glbasic is NOT alone. Im got similar issue in KeyDelay issues even in AutoHotKey. So Windows must have broken some thing about that api INKEY$() using. So its could been more a Windows and not directly a glbasic issue.

We should create your own INKEY$() using KEY() instead, event on the command as well.

[Ian Price]

If it was just a Windows bug, it would affect ALL versions of GLB. It doesn't. INKEY$ is working in GLB 12.XX. Maybe Windows is fecked as well. Dunno.

Yes, we could roll our own version of INKEY$, but why reinvent the wheel? It's working in earlier versions of GLB, so no big deal. Just hope that Gernot fixes what he broke in a future update.

[spacefractal]

Auto hot key also Bugger to with extract same issue, also recently too, when I'm tried to remap game pad to keyboard. It's got very much delayed on some keys. Now I'm dropped game pad and used a real keyboard encoder.

I'm could take a look when time. But not sure I'm can do anything....

I'm also newer used inkey$, but allways prefer KEY(). The command can been strange sometimes. Even in Greedy mouse when I'm used Inkey$ like command for testing. I'm did prefer use my own function instead. So the issue must have been in very long time.

Same with print. I'm use my own font system.

Inkey might also not like keywait and key() me thinks and they may "steal" or improper input instead.

[spacefractal]

when im checking KEYWAIT (im have not the newest version)....

There is different between DEBUG and RELEASE versions. in the DEBUG release, its eill empty the INKEY$ as well. its seens not do that in the release version.

KEYWAIT should not effect INKEY, except if the fix was in the dxinput.cpp. Then something might have been broken. KEYWAIT is also quite strange. Its only wait when im PRESSING down a key, which is wrong behaiver for that command. Its should wait until the next keypress and then eventuelly send that keypress to the INKEY$. Its dosent do that, which is confirmed.

Until then you should use KEY(), which is not effected at all. But im want to know how im can invoke Scan2Ascii() in the dxinput.cpp? Then im could wipeout a simple workaround using that call directly in a inline.

[Ian Price]

I never use INKEY$ - it's just I needed it for a my text adventure. I always use KEY() in my games. In this case it's not necessary and would add a lot of needless code. I haven't used INKEY$ since coding on the CPC!!!

BTW I don't use print either, just my own bitmap font functions.

It's not a big deal and constantly saying "use KEY()" isn't actually resolving the issue. And It IS an issue. Full stop. Windows may also be buggered but GLB14.XX is definitely not right either.

I'm not expecting you to sort it out, but it IS a genuine bug.

[spacefractal]

It's just funny is same issue as in auto hot key issue I'm have. In a Extractly completely same malfunction behaveier. I'm not even sure it's was happens in a old version of auto hot key?

Very strange.

So... Glbasic is not alone and could been have been a new issue. I'm do not checked why it's happens here and its might only happens on some machines.

However there is still workaround, since you not know when thing got fixed and sometimes might newer did. I'm also did needed workaround various android bugs before it's finally got fixed. Few is still presents.

I'm also confirm keywait is not fixed. It's only works when key is pressed down. Also please tryout it's does same issue in the debug version. The code behaveier seens to been little bit different. Also I'm have not checked what Inkey really does in code in the background or what happens under a frameskip or such. Yet.

So something weird could have effected togheter. Property I'm can do nothing right now. Sorry.

All I'm can do is checking how scan codes can translated to char with a inline code. When done new Inkey function can been done in few lines. This is I'm checking later first. Workaround is better than nothing. Until that.

Ps. I'm deleted the next post. I'm are currently do a work around to been used until it got fixed.

[Ian Price]

Seems like a lot of work for you SF, for limited benefit tbh.

[spacefractal]

yes. im are not a advanced c++ programmer. howover this is a function that can been used as a workaround. im have only supported US keyboard for now. but other keyboard is very easy to been supported, if you read a keyboard.ini in your folder, so the keyboard layout can been changed that way. Im know this is not perfect, far away, but much better than nothing. what im should do is doing a system call to checking the visual scancode from Windows from the scancode. But im not sure how to do that.

its on purpose to hold the whole code into a the function. on some platforms, DIM static might require to been declared as GLOBAL...

But hey you have idea what im would do with this.

Code (glbasic) Select Expand


// a little workaround version of bugged INKEY$().
//
// Since im are not sure how TO detect the country keyboard layout (USA, German, France etc).
// Its best to read the layout from a inifile and put the result into those argument. example in this layout in the ini file:
//
//
// small=..1234567890....qwertyuiop....asdfghjkl.....zxcvbnm
// big=..1234567890....QWERTYUIOP....ASDFGHJKL.....ZXCVBNM
//
// you can also add extra keys and translate to chr values, example by using functions keys if you want. Something that is
// not possible with original INKEY$().
//
// Also this function might output more than one char, if two keys is pressed down same time on same frame.
FUNCTION INKEY2$: small$="..1234567890....qwertyuiop....asdfghjkl.....zxcvbnm", big$="..1234567890....QWERTYUIOP....ASDFGHJKL.....ZXCVBNM", skip$="."
STATIC i_scancodes[]
STATIC i_init=0

IF i_init=0
i_init=1
DIM i_scancodes[256]
ENDIF

LOCAL keys$=""

LOCAL keys[]
DIM keys[10]
LOCAL nr=-1
FOR i=1 TO 255
IF KEY(i)=1
i_scancodes[i]=i_scancodes[i]+1
ELSE
i_scancodes[i]=0
ENDIF

IF i_scancodes[i]=1 // here we could also eventuelly supports key repeat. but its up to you if you want.
nr=nr+1
IF nr<9
keys[nr]=i
ELSE
BREAK
ENDIF
ENDIF
NEXT

LOCAL ikey$=""
IF nr>-1
LOCAL letters$=small$
IF (KEY(42)=1 OR KEY(54)=1) AND big$<>"" THEN letters$=big$ // big letters, if required.
FOR i=0 TO 9
IF keys[i]>0
LOCAL ch$=MID$(letters$,keys[i],1)
IF ch$<>skip$ THEN ikey$=ikey$+ch$      // a letter
IF keys[i]=57 THEN ikey$=ikey$+" "      // spacebar
IF keys[i]=28 THEN ikey$=ikey$+CHR$(13) // enter
IF keys[i]=14 THEN ikey$=ikey$+CHR$(8)  // backspace
// you can expand it here with extra keys required, example F keys etc and use special letter to that.
ENDIF
NEXT
RETURN ikey$
ENDIF
RETURN ""
ENDFUNCTION


in a text adventure, you dont need to checking the full keyboard at all, and is property only in English anyway, but as im say the arguments in the function is designed so more keyboard layout easy can been added.

Please Note, INKEY$ here might return more than one letter, when two keys is pressed down on the same frame. The function is to been called every time by every SHOWSCREEN.

[Ian Price]

That's a nice function, but I'm just going to stick with using an older version of GLB - it works.