Mouse, Key Input - Erratic [SOLVED]
Archives Forums/Linux Discussion/Mouse, Key Input - Erratic [SOLVED]
| ||
| Hi, I have an issue where the game I am compiling works, but the polled inputs seem to be wild and get worse the more you apply input from the keyboard or mouse, I have come across this problem in a search of this forum but no solutions or even a reason why. My tween timing reports that I have plenty of free CPU cycles and holds the FPS to 60 on the nose. So the application seems to be running well. It appears if the inputs from mouse and keyboard are flooding in intermittently and tends to report the last key pressed as down when it is up. The same with the mouse, reporting the mouse button as down when it is up. The inputs also seem to stream in data then pause then start streaming data again at a regular rate. Any ideas on what to do? The code for my project compiles fine on Linux and runs on Windows with no problems. I am using Debian 7 64bit and BlitzMax 1.48. |
| ||
| I think that the input polling routines need a major over-haul as do a hell of a lot of other things. I barely use BlitzMax or GLBasic any more as it's it's getting to be more problematic with each new update or release of Linux. The most suitable for me at the moment for writing games is MonkeyX. |
| ||
| Do you use some kind of additonal wrapper? I did not recognize such an behaviour on my linux boxes - nor do some of my game players. I rely on the polled input provided by BRL for simple "KeyHit" thingies in samples but wrap it in a keymanager to enable blocking of specific keys and to allow "special" keys (€ sign etc.) bye Ron |
| ||
| @Derron As far as MOD's go for Linux I use BnetEX (Vertex) and oddmod (oddball). I don not suppose they are causing any problems but I will try to remove them and check. Aside from those two mods everything else is in native BlitzMax code. I did come across mentions of this porblem in this forum going back to 2006 with the same reported problem. http://www.blitzmax.com/Community/posts.php?topic=79196#889183 http://www.blitzmax.com/Community/posts.php?topic=65079#726461 I know very little about Linux but that first link mentions 'WSAD' keys (very similar problem) which makes me wonder if Debian's keyboard driver is incompatible with BlitzMax. I would invite you to look at this thread where I am having problems with the keyboard input. http://www.blitzmax.com/Community/posts.php?topic=99257#1164355 My gut feeling here is Mark is (and I think always has used Ubuntu) compiling BlitzMax in Ubuntu 12.xx and I wonder if the only way to be compatible with BlitzMax in its current form is to Stick to Ubuntu. In my case that means a new system as Ubuntu will not run on my two systems here (video issues). I am also wondering if maybe I should down-grade to a 32bit install of Debian? Could the 64bit version I am running now be a problem? The upside is my Project (Phoenix USC) compiled and ran beautifully except the above problem. Edit: I am using KeyHit(), KeyDown(), GetChar(), MouseDown() and alike. All native BlitzMax commands to get device inputs. @all I am willing to tear into this problem if anyone wants to have a go at a solution. :) |
| ||
| Hmm Could you reproduce that in a simple sample code? I do not use "getchar", so I do not play with the "blitzmax queue" of input characters. Do you use "maxgui" ? I do not use it in any of my programmes. @regarding compilation: For now I created a virtual machine in virtual box with "xubuntu 12.04" so it should not have glibc issues and "xfce" is not using much memory, so the machine is happily compiling with 512mb ram and 1 core (I even got 20 of 30 desired fps with the emulated gpu :p). Just setup a shared folder for the machine (in virtual box) and within the virtual machine you add your user to the group added by the guest addition (vboxsf is the groupname) so you can access your data via /mnt/sharedfoldername ... which makes it easy to code on your local box but compile the real binary using the old 12.04 ubuntu base. Edit: even if it does not help you know, but once Bruceys SDL-mod is working (dunno if it works with vanilla...) you could use SDLs windows + input management - maybe they are not that borked (if it is faulty...). bye Ron |
| ||
| Hi, Nope no MaxGUI. It causes problems in Linux from my experience. I will try setting up a Virtual Box and try installing Ubuntu 12.xx 32nit on it although I think 14.xx would work as well and I will have to look in this forum but Mark may have compiled BLitzmax 1.50 in it. Do you have a link for a good Virtual Box? Oracle I think? I am now just getting to the point time wise to start working with Brucey's new toy's ;) So I will scan for info on 'Bruceys SDL-mod'. Messing around with my code I can see that the keys (mouse as well I think) literally just keep reporting the last key pressed. In my case using the arrow keys to move my ship around I can see pressing any arrow key will just keep reporting that key as press down until I choose another. The same goes for the mouse. Clicking down on the mouse button will cause it to continually be reported as down. Even clicking on another mouse button will not change this. So from my point of view BlitzMax is either not clearing that key/mouse input form a buffer (or variable) or the keyboard/mouse drivers work in a way not compatible with BlitzMax. I guess my question here is what is the preferred keyboard and mouse drivers for BlitzMax? Where might I look in BlitzMax's mods/code to try and modify and perhaps fix this issue? It seems to me this might have a simple solution somewhere in the mods for BlitzMax. Edit: I should mention that this is not a USB keyboard or mouse. One other issue is that on a smaller less CPU resource hungry build the mouse and keyboard seem to work OK. For example Digestiroids seems to work ok. - Rich - |
| ||
| "Virtual Box" ... else I would have called it differently :D @cpu hungry things: Maybe you should try to poll the system or so ? Maybe some issues of not asking the system on a regular base. bye Ron |
| ||
| Hi, in some testing Digesteroids runs OK and looking over that code using Flushleys() stops it from endless key down streams. But causes other issues that I might be able to work around for example once flushed holding down the arrow key I don't get a steam of arrow key down messages and KeyDown() acts like KeyHit(). The same goes for mouse buttons, if I flush them things improve, but flushing causes problems in my code. So using Flushkeys() and Flushmouse() fixes the problem of endless key/mouse down data but presents other issues. It appears that there is a difference between the way key/mouse input is recorded in Linux. In Windows I can just use KeyDown() and when the key is not down it gets reported that way. In Linux the key down is never reported as back up. So flushing the keys and mouse is the only way I figure to work around this issue. I'll see if i can somehow workaround this. Edit: Very odd problem and I think more to it then flushing key/mouse data Edit 2: Where I wonder in BRL mods should I look for mouse / keyboard input. polledinput? |
| ||
| once Bruceys SDL-mod is working (dunno if it works with vanilla...) uh.. me neither. SDL input stuff is pretty solid - there are lots of people working on SDL (and a large number of people using it for their games) so it is updated often. Now, whether I've done a good job of plugging into the BlitzMax polling stuff is another matter altogether (it worked for things like digesteroids, so it seems at least on a basic level it is doing the right things). What do you use GetChar for? |
| ||
| Do you happen to have a little example which shows what kind of issues you are experiencing? The examples in the posts you linked to appear to be MaxGUI-related stuff. |
| ||
| Hi, Do you happen to have a little example which shows what kind of issues you are experiencing? I will soon here. Right at the moment I trying to figure out why both the breakout and digesteroids examples work. So I am adding some of my code to them for example my GUI code. I am not using any hooks or anything else not usual. All of my code uses as few native BlitzMax commands vs. Money-x for easier porting, So nothing funky code wise. The examples in the posts you linked to appear to be MaxGUI-related stuff. Yes and the problem looks and feels just like MaxGUI is in and running. I am not including it " Import maxgui.Drivers ". Is it included anyway? Do I have to define frameworks to exclude MaxGUI? |
| ||
| > Do I have to define frameworks to exclude MaxGUI? No. |
| ||
| OK. Thanks. |
| ||
| Is there a reason you not using latest BlitzMax (1.50)? |
| ||
| There is. It will not run on Debian 7: http://www.blitzmax.com/Community/posts.php?topic=102717 As far as I know the problem still exist in above thread. Ubuntu will not run on either of my two systems because of video problems. Can not even get installed. Looking into a virtual box, but I am wondering if the same video problems will be an issue in a V-Box. Plus is there a difference regarding this issue between 1.48 and 1.50? ie: a fix? |
| ||
| I suspect not, I was just curious. |
| ||
| OK, I am trying to isolate the issue. At least find what could be causing it. Right now I am adding mods to some of the samples to see if they might be causing an issue. Of the two (oddmod, Bnetex) BnetEx has the highest potential to be an issue. So far including (Import) the mods in examples has no ill effect In my code I can run a loop to test inputs after all initialization has occurred and right up to the main loop. If i just have a loop reporting key presses all is well. If I use any functions or methods the issue becomes evident again. All I can think to do at the moment. |
| ||
| Bnetex does not cause issues ... I am using it too (broadcasting game data through x.x.x.255 broadcast ip addresses). It does not interfer with input data. @1.50 1.50 only removed a potential crash when some rem...endrem was used (i reported this bug.. and it took a while to narrow it down, thats why I still remember it ...lie... I remember because I reportet it :p). @maxgui I thought of maxgui too (maybe some odd polling of input states). All in all I think you use some thinks which "together" start the trouble. I do not have it, nor do people have reported it to be broken. Because of my playerbase only consisting of some hundreds of users the "debian user"-count might be < 1 ... so I cannot assure things. So it gets more and more important to fiddle together some kind of "show off example". Especially that "GetChar()" is of interest for me. I personally am only using "KeyHit" and "KeyDown" - and for now it works flawlessly on my "ubuntu" based boxes (xubuntu and linux mint xfce). I know of one user who is running "Knoppix" (which is based on Debian) whose only trouble is "PulseAudio" ... which means I have to build one "NoPulseAudio"-binary because it else starts problems on his machines. But input-wise everything is running as it should (I have some keyboard-dev-shortcuts to move in the game world). bye Ron |
| ||
| @Derron Well good news on BneteX. I use it for UDP and TCP so it gets a work out especially running server/client on UDP and TCP on IRC, server listing and reporting. I don't see how oddmod2 would effect it either but simple enough to test that. So far no problems. I will have a look at Getchar() maybe experiment with it. My project is fairly massive with a GUI system, game engine and other support frameworks. They all compiled just wonderfully in Linux as I have written it to do so along the way. As soon as I can find the issue I'll post some code. I'm in a situation where see no problems with my code, which makes it tougher. Thanks as that is useful input. ;) |
| ||
| What do you use MaxGUI for? |
| ||
| What do you use MaxGUI for? I do not use it. I wrote my own window based GUI system that uses no hooks or pointers and is compatible with Monkey-X (not tested but should work fine). Written in all BlitMax native code. I do use MaxGUI for my world/map editor but not in my game which is where the issue is. As soon as I get ahead of the curve I will post the GUI for all to use. It just needs some cleaning up and documentation. It's fast and has the basics to cover any game application like sliders, buttons list boxes. All based in windows that move, resize, manage what you draw to them, set view ports and more. You can draw in real time to a window or draw once and have the window system mange it. Anyway I love it mainly because it's fast and portable and manages anything drawn on a window . You can see it in action in some of the videos and images I have posted about Phoenix USC. Here is an older video. Interfaces at the beginning and the end of the video. https://www.youtube.com/watch?v=NCzItEu6UbM#t=225 |
| ||
| Does this GUI poll key states? "KeyHit()" resets after you check it! So once you called "if KeyHit(myKey)" a loop, it does not get true until it is hit again _in_another_cycle_ (after next polling of input states). KeyDown() does not behave that way, it just returns whether a key is down. So please check if and how you use "KeyHit()". That is btw why I use an keymanager which saves the states of all "down keys" and handles "hit" on its own (and keeps the state for the current cycle). @GUI do you handle Drag-n-drop? Was the most difficult part in my gui system (which has dragndrop for all gui elements which are various lists, dropdown boxes, inputs, checkboxes, panels, ..., too - needs a big overhaul somewhen) bye Ron |
| ||
| KeyHit returns the number of times the key was hit since the last time you called it. |
| ||
| @Derron Nope I do not check the key state in my GUI. I do however check mouse states with MouseX(), MouseY(), MouseZ() and MouseDown(). With my issue the key state is constantly reported as true (or key down/hit). You do bring up a interesting point, KeyHit() does 'not' rest the key state. So pressing down any of the arrow keys and then running the following still reports key state true when polled.
For Local Key:Int = 0 To 255
KeyHit(Key)
KeyDown(Key)
Next
KeyHit(KEY_UP)
KeyDown(KEY_UP)
KeyHit(KEY_DOWN)
KeyDown(KEY_DOWN)
KeyHit(KEY_RIGHT)
KeyDown(KEY_RIGHT)
KeyHit(KEY_LEFT)
KeyDown(KEY_LEFT)
So if KeyHit() is supposed to reset the state it is not. I'll be working on this issue today and poking around. I am also sending a copy of the Linux build to a few beta testers to see what it does on their systems just rule out any wackiness on my own. GUI ----- My GUI code is broken down into two frameworks; the button, slider, gadget framework and a separate window framework. This allows for a high degree of flexibility as if you just need GUI components (slider, list boxes, buttons) you can use that framework. If you need windows you can use both frameworks together. So I can use the GUI components framework to have say a slider drawn to the back-buffer or hand that slider a window handle it belongs to. I can also use a custom lists of component objects (buttons, gadgets) the GUI system will use, This has the advantage of letting the GUI system manage your GUI components and within say a games code you can use that custom list to check all the component states. So Instead of going through a list of every button the GUI system manages, you can just use your custom list of components to check the button states. This works well for when you want to check states of all the components associated with a window, you just walk through your custom objects list, Great for a speedy GUI. I've not added drag and drop at the moment but I do not see any real issues as the GUI system manage images and text sent to it. So drawing an image is essentially handing off the image object, position and other data to a window. The GUI system will manage that image until it is removed. I can also just send the image to a window for onetime use as if you were drawing to the back-buffer. The same method is used for text where I can additionally set a font for the window. So potentially if you were to drag an image object over a window (already commands available to know that) you could added it to that window and the only concern would be it's z-order. Edit: I would add that I do not see a problem with dragging over GUI components to a window either as once dropped you could easily set that components window to the new window and also it's position and other data. I may try to do this just to see it work. :) Anyway the system is super fast and flexible. you would hardly know it is there CPU/Video resource wise. |
| ||
| Richard, are you creating multiple graphics contexts such as using a splashscreen? I would continue trying to reproduce the issue by modifying a simple example if the standard example programs work without issue. I suspect this is to do with the particular window manager you are using. BTW What window manager are you using? |
| ||
Keyhit :Function KeyHit( key ) If autoPoll PollSystem Local n=keyHits[key] keyHits[key]=0 Return n End Function Most definitely resetting the count in my version. |
| ||
| @Skidracer Richard, are you creating multiple graphics contexts such as using a splashscreen? Noope. Just one. I use a client launch application (setup - servers - game launch) that kind of does the splash on it's way out when launching the client (demo). The client launch application actually seems to run OK. It uses the GUI components framework of the GUI system. I suspect this is to do with the particular window manager you are using. BTW What window manager are you using? Hmmm. Well I am not using any if I understand correctly. The window portion of my GUI code is custom written and does not reach out to the OS's GUI but is all internal to the application using it. At this moment I'm putting the Breakout example into a window (again internal not OS) using my GUI code to make sure that is not the problem. Just testing that portion to make sure it works fine. It's a very odd problem as the examples I have tested work and even my launch app works. I have scanned my code for KeyHit() and any other input related code to try to isolate the problem. I just don't see how code wise I could be getting key and mouse inputs to constantly report true or down. The key and mouse states start off false but then once you press the mouse button or a key the state will never be reset. @Brucey That is good to know and I will try to get a V-Box up to day and try it on hopefully Ubuntu. If successful I will install BlitzMax 1.5 and see how it goes. I'm going to also start with a fresh copy of 1.48, rebuild mods and see what it does on this Debian 7 system. Also if I get Ubuntu going V-Box I can take a stab at compiling it on your new toy (/me likes that Burcey shares his toys). :) |
| ||
| Sorry, I meant what desktop manager? As in gnome, KDE, xfce etc. |
| ||
| ^Gnome ;) |
| ||
For Local Key:Int = 0 To 255
KeyHit(Key)
KeyDown(Key)
Next
KeyHit(KEY_UP)
KeyDown(KEY_UP)
KeyHit(KEY_DOWN)
KeyDown(KEY_DOWN)
KeyHit(KEY_RIGHT)
KeyDown(KEY_RIGHT)
KeyHit(KEY_LEFT)
KeyDown(KEY_LEFT)
translates to this: For Local Key:Int = 0 To 255 'KeyHit(Key) If autoPoll then PollSystem keyHits[Key] = 0 'KeyDown(Key) If autoPoll then PollSystem Next 'KeyHit(KEY_UP) If autoPoll then PollSystem keyHits[KEY_UP] = 0 'KeyDown(KEY_UP) If autoPoll then PollSystem '... Which is a big bunch of "PollSystem". Normally I would suggest to prepend "DisablePolledInput()" before above's calls and then PollSystem() when needed, but I am not sure what the hook in PolledInput.mod/polledinput.bmx does ... because it even is needed for things like "AppTerminate()" to work (which I think could be started by input or (?) external apps). But "DisablePolledInput()" is normally "private" (according to function 'comment). Also "autoPoll" is private and not adjustable without modding the module. So the only way to achieve similar thing is to copy code from it. I made a simple sample application showing key states and allowing to enable/disable auto polling and/or resetting keyHit-states. Maybe it is somehow of help to narrow it down to "pollSystem" (and things like the xwindow's getXKey() calls) bye Ron |
| ||
| Hi, I have it working. ;) I have know idea really what I did, part of a sequence of upgrade, scripts and updates. There was a backlog of updates (like 272 - OMG). I have had hardly a reason to jump into Linux and well.. long time. After recompiling all the modules it seems to work awesomely. If it were not for this little hick-up the code would have compiled right from the start (slight comment out code). Just a joy to see it run on Linux. Thank you for helping out a Linux newbie. edit - I am so totally stoked to get the server going. :) |
| ||
| @updates But this means that there must have been some flaws in the past - it sounds as if your machine was running as if it run in january 2014 (or so) - which means, people would have had trouble with bmax at that time... Did you have recompiled modules at that stage too - or did you use the module binaries of the bmax download? bye Ron |
| ||
| The problem existed in a previous version but was not as apparent (not as far along dev wise). So I think it has been there all along. I did recompile then (only 'build modules' I think) but as I noticed the problem existed in the past, just not as apparent. It probably was close to early 2014 the last time I messed around with a Linux build. Did I mention Linux newbie. :) |
| ||
| This implies that there was a bug in previous versions. As "ubuntu 12.04" is what others suggested to use for compiling (because of glibc-version-problems: building with newer ubuntu boxes lead to trouble on other - older - distros) is older than "2014" i am not sure if you would have your input problems still existing there . I suggested somewhere to install an xubuntu 12.04 into a virtual box VM and compile from there (of course a dual boot linux offers the real-hardware-tests you should do from time to time). Also Linux binaries get some kilobytes shaped off when compiling with that older gcc :p (newer ones also need a "strip --stripall binary" because they somehow contain more unneeded stuff for release builds than needed). bye Ron |
| ||
| .. strip --stripall .. That depends if you intend to get some kind of useful error information if the application crashes. |
| ||
| With 12.04 my "stripall" does not provide benefits, filesize keeps up to the same. With 14.xx my binaries get bigger after compiling. Stripping is lowering filesize from 7 to 4mb for a single binary. With debug builds the filesizes are somewhat bigger (12mb unstripped I think). Is the "unstripped" release build of use (I mean, does it name the bmx function call - or something from the asm-output bcc did?) ? bye Ron |
   |