Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Input Abstraction Layer  (Read 3693 times)
0 Members and 1 Guest are viewing this topic.
Offline troggan

Junior Devvie




no guts no glory


« Posted 2003-09-21 06:44:21 »

Hi!

kevglass and  I are writing an abstraction layer for 2d graphics. we just want to add an abstraction layer for input.
that would make it possible to have input via different libraries (jinput or awt).  this is needed because we want to have a solution that is 100% platform independent.

the only solution we have found is to create a key mapper that maps awt keys and jinput key values to the same value, since jinput and awt  use different values for keys. is there a better / faster solution?

troggan



(http://www.wannawork.de) - Will work for food
(http://tvbrowser.org) - Java EPG
Offline kevglass

« JGO Spiffy Duke »


Medals: 212
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2003-09-23 07:40:20 »

I'm not sure the question was really understood here.

Why don't the axis codes for keyboard buttons in JInput match up with their associated key code in AWT?

Maybe it's to do with it being a more direct mapping to the keyboard in JInput, just wondering if someone could enlighten us?

Kev

Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #2 - Posted 2003-09-23 08:15:27 »

Maybe you just take the JXInput approach?

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

« JGO Spiffy Duke »


Medals: 212
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2003-09-23 08:48:06 »

Its entirely possible at this point. More worried about gamepads more than anything else tbh.

Kev

Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #4 - Posted 2003-09-23 08:58:04 »

JXInput covers gamepads easily. If its more about buttons, the JXInput eventing might be usefull. Or its button-combis constructs...

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline JuddMan

Senior Devvie


Medals: 1


Your Ad Here


« Reply #5 - Posted 2003-09-23 18:31:21 »

jxinput is not free if you want to sell anything that uses it.
Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #6 - Posted 2003-09-23 19:19:27 »

Thats written nowhere. So far, everybody interested received a free license.

I currently considering putting it under a opensource licence. I just have no idea how to....

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #7 - Posted 2003-09-24 17:56:26 »

Jinput will also work ok with gamepads, just ignore the keyboard and mouse stuff, you get alot more platform independance. Last time I checked JXinput didn't have linux or mac versions, just the ability to have ports/plugins.

HTH

Endolf

Offline kevglass

« JGO Spiffy Duke »


Medals: 212
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #8 - Posted 2003-09-25 05:02:21 »

Thats not really a solution I'm happy to play at the moment. If the user has gone to the trouble of distributing jinput with their stuff then they should be able to utilise its pollable nature. Implementing JInput support but then using AWT to pick up mouse and keyboard would be a last ditch I reakon.

Kev

Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #9 - Posted 2003-09-25 11:55:30 »

I think i missed the point somewhere near the top of this thread. The original question was about having inputthat is platform independant. The closest you will get is using jinput for the platfroms it supports, and awt for the rest, the rest will only have mouse and keyboard support. Then there was a question about the key codes. If you want awt and jinput then you will have to map the key codes. If you want gamepad support on windows only then you can use jxinput, but at the last look itdidn't have any implementation for mac or linux.

jinput is closer to the hardware, and has no idea of the key codes based on the keyboard layout you have, which sucks. I think for my projects i'll end up writing a wrapper around awt mouse and keyboard and create a pollable interface over the top, then use jinput for gamepads/joysticks. It's not ideal, but nor is jinput or jxinput or awt alone.

Endolf

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

« JGO Spiffy Duke »


Medals: 212
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #10 - Posted 2003-09-25 12:47:37 »

Ok, I think we've talked about this before (offline) but if JInput sucks for keyboard then wouldn't it be nice to supply an AWTKeyboard device that just wrapped the pollable interface around the AWT events as part of JInput?

The original question was really only about keyboard and the lack of common values between JInput and AWT (which you've just explained).

Kev

Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #11 - Posted 2003-09-25 13:20:47 »

Quote
Ok, I think we've talked about this before (offline) but if JInput sucks for keyboard then wouldn't it be nice to supply an AWTKeyboard device that just wrapped the pollable interface around the AWT events as part of JInput?


Yes. I'll try and get en environment working on my laptop when I get back and look into it. It's a good idea that I hadn't thought of before. My initial thoughts are that it would show up as another device when you do a getControllers on your environment. I'll talk to jeff nad see what he thinks about it. If I get the go ahead i'll get on wit hit, if I don't then I'll probably work around it and get something that sits over 'official' jinput and returns everything + the new controller and release it, as I think it's how *most* people will want to use it. I might look and see if it makes sence to wrap the mouse too or not.

Cheers

Endolf

Offline Jeff

JGO Coder




Got any cats?


« Reply #12 - Posted 2003-09-25 19:52:17 »

The issue with using AWT to read keyboard and mouse basically boils down to this:

JInput is designed purposefully to be AWT independant.  This is  so you don't have to drag the huge AWT tangle of classes into memory just to do input.

That being said, you could indeed write an AWT based plug-in that hid the AWT details for when you want that.  It woudl be kind of nice to have one gauranteed way to get mosue and keybaord on any J2SE system (note that J2ME systems don't support full AWT though so your back where youstarted from there.)

The biggest issue with writing this plug-in is that, to function, it needs an AWT frame passed to it.  You will only get input within the scope of that Frame.

As I do *not* want to expose AWT-ness in the API, what you will need to do is somethign like this in the initialization section of your client code:

1  
2  
3  
if (myDeviceContext instanceof AwtContext){
       ((AwtContext)myDeviceContext).setFrame(myFrame);
}


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #13 - Posted 2003-09-25 19:58:52 »

Hi
 The way I had thought of doing this was to be completetly optional, so a user can ask the jinput environment to create it an AWTKeyboardDevice, passing a component to it, thus if you are not on an AWT enabled device it will not worry you, but if you want it it is there. This might introduce compile time issues though for the platfroms that don't have AWT. Maybe a layer over the top that isn't part of core jinput would be the way to go, but making the layer onto look like jinput, and create the AWT devices if requested on a per component bases.

Thoughts/comments/rotten fruit? Smiley

Endolf

Offline Jeff

JGO Coder




Got any cats?


« Reply #14 - Posted 2003-09-25 20:19:13 »

Hm.
You mean add a new API call to get this AWTInputDevice?

The problem I see there is that yo ueither need to make the parameter a Component, which pulls in AWT immediately as now you are referencing the AWT class tree, OR pass a generic "Object' through.  Which is pretty ugly when all you really want is a component and anything else is an invalid parameter.

It still seems cleanest to me to do it by downcasting a DeviceContext supplied by an "AWT Plugin"...


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #15 - Posted 2003-09-26 11:44:33 »

Hi
 I can see where you are comming from on this one, I guess setting a property up and then checking it to say wether or not to load the AWT plugin too, but the way I see it you would want both the awt plugin *and* the native one, so that you still have access to gamepads etc.

More thought required, I'll look at this next week if I can get jinput up and building and running on my laptop on sunday.

Cheers

Endolf

Offline kevglass

« JGO Spiffy Duke »


Medals: 212
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #16 - Posted 2003-09-27 05:41:35 »

You could register for key events on a global scale using:

Toolkit.getDefaultToolkit().addAWTEventListener(myKeyHandler,AWTEvent.KEY_EVENT_MASK);
       
and hence not ever have to have an AWT component. Also this means that at runtime you wouldn't need AWT unless you hit this bit of code (at which point you must have requested the AWT Keyboard) at least thats how I would think dynamic binding would work.

Kev

PS. Thanks to someone over in the Xith3D forum some time back for this tit-bit.

Offline Jeff

JGO Coder




Got any cats?


« Reply #17 - Posted 2003-09-28 04:33:47 »

Cool.  That relieves the component issue for the Keyboard, is there a similar way to register a mouse listener?

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline troggan

Junior Devvie




no guts no glory


« Reply #18 - Posted 2003-09-28 04:56:14 »

If you look into the AWTEvent Class, there are much more Event Masks, just try this one : MOUSE_EVENT_MASK

troggan

(http://www.wannawork.de) - Will work for food
(http://tvbrowser.org) - Java EPG
Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #19 - Posted 2003-09-28 08:12:35 »

Quote
You could register for key events on a global scale using:

Toolkit.getDefaultToolkit().addAWTEventListener(myKeyHandler,AWTEvent.KEY_EVENT_MASK);


Well that makes things a little easier Smiley

Back to asking the environment for an awt keyboard device or a awt mouse device then Jeff?, or how do you want to take this further?

Cheers

Endolf

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (22 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (51 views)
2014-12-03 16:27:13

CopyableCougar4 (49 views)
2014-11-29 21:32:03

toopeicgaming1999 (115 views)
2014-11-26 15:22:04

toopeicgaming1999 (105 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

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

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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!