Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
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  
  Quake-like Mouse Control  (Read 5457 times)
0 Members and 1 Guest are viewing this topic.
Offline hawkettc

Junior Newbie





« Posted 2006-02-04 01:46:28 »

I read a post by endolf here http://72.14.207.104/search?q=cache:_JTiqa9OGnUJ:www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi%3Fboard%3Djinput%3Baction%3Ddisplay%3Bnum%3D1083727410+jinput+quake&hl=en&ct=clnk&cd=2&client=safari (sorry for the cached google - but the forums seen to have been down for ages now) that suggested achieving quake like mouse look behaviour in java would be ideally suited to jinput.

Ok - great cos thats what I want Smiley.  Trouble is I'm struggling to work out how this is achieved - in fact I'm considering moving from jogl to lwjgl purely because of the mouse control (which is crazy - considering their mouse input is apparently based on jinput, which should work fine with jogl).  I've trawled the lwjgl source to try and work it out - but its not coming to me - I feel like I'm missing a part of JInput.

The functionality I can't seem to get is what lwjgl achieves with 'Mouse.setGrabbed(true)' - the mouse control is 'grabbed' from the underlying OS and the mouse doesn't scroll out of the window.  Easy to see what I'm talking about if you run the lwjgl MouseTest annd try modifying the setGrabbed to false.  Maybe its achieved by moving the mouse back to the centre of the screen all the time.  Dunno but I figure its more likely that the hardware events are not being passed to the OS.

So how do you do this with JInput?  The polling bit I get, so I can control my scene with the mouse - as long as I don't want to turn more than 270 degrees and lose the mouse off the edge of the window.  If anyone could give me any idea on this that would be a great - if I've missed pile of docs or how-to's or a wiki or something, a pointer to that would be much appreciated as well - thanks,

Colin

P.S. Once I've got it sorted out I'd be happy to post the walkthrough on a wiki somewhere if there is one...
Offline Jeff

JGO Coder




Got any cats?


« Reply #1 - Posted 2006-02-04 07:15:35 »

It soudns liek youa re confusing the mouse and the the cursor.

The mouse is an input device.

The cursor is an output device.

Typically a game will draw its own cursor and clip it to its space.

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 Jeff

JGO Coder




Got any cats?


« Reply #2 - Posted 2006-02-04 07:18:07 »


So how do you do this with JInput?  The polling bit I get, so I can control my scene with the mouse - as long as I don't want to turn more than 270 degrees and lose the mouse off the edge of the window.

I dont quite get this.  The OS aught to be returning mouse events regardless of where the cursor is in relation to the window.

I know this is the case in Linux.  What OS are you under?  Its possible the plug-in needs a property to tell it to make some OS specific call on your OS, though this would be a bizzare OS.... (which is why Im guessing its Winblows but maybe Im wrong.)


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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #3 - Posted 2006-02-04 14:46:33 »

Hi

As I understand it, lwjgl doesn't use jinput for mouse or keyboard, but does for other controllers. Under XWindows on linux, I also get issues when I move the mouse out of the window using lwjgl, but not using jinput.

HTH

Endolf.

Offline hawkettc

Junior Newbie





« Reply #4 - Posted 2006-02-05 00:41:21 »

Thanks for the responses...

I get the difference beetween the mouse and the cursor - but it sounds like I might have things a bit confused in other ways.  Perhaps I need to roll back and ask some more fundamental questions.  Perhaps JInput isn't what I'm after.

Can I stop the OS  (OS X in this case) Windowing System cursor moving while my game window has focus?  It seems the answer is yes, because both lwjgl and jake2 achieve this.  Did they write their own custom native implementation to achieve this - or is there a method somewhere that I'm missing.   

Essentially this would have to happen in one of three ways -

1.  The Windowing System stops polling the mouse driver (if thats how it gets mouse movement data - JInput model)
2.  The Windowing System would have to stop listening for mouse movement events (if thats how it works - the AWT model)
3.   The mouse driver the Windowing System is using would have to present information (polling or eventing) that indicated no mouse movement.  If the model is eventing, then this would prrobably mean never raising the event.

The ugly other option here would be to continually move the cursor back to the centre of the screen with something like the java.awt.Robot class.

I can hide the system mouse cursor and draw my own in JOGL, but I suspect that if any of the above 3 things happened, then AWT would not receive mouse events either.  Hence I would need something like JInput to receive mouse movement data.

So the question is - for Quake-like mouse control - how do I stop the Windowing System cursor from moving when my window has focus?

At the moment I think I'm going to have to go with JInput and java.awt.Robot - but that seems dodgy - hopefully the Robot won't interact wiith JInput - seems ok at first glance.  Cheers,

Colin

Offline Jeff

JGO Coder




Got any cats?


« Reply #5 - Posted 2006-02-05 01:03:26 »

Thanks for the responses...

I get the difference beetween the mouse and the cursor - but it sounds like I might have things a bit confused in other ways.  Perhaps I need to roll back and ask some more fundamental questions.  Perhaps JInput isn't what I'm after.

Can I stop the OS  (OS X in this case) Windowing System cursor moving while my game window has focus?  It seems the answer is yes, because both lwjgl and jake2 achieve this.  Did they write their own custom native implementation to achieve this - or is there a method somewhere that I'm missing. 

Games almost always hide the system cursor and draw their own as part of their game render loop.

Quote
So the question is - for Quake-like mouse control - how do I stop the Windowing System cursor from moving when my window has focus?

Hide it and draw your own.


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 hawkettc

Junior Newbie





« Reply #6 - Posted 2006-02-05 06:15:24 »

Hi Jeff - that works except that even with the cursor hidden it still tracks - and when it goes past the edge of the screen - i.e. my window loses focus - the cursor reappears - I can't move the mouse infinitely in any direction - only within the bounds of my game window.  Basically just because my window hides the cursor, doesn't mean the OS X windowing system stops tracking it - I need to be able to move the mouse any distance in any direction without the OS X windowing system cursor moving.  Cheers,

Colin
Offline kevglass

JGO Kernel


Medals: 121
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #7 - Posted 2006-02-05 17:35:09 »

Quote
The ugly other option here would be to continually move the cursor back to the centre of the screen with something like the java.awt.Robot class.

If you don't want to use LWJGL then you already had the answer with the above. Its not particularly pretty but does work pretty cleanly.

LWJGL takes the line that its a game development library so do whatever it wants at the native level to make the tools available to the user - hence they can implement setGrabbed().

JInput takes the line that its a way of getting input from various devices through the native layer. Hence it doesn't have any interest in cursors, making them visible or constraining them to the screen. (which are of course output - to the screen Smiley).

You have the answer from yourself Smiley - just run with it.

Kev

Offline Jeff

JGO Coder




Got any cats?


« Reply #8 - Posted 2006-02-06 01:06:06 »

Hi Jeff - that works except that even with the cursor hidden it still tracks - and when it goes past the edge of the screen - i.e. my window loses focus - the cursor reappears - I can't move the mouse infinitely in any direction - only within the bounds of my game window.  Basically just because my window hides the cursor, doesn't mean the OS X windowing system stops tracking it - I need to be able to move the mouse any distance in any direction without the OS X windowing system cursor moving.  Cheers,

Colin

HMm.  I guess that gets into the question of how Apple intrepted cursor hidefor their JRE .  Clearly they felt it was important to make it still possible to swtich focus when i nwindowed mode.  Honestly I cant entirely disagree with them.  If you are running windowed then, at least from a systems POV, you are telling the system yo uwant access to multiple apps at once.  If it let the windowed app entirely take the cursor away then it coudl repevent acess to other apps, which breaks the window metaphor.

Is there a reason why you really want to run windowed but have what soudns like full-screen type fucntionality?  If not Id go full screen.  if so, well then yes the robot hack OR writing your own JNi to hit the OS directly might be the only solutions.

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 hawkettc

Junior Newbie





« Reply #9 - Posted 2006-02-09 10:52:05 »

Thanks - in the end I chose to port my app. to lwjgl - which means the raft of refactorings I've had in the back of my mind for a while can be implemented Smiley - you're right though - it does feel weird to have the mouse 'grabbed' in a window, but isn't to bad once you geet used to it - 'apple-tab' app switching is ok enough.  Thanks for the input - cheers,

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

Senior Newbie





« Reply #10 - Posted 2006-02-13 02:46:34 »

I tried using java.awt.Robot to warp the cursor.  It worked, but very slowly: it could take upwards of a hundred milliseconds to read the mouse position once on Mac OS X.  Windows performed significantly better, but was still sluggish.  I also tried outsourcing the cursor warping to a native C method, but that increased the lag to more than one second for some reason.

I finally wound up using the approach mentioned in this forum of freezing the cursor and reading the mouse deltas.

For freezing the cursor, use the following Carbon function (if you're on Mac OS X):
CGAssociateMouseAndMouseCursorPosition(false);

Reading the mouse deltas is a little bit more obnoxious, just because JNI can be very tempermental.

CGMouseDelta x, y;
CGGetLastMouseDelta(&x,&y);

Then x and y represent the amount by which the mouse position changed the last time the application received a mouse event.  By application, I mean the parent process that contains the JVM.  Whenever you launch a Java application on Mac OS X it seems like the JVM gets wrapped up inside a Cocoa application.  So I cannot guarantee that my techniques would work in an applet.

Now, of course my native library only works on OS X.  But I think that this behavior would not be too hard to port to other platforms.  It's obviously been done before.

If you still have any interest in using JOGL, I would be happy to post my Java and C source files, as well as my shared libraries and JARs.
Offline Jeff

JGO Coder




Got any cats?


« Reply #11 - Posted 2006-02-13 02:56:15 »

Why bother reading the XY delta with JNI?

You can do that fine from JInput and then thats that much more thats cross paltform.

As for robot, I think you missed the point.

You dont read with Robot.  You read with JInput

You just reset the cursor every frame to the center of your window with Robot.  And if you do that, you need NO JNI at all.


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 Ken Russell

JGO Coder




Java games rock!


« Reply #12 - Posted 2006-02-13 02:58:57 »

I tried using java.awt.Robot to warp the cursor.  It worked, but very slowly: it could take upwards of a hundred milliseconds to read the mouse position once on Mac OS X.  Windows performed significantly better, but was still sluggish.  I also tried outsourcing the cursor warping to a native C method, but that increased the lag to more than one second for some reason.

How well does Jake2 work on your machine? I'm pretty sure they use java.awt.Robot to implement the cursor warping and it seems to work pretty well (and portably, with no additional native code needed).

Quote
If you still have any interest in using JOGL, I would be happy to post my Java and C source files, as well as my shared libraries and JARs.

I'd personally be interested in seeing your solution but would like to know first whether the sluggish performance you saw is reproducible with e.g. Jake2. Do you have a test case for the sluggish behavior? Maybe it should be reported to Apple.
Offline Jeff

JGO Coder




Got any cats?


« Reply #13 - Posted 2006-02-13 04:10:19 »

Ken,

I think the trick here is that he misunderstood,

I believe was using Robot to *read* the cursor.

And that was what was slow.


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 prof0aronnax

Senior Newbie





« Reply #14 - Posted 2006-02-18 03:17:32 »

I know that the mouse reading functionality is available in JInput.  It's just that learning how to use somebody else's JARs always takes time and I sometimes get lazy.  That's why I wrote JNI calls.  Besides, JInput is using JNI itself.

Jake2 runs at an acceptable rate on my machine, except if you try to use the mouse.
Offline Jeff

JGO Coder




Got any cats?


« Reply #15 - Posted 2006-02-18 03:30:54 »

I know that the mouse reading functionality is available in JInput.  It's just that learning how to use somebody else's JARs always takes time and I sometimes get lazy.  That's why I wrote JNI calls.  Besides, JInput is using JNI itself.

Sure, just like JOGL has to use JNI.

The question is, would you rather keep your own JNI up to date, fully functional,  and port it yourself to every new platform you want to go or do you want to leverage what the community is already doing for you.

Your little peice of JNi isnt much, but ist also not nearly as functional as JInput.  And to reach Jinput's functionality in terms of dynamic controlelr discovery and usage as well as portability, you would have to do some major re-inveting the wheel across multiple platforms.

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 prof0aronnax

Senior Newbie





« Reply #16 - Posted 2006-02-19 20:12:16 »

I'd much rather let someone else handle the headache of writing JNI code.

Here's the thing: this mouse input issue is the one thing that might discourage me from using Java for my game.

So JInput is wonderful.  It does everything I need as far as user input goes except that it doesn't allow you to unplug the cursor from the mouse.

I've tried LWJGL for this, and it works great, but I dislike their OpenGL bindings.  It is particularly obnoxious that gluUnProject wants double-scripted projection arrays (where OpenGL uses single-scripted arrays as a rule) whereas glGetDouble gives you a DoubleBuffer.  So if I went with LWJGL, I'd need a way to use JOGL in place of LWJGL's own GL.

I've had good experiences with Simple DirectMedia Layer in C, and I know that there is a project to bind SDL to Java (http://sdljava.sourceforge.net/).  Unfortunatley, sdljava is incomplete and still missing most of OpenGL.

And I'm not satisfied with my little native library.

So what's a poor Java programmer like me supposed to do?
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #17 - Posted 2006-02-19 22:55:45 »

So what's a poor Java programmer like me supposed to do?

In my opinion we should fix JInput to do what you want. I am definitely in favor of restructuring the internals and adding new functionality where necessary. @endolf, @elias, what is the status of the OS X work that you mentioned above?

You can use JOGL's OpenGL bindings with LWJGL (and vice versa). To use JOGL with LWJGL's OpenGL context, call GLDrawableFactory.createExternalGLContext() when LWJGL's OpenGL context is current, and call GLContext.getGL() on the resulting GLContext object when you want to draw. LWJGL has similar functionality.
Offline prof0aronnax

Senior Newbie





« Reply #18 - Posted 2006-02-20 00:46:49 »

Quote
You can use JOGL's OpenGL bindings with LWJGL (and vice versa). To use JOGL with LWJGL's OpenGL context, call GLDrawableFactory.createExternalGLContext() when LWJGL's OpenGL context is current, and call GLContext.getGL() on the resulting GLContext object when you want to draw. LWJGL has similar functionality.

Thank you.  I'll try that.

Here's another question: for the time being, if I used my own native library to surpress cursor movement, would JInput still report mouse motion?
Offline Jeff

JGO Coder




Got any cats?


« Reply #19 - Posted 2006-02-20 02:15:40 »

I'd much rather let someone else handle the headache of writing JNI code.

Here's the thing: this mouse input issue is the one thing that might discourage me from using Java for my game.

So JInput is wonderful.  It does everything I need as far as user input goes except that it doesn't allow you to unplug the cursor from the mouse.

Correct.  Thats because that is an output system issue not an input system issue.

I would MUCH rather see that functionality developed in a more approiate API (really IMHo it really should be part of AWT as it is an artifact of the windowing system, not the underlying hardware,  Maybe make it a JOGL call??)

Having said that, if we really can find noone else to pick that up, I suppose we could pollute JInput's API with it.  But I rreally DO believe it woudl be a necessity driven pollution.

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 Ken Russell

JGO Coder




Java games rock!


« Reply #20 - Posted 2006-02-20 02:38:06 »

This kind of call does not belong in JOGL. This is obviously an issue related to the behavior of an input device and if it belongs anywhere it should be in JInput.
Offline prof0aronnax

Senior Newbie





« Reply #21 - Posted 2006-02-20 03:33:35 »

I think this cursor locking function is something that only game developers really need.  So it doesn't belong in a graphics API or an input API.  It belongs in a game API.  Problem is, there's no catch-all framework like SDL on the Java platform -- yet -- except for LWJGL.

So... maybe the thing to do is write another library that makes use of JInput, but can lock and unlock the cursor -- or use java.awt.Robot.mouseMove() on platforms where this is unavailable.  Then I wrap JInput's mouse functionality in my own Mouse class, and use everything else in JInput as is.  Since the Mac is the main platform on which the Robot approach causes problems, this would be a portable and environmentally friendly approach.

No need to pollute.
Offline Jeff

JGO Coder




Got any cats?


« Reply #22 - Posted 2006-02-20 03:35:07 »

This kind of call does not belong in JOGL. This is obviously an issue related to the behavior of an input device and if it belongs anywhere it should be in JInput.


Sorry Ken I 100% disagree.

A cursor is not an input device.

A cursor is a small, mobile video plane.   (or a sofwtare simulation of such a plane.)

And thus control of it belongs in video support and NOT in input.

The confusion comes because so many windowing systems DO confuse input and output badly in this area.  I strongly dislike introducing the *same* confusion into JInput.

As the issue is not really the input hardware (the mouse) or the output hardware (the cursor) but really a connection (mouse to cursor) that is an artifact of the WIndowing system, it **really** belongs in the API that controls the windowing system, which is AWT.

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 Jeff

JGO Coder




Got any cats?


« Reply #23 - Posted 2006-02-20 04:03:15 »

Proposal:  Given that I firmly believe this is not a proper peice of JInput functionality, but that I ALSO recognize the need for it.

I propose we add it to JInput2, BUT we put it in the JUtils package tree and that we document in the Javadocs that this is properly AWT functionality and the day AWT properly supports it, it will be removed..

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 prof0aronnax

Senior Newbie





« Reply #24 - Posted 2006-02-20 04:39:06 »

Sweet!  It works!  My cursor freeze doesn't block JInput!
Offline stefiqeg

Junior Newbie





« Reply #25 - Posted 2006-02-24 17:54:44 »

This works perfectly for me (with jogl):

    BufferedImage cursorImg = new BufferedImage(16, 16, BufferedImage.TYPE_INT_ARGB);
    Graphics2D gfx = cursorImg.createGraphics();
    gfx.setColor(new Color(0, 0, 0, 0));
    gfx.fillRect(0, 0, 16, 16);
    gfx.dispose();
    frame.setCursor(frame.getToolkit().createCustomCursor(cursorImg, new Point(), ""));
Offline prof0aronnax

Senior Newbie





« Reply #26 - Posted 2006-02-26 21:43:28 »

Quote
This works perfectly for me (with jogl)

Hiding the cursor is easy.  What we want is to immobilize the cursor.
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.

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

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

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

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

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

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

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (29 views)
2014-07-23 21:07:15

Riven (30 views)
2014-07-23 20:56:16
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

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24: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!