Input Abstraction Layer

Engines, Libraries and Tools Xith3D Forums
#1

I have created an Input Abstraction Layer.

Links:

Announcement
Hybrid Input Abstraction Layer website

I was going to make it part of Xith3D, but decided not to as it is totally independent and I believe non-Xith3D people can benefit from it but might be put off it it were part of the larger xith3d package.

The implications of this to Xith3D are that if we adopt this package for the input of our demos, the demos can be made so that a simple VM argument changes them from using the JOGL renderer and AWT input system to the LWJGL renderer and input system.

I am willing to change the Xith3D demos so they use the HIAL input system and support LWJGL at the flick of a switch – it is actually fairly trivial (now that the leg work is done).

What are everyone’s thoughts on this? Does anyone object to changing the way the input is processed in the official Xith3D demos? Please reply with your +1’s if you approve of this change, or -1’s (with a reason) if you disapprove.

Cheers,

Will.

#2

+0 … except for the Input demos, +4!

/* finally my javagaming login works… hello all :slight_smile: */

#3

Hi,

If we do not include HIAL into Xith3D core, I will suggest not to mage strong dependency of core examples on it.

I will vote for starting a subset in Xith-TK project which will host the demos.

Modifying demos in com.xith3d.test will cause one more dependency on “3rd party library” which is questionable.

Anyway, I think we should finally factor out test and example code from the core itself.

Yuri

#4

[quote]Hi,

If we do not include HIAL into Xith3D core, I will suggest not to mage strong dependency of core examples on it.

I will vote for starting a subset in Xith-TK project which will host the demos.

Modifying demos in com.xith3d.test will cause one more dependency on “3rd party library” which is questionable.

Anyway, I think we should finally factor out test and example code from the core itself.

Yuri
[/quote]
I agree that another dependancy is not ideal, but I wasn’t sure if HIAL belonged in the core either. Is input processing considered part of a scenegraph? I am happy to add it if this is wanted (although I’ll still maintain a seperate download for non-Xith3D users).

There is currently some bloat in the Xith3D core, perhaps we should migrate some other non-essential packages (e.g. collision, ASE loader, userinterface) out as well? These packages, like the examples could still be maintained by the Xith3D developers in CVS, but it would keep the actual core packages more seperate and they could be maintained at a higher quality (e.g. moving to full javadoc).

It would be good if there were more examples than what we have now. Perhaps if we use the xith-tk CVS, more developers could have access to add more demos (maybe we should place Java Cool Dude’s demos there as well (with permission) so they can be kept up to date).

Regards,

Will.

#5

I think the best solution would be to move a bunch of the Xith-tk stuff into the core and allow developers of those various pieces of xith to modify only their sections of the Xith core.

Doing this would encourage more people to contribute to xith, and it would also make it much easier on getting new individuals to use Xith. As it stands now, most of these newbies would most likely choose jME instead of xith, because its core contains everything they need: loaders for various models, collision, effects, etc. While for xith, these rather essential pieces are scattered about in a separate project that is hardly even mentioned on Xith’s main site (xith3d.org).

On a side note, I’m almost done porting a very nice 3DS loader that loads models perfectly, returning a shared copy, and even handles basic animation (rotation, scaling, and translation). I think that there should be a standard implementation for all Xith loaders: a modified LoaderBase that returns a modified SceneBase that adds the methods like:
setCurrentFrame(int frame);
getNamedObject(String transformGroupName);
And especially: public SceneBase sharedCopy();

Then all these loaders could be put in the org.xith3d.loaders package and would all use identical methods and would allow developers to easily switch between model loaders without having to rewrite their code, and developers of them would have the confidense of knowing that many people can help improve their loaders, and when improvements are added, all users of Xith3D immediately benefit from them when they update their CVS.

And finally, I think it needs to be mentioned again because it’s important, doing this would seriously expand Xith’s userbase and developers coding for it.

#6

You are right, I believe more organisation is definitally needed rather than a bunch of disjointed projects which can get out of date with the main trunk.

However I disagree that Xith3D should contain everything including the kitchen sink. It is a scenegraph. Personally, I feel we should go the other way – move non-essential stuff out of the core and into the toolkit. Then really keep the core of a very high standard with no known bugs and missing features.

We could mandate that developers changing the API must also update all of the code in the toolkit to match (of course, if this is a big task due to a large change, they can ask for help – but at least issue will be known).

Having a large amount of community code in the toolkit, readily available as a single download would be ideal. Users can be granted developer access to the toolkit much more readily than the core itself. Community builds (what most people download) can include the packages from the toolkit, easily distinguishable by the “org” prefix.

Packages that can be moved to the toolkit from the core (ref):

[] com/xith3d/collider
[] com/xith3d/loaders/ase
[] com/xith3d/terrain
[] com/xith3d/test
[] com/xith3d/utility/cmdline
[] com/xith3d/utility/events
[] com/xith3d/utility/exception
[] com/xith3d/utility/general
[] com/xith3d/utility/interpolate
[] com/xith3d/utility/noise
[] com/xith3d/utility/properties
[] com/xith3d/userinterface
[*]+ more…

Disjoint projects which could be merged into the toolkit CVS

[]OBJLoader
[]XML Serialization
[]Java Cool Dude’s demo
[]Primitive geometry (I am already working on this as we speak)
[*]other loaders and tools…

New projects which could be housed in the toolkit

[]Various UI packages
[]New Collision package

This way we have a bare bones and hopefully high quality core, with quality control ensured by having only a small number of developers with commit privlidges, and a large supporting toolkit which everyone can contribute to. This was the original goal of the xith-tk project.

All maintained code in the toolkit project would be version controlled and have the “org.xith3d” package prefix. Libraries not using the CVS would be instructed not to use the “org.xith3d” package to avoid confusion.

I definitally agree that we need to better coordinate and maintain the wealth of third party code that is out there. This is a way of doing it while preventing core bloat. By including the toolkit in the community builds of Xith3d, the code is still distributed to all Xith3D users but is more easily distinguishable (and removable if you are trying to save space when distributing your project).

Cheers,

Will.

#7

this all sounds cool Will nice one.
i am at present makeing a GE2 loader so if theres
a framework model we want loaders to cover then
np with me. :slight_smile:

#8

Thanks aNt. Are you already a developer for the xith-tk project? If not, request that role and it will be approved.

The migration of xith3d packages I will leave for a while.

Lets start trying to move some of the third-party libs into CVS.

My contribution:
I have created a new primitives package – org.xith3d.geometry with near-complete javadoc comments. It is already in the xith3d javadoc. Source is in the xith-tk CVS.

The code is a combination of Daniel Herring’s, Yuri’s (TestUtils Rectangle) and my own (SkyBox). I have gathered the BSD-like licensed code and made it into an OO primitives package for all to use.

One requirement of the org.xith3d package that I am going to insist on is that it be licensed the same as Xith3D itself. That is BSD-like. The toolkit should be licensed alike to maximise usability. We also don’t want a spaghetti of different licenses in the one package set which may trap unsuspecting people.

EDIT:
A second requirement is that any API changes must be annouced (prefrably discussed) in the forums so people relying on the code have some warning. I believe this requirement will increase the usability of the package.

Will.

#9

I tried to use the HIAL and changed the following parts of the original code to get the KeyEventQueueListener work:

Constructor:


public KeyEventQueueListener(int queueSize, Collection eventQueueFilter, boolean invertFilter, Timestamp timestamper) {

    events = new KeyboardEvent[queueSize];
    for (int i = 0; i < events.length; i++) {
       events[i] = new KeyboardEvent();
       // events[0] ... doesn't work
    }
    
    if (eventQueueFilter != null) {
        this.eventQueueFilter = new HashSet(eventQueueFilter);
    }
    this.invertFilter = invertFilter; 
    this.timestamper = timestamper;
}

next() checks if the queue is empty and returns true if it was able to return an event.


public synchronized boolean next(KeyboardEvent event) {
    if (!hasNextEvent()) {
        //throw new IllegalArgumentException("No next event");
        return false;
    }

    KeyboardEvent toReturn = events[nextEventGet];

    event.key = events[nextEventGet].key;
    event.pressed = events[nextEventGet].pressed;
    event.timestamp = events[nextEventGet].timestamp;

    nextEventGet++;
    if (nextEventGet > events.length) {
        nextEventGet = 0;
    }
        
    return true;
}

I think the queue is empty if nextEventGet and nextEventPut point to the same entry.


public boolean hasNextEvent() {
    return nextEventGet != nextEventPut;
}

With these changes an example like this worked:


import java.awt.event.WindowEvent;
import java.awt.event.WindowAdapter;

import java.awt.*;

import net.jtank.input.*;
import net.jtank.input.awt.*;

public class Hial implements Runnable {

    private Thread inputThread = null;
    private GLCanvas glCanvas = null;
    private Frame frame;

    private KeyboardDevice keyboardDevice;
    private KeyEventQueueListener keyboard;
    private KeyboardEvent event;

    public Hial() {
        frame = new Frame( "TTW" );

        frame.addWindowListener(new WindowAdapter() {
          public void windowClosing(WindowEvent e) {
            killApplication();
          }
        });

        frame.show();

        keyboardDevice = new AWTKeyboard(frame);
        keyboard = new KeyEventQueueListener();
        keyboardDevice.registerListener(keyboard);

        event = new KeyboardEvent();

        inputThread = new Thread(this);
        inputThread.start();
    }

    public static void main(String args[]) {
        Hial h = new Hial();
    }

    public void run() {
        while (isRunning()) {
          try {
            Thread.sleep(3000);
          } catch(InterruptedException e) {
            e.printStackTrace();
          }

          keyboardDevice.update();

          while(keyboard.next(event)) {
            System.out.println("event: " + event.key + "-" + event.pressed);
          }
        }
    }

    public boolean isRunning() {
        Thread myThread = Thread.currentThread();
        return (inputThread==myThread);
    }

    public void killApplication() {
        inputThread = null;
        if (glCanvas != null) {
            frame.remove(glCanvas);
            glCanvas = null;
        }
        frame.dispose();
    }
}

I hope I understod your code right.

#10

Cant find a good unix toolset to handle gz and tar balls. The Reed-Kotler site isn’t around anymore. Could you package this up as a zip??

#11

[quote]Cant find a good unix toolset to handle gz and tar balls. The Reed-Kotler site isn’t around anymore. Could you package this up as a zip??
[/quote]
http://www.cygwin.com

http://gnuwin32.sourceforge.net/

#12

http://winzip.com/ handles .tar.gz’s fine

http://winrar.com/ handles them (and more) better.

Will.

#13

[quote]I tried to use the HIAL and changed the following parts of the original code to get the KeyEventQueueListener work:

I hope I understod your code right.
[/quote]
:o yikes, thanks for spotting the [0] bug!

As for hasNextEvent, you are right. It used to be called “isEmpty” but I changed the name without changing the code.

Regarding next(event), you are right, my use of the returned boolean in the example was inconsistant with the meaning of the returned boolean. I have applied your fix which makes the example work as it should.

Thank you for reporting these bugs, I shall do a new release soon.

Will.

#14

I wrote a long reply on this when the topic started, but it got lost in a PC crash :(.

So, a more concise reponse this time :)…

From long personal experience with java libraries (writing, maintaining, distributing, upgrading, and managing different partial releases for different customers), my 2 cents is this:

  1. Make everything as modular as possible, where “modular == separate JAR files”. JAR files are good; people really like having the different components in different JAR’s because it’s so damned easy to manage!.

When someone wants to upgrade, downgrade, or recompile just one part of the library at once, the fact that they only need to produce the JAR they need is beautiful (especially if it needs no native code whereas others do - no worries about having LWJGL available at compile time, etc). Even better is that they can do rapid testing by swapping just one file in and out of a directory.

  1. DO reference stuff like this in the core; in the long-run, it’s a false economy not to. It’s a good practice in C not to, but in Java…no. In Java, with runtime-only lazy-linking and dynamic classloading it’s a good and sensible thing to have a core that references other packages.

Yes, it might cause some pain if your build tools aren’t good enough to understand mutually dependent packages (one of my few gripes with vesta: it’s written by C developers, who didn’t expect that you can have two packages that have to be compiled simultaneously the first time, but thereafter only need the binaries of each other in order to be re-compiled).

There are, of course, neat standard OOP solutions to this: SPI’s and abstraction layers. SPI’s can be done, I think, by people other than Sun? but with hassle…as for abstraction layers, well - that’s what you’ve just done! It is precisely what you would expect that the “core” references an “abstraction layer”.

You’re not going to reference it in every class just for the heck of it, but only in the classes where you need to.

  1. Dump the whole xith-tk thing. I’ve co-written a Xith game and never even realised the xith-tk thing existed (I did see it mentioned, but it went in one ear and out the other).

Make the main xith.org etc refer to “Xith” as everyting you currenlty have, and always display the packages that are now in the toolkit side-by-side with the xith core packages, like this:

Xith core; this is the minimal amount needed to run Xith (plus you need the native libraries for your platform):

  • xith3d.jar

Xith native libraries:

  • LWJGL: lwjgl.jar (needed by all platforms) , lwjgl-windows.jar (needed by windows) , lwjgl-linux.jar (needed by linux)

Xith additional modules:

* ...each of the xith-tk things (download-link, file-size, version)
* ...each of the xith-tk things ...
* ...each of the xith-tk things
* ...each of the xith-tk things

Xith external modules (untested, unsupported, might not work at all)

* ...each of the xith-tk things which you're uncomfortable/uncertain about. Probably worth keeping all new things in this area for a while until you're a bit more confident about them...

(nb: show ALL the xith modules on the same page, all listed - this is a VERY good way of giving the surfer a good idea of what they need to download, and is a VERY convenient place for them to visit periodically one single page to see what’s available, what version it’s at, etc)

Why?

Because, although in your minds (as developers) the current layout makes sense, it does NOT make sense to uneducated potential users. What it looks like is to many viewers is that xith-tk is something random that’s not supported and probably doesn’t work and hey - it links to a completely different website with a horrible GUI that runs in a different window.

Plenty of people view the site and understand the relationship between xith-tk and xith. But plenty of others do not.

Just MHO…

#15

[quote]There are, of course, neat standard OOP solutions to this: SPI’s and abstraction layers. SPI’s can be done, I think, by people other than Sun? but with hassle…as for abstraction layers, well - that’s what you’ve just done! It is precisely what you would expect that the “core” references an “abstraction layer”.
[/quote]
Just an FYI, but SPI is SUPER-EASY to implement. You see, Sun added a special API to the ClassLoader API just to make this possible. The exact method call is:

public final Enumeration getResources(String name) throws IOException

Now the SPI spec specifies that the class names to load should be in a file called “META-INF/services/”. Let’s assume for a moment that “classname” is “com.blah3.NeedAShorterNickNameGenerator”. Thus the code to load the plugins would be:


            Enumeration enum = findResources ("META-INF/services/com.blah3.NeedAShorterNickNameGenerator");
            BufferedReader in;

            while(enum.hasMoreElements())
            {
               in = new BufferedReader(new InputStreamReader(((URL)enum.nextElement()).openStream()));
               
               while(in.ready())
               {
                   Class pluginClass = findClass(in.readLine());
                   NeedAShorterNickNameGenerator plugin = (NeedAShorterNickNameGenerator)pluginClass.newInstance();
                   //Add to list of nickname generators.
               }

               in.close();
            }

And Voila! Instant plugin architecture! Anyone who wants to create their own “NeedAShorterNickNameGenerator” plugin, would simply implement the interface (or extend the class), create a file in META-INF/services, and pack it into a JAR file. Simply adding the JAR to the classpath would then be sufficient to activate the plugin. ;D

Edit: I forget to say what would be inside the “META-INF/services/com.blah3.NeedAShorterNickNameGenerator” file. The answer is simply the name of the class(es) to load. The format is one class per line, so more than one plugin may be loaded from the same JAR file. An example file might be as follows:


com.jbanes.NamesFromIncrediblesGenerator
com.princec.ElvisNicknamesGenerator
com.spaceghost.UnknownCelebritiesGenerator
com.bubbagump.ShrimpPreperationNamesGenerator
#16

[quote]3. Dump the whole xith-tk thing. I’ve co-written a Xith game and never even realised the xith-tk thing existed (I did see it mentioned, but it went in one ear and out the other).

Make the main xith.org etc refer to “Xith” as everyting you currenlty have, and always display the packages that are now in the toolkit side-by-side with the xith core packages, like this:

Xith core; this is the minimal amount needed to run Xith (plus you need the native libraries for your platform):

  • xith3d.jar

Xith native libraries:

  • LWJGL: lwjgl.jar (needed by all platforms) , lwjgl-windows.jar (needed by windows) , lwjgl-linux.jar (needed by linux)

Xith additional modules:

* ...each of the xith-tk things (download-link, file-size, version)
* ...each of the xith-tk things ...
* ...each of the xith-tk things
* ...each of the xith-tk things

Xith external modules (untested, unsupported, might not work at all)

* ...each of the xith-tk things which you're uncomfortable/uncertain about. Probably worth keeping all new things in this area for a while until you're a bit more confident about them...

(nb: show ALL the xith modules on the same page, all listed - this is a VERY good way of giving the surfer a good idea of what they need to download, and is a VERY convenient place for them to visit periodically one single page to see what’s available, what version it’s at, etc)

Why?

Because, although in your minds (as developers) the current layout makes sense, it does NOT make sense to uneducated potential users. What it looks like is to many viewers is that xith-tk is something random that’s not supported and probably doesn’t work and hey - it links to a completely different website with a horrible GUI that runs in a different window.

Plenty of people view the site and understand the relationship between xith-tk and xith. But plenty of others do not.

Just MHO…
[/quote]
Excellent point. The current setup is just too confusing and will discourage potential developers from using Xith.

#17

The 3rd party tools do not have enough exposure I agree. They are a valuable asset to Xith3D and should be treated as such.

Speaking of links, Xith.org isn’t even linked from the xith3d java.net page! (this I will change very shortly).

Regarding the input abstraction in the core… The only actual “core” classes which could use it currently are the demos.

I believe we should start distributing all open tools with Xith3D itself. We can do this as a bunch of seperate .jar files if this is desired. Since our tools will be individually packaged and will not depend on non-core packages (unless explicitally stated), it will be possible to rip out all the tools that one doesn’t need later on.

The reason for the existance of the xith-tk project is to have a DMZ where new developers can easily add their code to the project without having access to the core itself.

The xith-tk has a purpose for developers (i.e. ones writing code for xith3d), but I agree that it can confuses new users (i.e. ones writing code with xith3d).

I think we should organise all third party code currently spread around the place into the CVS, and start including it with the distributions.

Will.

#18

edit: just noticed the new thread

#19

[quote]edit: just noticed the new thread
[/quote]
Thanks. This thread is a bit of a mess topic wise, I thought a thread dedicated to organising the tools would be in order :slight_smile:

Will.