Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (537)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / JInput / Small driver program for jinput's joystick code on: 2011-02-09 03:51:00
I've written a small set of Java classes that I've used to teach myself jinput, and to test how my Logitech 3D joystick works. Its open source, and may be useful to some other beginner.
http://pfarrell.com/java/joysticklib.tar.gz

It was written using Netbeans, but should work with any setup that can use the ANT scripts.
2  Java Game APIs & Engines / JInput / Re: Tempoary: Patches for javadoc thread on: 2011-02-09 00:53:08
Also, javadocs should never contain questions! Either figure it out or ask someone else.

I was assuming that whoever was doing the commit would either know the answer or remove the question. So rather than having a separate thread on the detail, I just put the question in the code

It was not clear from looking at the java code what the answer was.
3  Java Game APIs & Engines / JInput / Re: is LinuxJoystickPOV not subclassed from Component.POV? or am I doing this wrong? on: 2011-02-06 03:39:33
Looks like the constant I want is available with:

Axis.POV.getName()

or fully qualified:
net.java.games.input.Component.Identifier.Axis.POV.getName()
4  Java Game APIs & Engines / JInput / Re: Timing for pooling loop, and Multi-threading for polling on: 2011-02-06 03:12:32
From looking at the code, and debugging the software on my Ubuntu 10.10 system, it appears that the default implementation sets the EventPool size to 10. This would then set a hard limit on the number of Events that can be obtained in a single poll() call. Which would, in turn, set a upper bound on the polling interval. Clearly you don't want to have the queue fill, so you have to call poll() often enough to capture all events.

its not clear how fast they can be generated. For a mouse's buttons, or triggers on a joystick,  human's can only fire fairly slowly. A reasonable limit might be 10 clicks/pulls per second. A good typist may type 120 words per minute, which is only 2 words per second. At six characters per word, you have only three characters per second. So three times that would seem to be a reasonable guess. (Not counting, of course, the Korean professional Starcraft folks, they have amazing key abilities).

Rolling the mouse, or moving the joystick, can cause lots more events, far more than trigger pulls or mouse clicks.

In my testing, I don't see any noticable diference between a 50 millisecond poll rate and a 20 millisecond rate, except that the CPU usage is a lot higher with the shorter rate.
5  Java Game APIs & Engines / JInput / Re: Clarifying the Javadocs for EventQueue's getNextEvent() on: 2011-02-06 00:25:24
Yes, and the add() code replaces the Event object at the tail.

Seriously, take a breath. Its OK for old code to have creaky edges.

To make a full assessment, I'd have to dive into the code that populates the queue when you do a poll(), which is more effort than this tiny routine merits. But in the AbstractController class, the poll() function calls add() on the queue, replacing the Event that was there with the static one in the class. The Event is loaded using getNextDeviceEvent(Event event), which is abstract. Other implementations may do other things.

6  Java Game APIs & Engines / JInput / Re: is LinuxJoystickPOV not subclassed from Component.POV? or am I doing this wrong? on: 2011-02-05 21:07:36
Don't use the class names, use the component identifiers. That is what they are there for.
I think you are missing some subtle things in my code. I get both the class and the identifier
and the debugging code shows all possible returned values.

So what constants in the package contain the value "pov"?
7  Java Game APIs & Engines / JInput / Re: Tempoary: Patches for javadoc thread on: 2011-02-05 21:05:44
Huh? Lots of the JDK code has fragments in the class showing how to use it.

1  
2  
3  
4  
5  
   /**
     * test if queue is full. Note: package protected, not public
      * @return true if the queue is full
      */

    final synchronized boolean isFull() {


One could argue about the need to point out its package protected, but the rest is minimal.

for
1  
2  
3  
4  
5  
6  
           /**
            * add one event to the queue.  Note: package protected, not public.
            * Question: does this fail or block if queue is full?
            * @param event the Event to add
            */

    final synchronized void add(Event event)

I assume that someone would know the answer to the question, and what a fixed size queue does when its full is a critical part of understanding the API.



The words on how the  getNextEvent(Event event) works are specifically to explain how it works, since it is so different from how "get()" works for the standard JDK's Queue functions.

More importantly, what is the downside of well strructured javadocs? The are removed in compilation, they only help programmers understand what the API does.
8  Java Game APIs & Engines / JInput / Re: Clarifying the Javadocs for EventQueue's getNextEvent() on: 2011-02-05 17:29:06
Populating an object you pass in is an efficiency saving designed to reduce the number of objects created, and thus the amount of GC needed

Actually, this is not a correct optimization. Some lower level code (probably the poll() function) creates the Event objects and places them in the queue. There is nothing to be gained by passing in an object to populate. The standard Queue functions in the JDK just return the reference to the object created elsewhere, and "add()" to the queue.

What this class needs, IMHO, is functions aligned with the JDK's Interface Queue<E>, specifically the peek() and poll() functions. They are the standard way of dealing with queues.

9  Java Game APIs & Engines / JInput / Re: Clarifying the Javadocs for EventQueue's getNextEvent() on: 2011-02-05 17:07:52
Best place to submit patches is here.
new thread created for this.
10  Java Game APIs & Engines / JInput / Re: Timing for pooling loop, and Multi-threading for polling on: 2011-02-05 17:07:05
I can understand the historical basis. And I'm not up to speed with the internals of OS-X or Windows more recent than W2000, so it may be true still across the board. But interrupt and/or callbacks are the more modern way to do events, and are less resource intensive. Since OS-X has assorted BSD and Mach origins, I would expect it to work fine with interrupts. For Windows, I would not be surprised that you have to connect into one of the Direct-X apis.
11  Java Game APIs & Engines / JInput / Tempoary: Patches for javadoc thread on: 2011-02-05 17:03:29
attached is patchfile updated copy of EventQueue.java with additional javadocs.

Same file is available on my website
http://pfarrell.com/java/EventQueue.java
and
http://pfarrell.com/java/EventQueue.diff


Index: EventQueue.java
===================================================================
--- EventQueue.java   (revision 236)
+++ EventQueue.java   (working copy)
@@ -38,23 +38,56 @@
  *****************************************************************************/
 package net.java.games.input;
 
+   /**
+    * The <code>EventQueue</code> class implements a FIFO queue for Events.
+    * Typical usage pattern looks like:
+    * <pre>
+      for (Controller ctl : controllers) {
+            ctl.poll();
+            EventQueue localQueue = ctl.getEventQueue();
+            Event event = new Event();
+            while(localQueue.getNextEvent(event)) {
+                // do something cool here
+            }
+            try {
+                Thread.sleep(LOOP_TIME);
+            } catch (InterruptedException ex) {
+                // log exception
+            }
+        }
+    * </pre>
+    *
+    * @author Sun and open source contributors
+    */
 public final class EventQueue {
    private final Event[] queue;
    
    private int head;
    private int tail;
-
+           /**
+            * constructor, accepts argument with length of internal storage. Note, this constructor
+            * is not normally used by game developers, as they use the getEventQueue() function of
+            * Controller
+            * @param size capacity of the queue
+            */
    public EventQueue(int size) {
       queue = new Event[size + 1];
       for (int i = 0; i < queue.length; i++)
          queue = new Event();
    }
-
+           /**
+            * add one event to the queue.  Note: package protected, not public.
+            * Question: does this fail or block if queue is full?
+            * @param event the Event to add
+            */
    final synchronized void add(Event event) {
       queue[tail].set(event);
       tail = increase(tail);
    }
-
+           /**
+            * test if queue is full. Note: package protected, not public
+            * @return true if the queue is full
+            */
    final synchronized boolean isFull() {
       return increase(tail) == head;
    }
@@ -62,7 +95,15 @@
    private final int increase(int x) {
       return (x + 1)%queue.length;
    }
-
+           /**
+            * The getNextEvent method returns true if the queue <i>had</i> an event in it,
+            * and it managed to populate the event object you passed in with the details.
+            * False if there was nothing in the queue to copy in to your event object.
+            * Populating an object you pass in is an efficiency saving designed to reduce
+            * the number of objects created, and thus the amount of garbage collection needed.
+            * @param event
+            * @return  true if the queue <i>had</i> an event on it
+            */
    public final synchronized boolean getNextEvent(Event event) {
       if (head == tail)
          return false;
12  Java Game APIs & Engines / JInput / Re: clarification needed on "getting started" on: 2011-02-05 16:33:47
Adding it to the jdk is crazy, what happens if you have 2 apps installed that depend on different versions of jinput?
I could be wrong, I often am.

I can't imagine that. Are there really serious compatibility problems with jinput? Does it really upgrade that frequently?

Standard Unix practice, going back decades, is to use version numbers in the name to keep them separate if needed.
libjinput-linux_2.1.3a.so

On Windows, we are stuck with DLL hell
13  Java Game APIs & Engines / JInput / Re: is LinuxJoystickPOV not subclassed from Component.POV? or am I doing this wrong? on: 2011-02-05 16:30:49
pov(pov)
14  Java Game APIs & Engines / JInput / Re: reasonable to expect that the user will not plug in new controllers in game? on: 2011-02-05 16:05:32
I have a hard time seeing that its a real-world need. I expect most folks plug in their controllers and then start the game.
15  Java Game APIs & Engines / JInput / Re: clarification needed on "getting started" on: 2011-02-05 16:04:27
Thanks for the clarification. Nice to know.

I'm not convinced that its really needed, over the simple copy. Except that if you put it in the JRE directory, and subsequently use another JRE version or even change to a completely new JRE, you have to redo it. I don't think its likely that we'll see a lot of name conflict, libjinput-linux.so is a nice name.
16  Java Game APIs & Engines / JInput / Re: Clarifying the Javadocs for EventQueue's getNextEvent() on: 2011-02-05 16:01:29
Cool. What's the proper access for read-only? I assume its all in CVS/SVN/GIT or something similar.

17  Java Game APIs & Engines / JInput / Re: Timing for pooling loop, and Multi-threading for polling on: 2011-02-05 16:00:02
I understand the desire for the game to have One Clock to rule them all. But I'm not understanding why that means a fixed polling time for input. That's really a separate issue, unless I'm confused.

Seems to me that the key to handling input is to get all the events as soon as possible. Pulling the trigger is clearly an obvious example, but even turning (rotation) is critical to survival in a FPS.

Putting in a simple thread to handle and queue up the Event is trivial to do, I did it last night. I'm more interested in why a fixed polling time for events is good.

You say it couldn't be changed, so perhaps this is just historical. Clearly jInput predates Java 1.5.
18  Java Game APIs & Engines / JInput / reasonable to expect that the user will not plug in new controllers in game? on: 2011-02-04 22:27:29
The usual samples show a code fragment like this:
1  
2  
3  
4  
5  
6  
7  
8  
    Controller[] controllers = driver.getKnownControllers();
    while(true) {
        for (Controller ctl : controllers) {
            ctl.poll();
            EventQueue queue = ctl.getEventQueue();
           // do stuff
       }
    }


Which works great in my testing.
But by placing the getKnownControllers() outside of the infinite loop, you will not detect any changes. The user could plug in a new controller, or even swap one for another, and the sample code will not detect it.

Is this a reasonable restriction? Is it acceptable to use this design? or should the main loop also check occasionally for new controllers?
19  Java Game APIs & Engines / JInput / Re: clarification needed on "getting started" on: 2011-02-04 22:21:06
I agree with the potential for version skew. Perhaps I don't understand the suggestions above.
Something has to bind the .so to a known place so that the java library can find the needed functions.

How do you suggest one do that?
20  Java Game APIs & Engines / JInput / Timing for pooling loop, and Multi-threading for polling on: 2011-02-04 22:06:42
I've noticed that all of the usual examples have a 20 millisecond polling sleep in the main polling loop. Which raises the question: why 20 milliseconds?

In a long dead thread:
Nope. JInput is a polled API, you always have to poll it. If you want to do what you say, you could write a thread that polls the API and then calls in to your code on a listener interface, but it seems odd. Most games want control over the threading model, so polled APIs seem more acceptable to developers.

My initial reaction is, what kind of control do games want over the threading model? Java has had nice threading support for ages, and the recent 1.5 and later versions have nice synchronized queues. To me, the obvious model is to have the controller polling in one thread, the command/key/movement action in another, with a third thread for game motion and AI. (with usually another for painting the graphics)

What is the reason that folks don't implement it this way? Is it technical? or historical?

Are there known problems with putting the polling loop in a separate thread?

Thanks
Pat
21  Java Game APIs & Engines / JInput / Clarifying the Javadocs for EventQueue's getNextEvent() on: 2011-02-04 21:56:53
The standard javadocs for EventQueue show that the full API for getNextEvent() is

Quote
getNextEvent
public final boolean getNextEvent(Event event)

With nothing about what it actually does, what the argument is, when it returns true, etc.

I take it from the sample code that turns true when there is the queue is not empty, and when it is going to return true, it modifies the argument "event" to contain the event at the top of the queue.

If this is a correct guess, I'm more than willing to change the source to improve the javadoc.

Is this guess correct?

And if so, how to I submit a patch? or to who?

thanks
Pat

BTW, I'm not a fan of the API's design, which is more of a C-idiom than a standard Java one. Usually in Java, you return the entry in the queue, and if its non-blocking, you would return a null.
22  Java Game APIs & Engines / JInput / Re: clarification needed on "getting started" on: 2011-02-04 21:47:33
As an alternative, all you have to do is copy the appropriate .so for your verrsion, i.e..

for 32 bit ubuntu:  libjinput-linux.so
and for 64 bit ubuntu: libjinput-linux64.so

to the proper directory in your JRE installation. For example, on my laptop, I have the JDK installed in
/opt/jdk1.6.0_21/
so the appropriate directory is
/opt/jdk1.6.0_21/jre/lib/i386

all you have to do is copy the proper .so to that directory and you are ready to go.
23  Java Game APIs & Engines / JInput / Re: is LinuxJoystickPOV not subclassed from Component.POV? or am I doing this wrong? on: 2011-02-04 21:40:42
Thanks for the reply. A code fragment:

1  
2  
3  
4  
5  
                Component comp = event.getComponent();
                String compName = comp.getName();
                Component.Identifier compIdent = comp.getIdentifier();
                String compId = comp.getIdentifier().getName();
                buffer.append(String.format(" %s idt: %s  %s %s", comp, compName, compIdent, compId));

is returning "pov" for all values.

I'm not seeing anything returning the string "Component.Identifier.Axis.POV" or alternatively
"Component$Identifier$Axis$POV"

If I look at the class name of the "comp" it shows LinuxJoystickPOV

While I can just hard coded it to "pov" I would much rather use either a nice class name or a manifest constant from the package.

Thanks
Pat
24  Java Game APIs & Engines / JInput / is LinuxJoystickPOV not subclassed from Component.POV? or am I doing this wrong? on: 2011-02-03 22:46:00
I'm a rookie at this. I'm trying to pick up values from the hat of my joystick. So I have code like:

1  
2  
3  
4  
               Component comp = event.getComponent();
                if (comp instanceof Component.POV || comp instanceof LinuxJoystickPOV) {
                    System.out.println(" is hat");
                }

This works, but if the test is jut for the Component.POV, it fails.

 
1  
2  
3  
            if (comp instanceof Component.POV ) {
                    System.out.println(" should still be a hat");
            }


What is the preferred way to check this?

Thanks
pat
Pages: [1]
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (17 views)
2014-08-01 22:53:16

CogWheelz (15 views)
2014-08-01 22:51:43

CopyableCougar4 (20 views)
2014-08-01 19:37:19

CogWheelz (19 views)
2014-07-30 21:08:39

Riven (27 views)
2014-07-29 18:09:19

Riven (16 views)
2014-07-29 18:08:52

Dwinin (14 views)
2014-07-29 10:59:34

E.R. Fleming (42 views)
2014-07-29 03:07:13

E.R. Fleming (13 views)
2014-07-29 03:06:25

pw (44 views)
2014-07-24 01:59:36
Resources for WIP games
by CogWheelz
2014-08-01 18:20:17

Resources for WIP games
by CogWheelz
2014-08-01 18:19:50

List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!