mmm I'm not sure if this will help, but I have a Swing user interface and when I press the button with an actionlistener it will not recevie any further input in-game. So I threaded it and it worked fine.

I wasn't using Jinput though sorry but maybe the same thing?

EDIT: spelling and also to clear up things more... I Threaded the call to start the game.

Hi When it crashes you should get a screen full of information, a stack trace, and maybe some native debug, copy and paste the whole lot into here and we *might* be able to help. The buffer over flow message happens when there is more information than the buffer can hold, there are 2 options to get round this. 1, if enough people report it I can up the buffer size in the native code. 2) poll more often, this should read the data before the buffer gets full, if you don't poll the buffer fills up till it over flows.

This output comes at the beginning (before crashing), and nothing more appears.

When I said crashes, I meant "freezes". Does it make any difference?

Polling more often doesn't seen to solve this problem... The main thread was sleeping only 20 milliseconds. I changed it to 10 e the results was exactly the same. Anyway, 20 millis is fast enought, isn't it?

To free the buffer what I have to do? Is calling "poll" enough, or I have to call "getPollingData" for every axis?

Hi Ok, freezing rather than crashing is a huge difference. In the jinput jar there are some test, can you run net.java.games.input.test.ControllerTextTest or net.java.games.input.test.ControllerReadTest ?

use the same classpath and start directory as you do for your app and those should run. ControllerTextTest will dump a whole heap of stuff to the console, copy and paste the lot in here please , and ControllerReadTest should open up some windows (one or more per device) and show axis and button values changing as the device is used.

How many time do you get the DI_BUFFEROVERFLOW message, rougly, once, once a second, or more?

Hi The controller read test uses swing, so it can't be that. There must be something in your app thats causeing it. maybe you could put your source on a website somewhere and link to it from here.

As for the DI_BUFFEROVERFLOW, if it's only happening once, I suspect that whats happening is JInput is being initialised and then it happens before the first poll, after that you poll frequently enough not to fill the buffer, but the time between initialisation and the first poll is too long, there is probably very little to worry about with this. Unless you start seeing some strange behaviour, you can probably ignore it for now.

The ControllerReadTest uses swing, but only panels and labels. My game was fine when I was using just that too. But when I put a JTextField there... So I'm still thinking it's a Swing / JInput issue.

The project I'm working on is an open source turn-based strategy game (artofwar.sf.net). It is hosted on sourceforge, but the code in the CVS is the one with wasn't freezing (and had no JTextField in it). I'll feel bad if I commit a broken version.

About the DI_BUFFEROVERFLOW, you are probably right (it really makes a lot of sense! ), and maybe it hasn't anything to do with the problem at all... And I'll surely ignore it for now.

Just thinking... can the AWTEvent queue and/or the use of some event listeners have something to do with this problem? I use jinput for processing keyboard, but I use mouse listeners to help processing the mouse input.

I found the error, and it really doesn't have anything to do with jinput... Thanks Endolf! It was a deadlock in the event dispatch thread X my custom painting code. At least I've learned about the DI_BUFFEROVERFLOW.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org