Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (115)
games submitted by our members
Games in WIP (562)
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  
  Abstract input management - need feedback  (Read 3293 times)
0 Members and 1 Guest are viewing this topic.
Offline aldacron

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Posted 2004-02-09 23:27:43 »

With the Simplicity project I'm trying to work out an input abstraction layer which should be able to support multiple input APIs (JInput, AWT, LWJGL). What's killing me is how to handle translation of key constants.

Mapping Simplicity's constants to the API constants is not the issue. The problem lies in going the other way. For example, I could number the Simplicity contants (0...n), then the concrete implementation would load an array which could be used for mapping. Since I can't rely on API key constants being sequential, or even within a sane range (wouldn't want an array of 1000 ints if I'm only going to use 100 of them), then that method is out for the reverse mapping.

A few ideas I've thought of:

1) The obvious switch statement. This is ugly, bulky, and not something I favor.

2) A hashmap - API constants as keys, Simplicity constants as values. I could still use the array for mapping Simplicity to API constants. This would require an Integer object to be created for each constant (both keys and values) at startup, then the cost for searching the hashmap, fetching the Integer and pulling the int value each time I want to lookup a keycode.

3) Simplicity constants could be non-final statics. Each concrete implementation would set them at load time to the appropriate API constant value. The drawback is that they could be accidently modified during runtime causing the input handling to break.

4) No Simplicity constants. Instead, define an interface with methods such as getKeyA(), getKeyUp(), etc... Implementations could simply return the appropriate API constant. The only drawbacks I see here are that the class created to implement the interface would likely take up more memory than constants would (nothing major), and implementations would require a lot more typing!

Performance doesn't really concern me as Simplicity's input system is event based, so there won't be needless polling of every key each frame. I'm also not concerned about memory overhead, as it is miniscule in the grand scheme of things (although it does just feel icky redefining constants that are already defined elsewhere - the price of abstraction).

So, with the exception of number 1, all of these techniques are viable for me. I really prefer #3, and it's currently how I plan to implement it. This is often done in C++ (externed constants in a header initialized in the source file of a concrete implementation, for example). I'm curious if anyone has any other suggestions/comments on how to go about it.
Offline elias

Senior Member





« Reply #1 - Posted 2004-02-10 04:31:59 »

I wouldn't worry about performance either, so the HashMap option sounds just about right from where I sit.

- elias

Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2004-02-10 09:07:04 »

Hashmap, for sure. Very easy to implement, and we're talking an unmeasurably small performance hit on the rare occasions a key is typed.

Cas Smiley

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

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #3 - Posted 2004-02-10 18:55:00 »

Simplicity constants should be object references - using the typesafe enum pattern.  (Or 1.5 enums)
Then when you look them up using the HashMap you don't have to convert the value to an int at all.

Offline aldacron

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Reply #4 - Posted 2004-02-10 23:10:08 »

THanks for the input guys. I often have this horrid fear of instantiating many small objects, which leads me to struggle with decisions like this one. I do some wacky stuff sometimes to avoid it.
Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2004-02-11 07:36:28 »

Instantiating small objects should never be a worry. Until you have to make hundreds of thousands of them.

Cas Smiley

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #6 - Posted 2004-02-12 03:21:26 »

Will this input abstraction layer be able to be used independently?  This is exactly the sort of thing which we need for Xith3D and I'm guessing other projects too.

What license will you be using?

Will.

Offline aldacron

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Reply #7 - Posted 2004-02-12 09:23:08 »

Yes, it could be used independently. The only ties it has to the rest of the framework are the custom exceptions I have in the top-level package.

The entire Simplicity project is being released under the same BSD-style license as Xith3D.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #8 - Posted 2004-02-13 21:55:16 »

great Smiley

Offline tgeorge

Senior Newbie




Java games rock!


« Reply #9 - Posted 2004-02-13 22:36:48 »

Is there any code or anything released yet ?

I'm in the middle of implementing something very similar for
cross-toolkit SWT.  Can I take a gander at what you're doing
for this?  If so, how, where is the CVS or file store ?

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

Senior Member


Medals: 9
Exp: 16 years


Java games rock!


« Reply #10 - Posted 2004-02-15 09:44:22 »

I don't have any of the input packaged checked in yet. Working on it piecemeal, so it will be a few more days. simplicity.dev.java.net is the project the package is a part of.
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.

BurntPizza (25 views)
2014-09-21 02:42:18

BurntPizza (16 views)
2014-09-21 01:30:30

moogie (19 views)
2014-09-21 00:26:15

UprightPath (26 views)
2014-09-20 20:14:06

BurntPizza (29 views)
2014-09-19 03:14:18

Dwinin (44 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (100 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56

mitcheeb (71 views)
2014-09-08 06:06:29
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

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

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

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!