Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 36

Thread: Mouse pointer 'set position' or bust!

  1. #11
    Senior Member
    Join Date
    May 2010
    Posts
    207

    Re: Mouse pointer 'set position' or bust!

    The thing that the "activeden" demo does is trivially easy - however, it does not (and cannot) do what PC-based FPS's do with the mouse. You can pan across the field of bubbles for a while - but when you reach the edge of the screen - you can't turn any further in that direction. It's using the rate of change of position of the mouse like an FPS does - but because it can't reset the cursor to the middle of the window - you keep running out of screen.

    There is no doubt that you could implement a scheme that panned or tilted the camera by an amount that's proportional to the distance from the center of the window - but that leaves you with the "running out of screen" problem.

    You could get around that by moving the camera at an angular velocity that's proportional to that distance of the mouse from the center. When the mouse is in the middle of the window - the camera stays still - the more you move the mouse away from the center, the faster the camera moves. This certainly gets around the "running out of screen" problem.

    But the problem with that (trust me - I've tried it) is that it's hard for the player to stop the camera exactly where he wants it to be because it's not clear where the "center" of the screen is. You can't find the "null point" easily enough when the action gets hot. This problem is 100 times worse in a classic FPS where the mouse controls not just the camera - but also the direction you're moving in. With a velocity-control system, you just can't get yourself pointed in the right direction reliably enough and you wind up lurching around like a drunkard!

    However, in a console-based game, that's exactly how the joystick works. The further the joystick is moved away from the center, the faster the camera turns. But the only reason that works well is because joysticks have a physical spring that returns them to the center position when you release them. So you can stop moving at any time by just letting go of the joystick.

    The mouse doesn't have that - so in conventional FPS's, you have to rely on RELATIVE mouse movement - not on it's absolute position. That means that when you stop moving the mouse, the relative motion goes to zero automatically and the camera stops moving - which is like releasing the joystick and letting the spring recenter it.

    In effect, you're mapping the velocity of the mouse to the velocity of the camera...or (if you prefer) the position of the mouse to the position of the camera...but that's the problem. If you use the position of the mouse - then you're limited to positions that lie inside the browser window...and now you can't keep on spinning the camera around without "running out of screen".

    So the mouse is basically a bust...we can't map mouse position onto camera velocity and we can't map mouse position onto camera position either.

    Using the keyboard arrows has some of the same properties as a joystick or relative-mouse-movement system - when you release the keys, you're returned to the "null" position. In a sense, your finger pressure on the key maps to camera velocity - and releasing your finger makes that go instantly to zero.

    But the trouble with keyboards is that they aren't proportional devices - a key is either down or it's not - so camera speed becomes a binary property. You can't control the speed at which you move the camera. Either it's too fast and the world swirls past dizzingly while you're looking carefully for something in your visual field - or it's too slow for a 'quick look' to your right or left and you feel like your head is stuck in treacle!

    But it's worse even than that. Doing even that little with the keyboard is a nightmare because of N-key rollover issues. Most PC keyboard hardware can't reliably detect more than two keys held down at the same time...unless those keys are selected very carefully - AND with a knowledge of the underlying keyboard switching matrix that varies from one keyboard to another in ways that are impossible to detect automatically.

    Try this...hold down any two keys and start pressing other keys nearby...pretty soon you'll find that some don't register. On my beloved GoldTouch keyboard, if I hold down (say) 'A' and 'C' then the 'S' and 'F' keys still work - but the 'D' key doesn't. But on my Dell Laptop, 'D' works just fine but 'F' doesn't! That's a hardware restriction - and it's very difficult to work-around because there are a bunch of different keyboard controllers out there in the world, and you can't query which you have - and they aren't compatible.

    This makes two-handed keyboard play decidedly problematic. If someone is using W,A,S,D to move around and other keys to drive camera motion - then they will interfere with each other and you'll find that if you (say) try to move diagonally by holding down W and D together - that suddenly some other random key will stop working and maybe you can't jump anymore!

    So this is rather a fundamental problem.

    In an ideal world, we'd be able to stick an analog joystick onto every phone and keyboard or issue game-pad controllers to everyone who plays an online game...but that's not the kind of thing that can happen overnight. Worse still, the world is leaping forward in the direction of touch-screens - and that makes things MUCH worse because it eliminates even the possibility of repositioning the cursor!

    If online 3D gaming truly takes off on the PC - then I think we should expect to see the return of the USB gamepad. With people playing games on iPad's and the like, they aren't going to want to have their fingers covering up the action - so the touch screen is a non-solution as an input device...so there is a problem there too.

    Using tilt sensors in cameras and pads has a similar problem to the mouse - you have to map tilt angle onto camera velocity - and finding that null position is like balancing a ball on a book!

    For 3rd person games, I think the answer is fairly clear - position the mouse (or your finger) on top of your avatar to stand still - move it further away in the direction you want to move to start the guy walking - the larger the distance, the faster he moves. We're using mouse position to control avatar/camera speed...but because your avatar is a focal point for your attention, it's easy to see how to stop the motion. It's not ideal - but it does work. Another nice thing about 3rd person games is that camera control is MUCH less critical. In an FPS, you need the two-handed style where one hand is on the mouse - controlling the camera and the direction you're walking in - the other controlling the speed of movement and allowing you to step sideways and backwards.

  2. #12
    Junior Member
    Join Date
    Dec 2010
    Posts
    10

    Re: Mouse pointer 'set position' or bust!

    Thanks for your thoughts.. And Jesus that was a marathon. Thanks for your effort.

    The demo you have seen was of course a 2D sort of thing. But applying this to 3D-space you would not have the border issue (as you would just keep spinning around - you just named it yourself). So far I still think this is the best basic approach. It is not meant to be the same like FPSīs - but to more conveniently pan the view. All your statements have been true (so far I can tell) and I agree about that "null"-issue. It might not be very user-friendly once it struggles to tell the null-point. So this got to be investigated. Maybe by applying a bigger tolerance for the null-point might let you keep the control. There is got to be something to do to improve on that.. I can see no other option to this. Users (like me) wont ever play FPS just on a keyboard (even if they could). Moving just by mouse (via button-overlay) or by touching screens should be additional options - not the only available control-style.

    This is not even affecting just FPS-games (3rd-Person-Shooters as well^^). Think of it as a more convenient solution to just walk around in 3D-space without necessarily holding a gun in your hand. How else would you explore 3D-environment? Surely not by crappy ways to control your avatar. People would more likely refuse this as trying to cope with that.

    I am not trying to give you a hard time - further I thank you for your honest reply. I am just a little concerned about this. And I wonder whether its just the few of us wondering about the future of conveniently exploring the 3D-space..


    I think this will be worth investigating. In case we fail - I am highly interested what would be plan C. So thanks, Steve and all the others don't hesitate to speak your mind.

    Reg
    KK

  3. #13
    Senior Member
    Join Date
    May 2010
    Posts
    207

    Re: Mouse pointer 'set position' or bust!

    The demo you have seen was of course a 2D sort of thing. But applying this to 3D-space you would not have the border issue (as you would just keep spinning around - you just named it yourself).
    I disagree - it doesn't matter in the slightest whether it's 2D or 3D. In that demo - when you move the mouse out to (let's say) the extreme left side of the window - the sideways motion of the bubbles stops - and now you have no way to move any further to the left. If this were in 3D, you might see a doorway off to the left there where you want to go...and you can't get there because you've run out of window.

  4. #14
    Junior Member
    Join Date
    May 2010
    Posts
    16

    Re: Mouse pointer 'set position' or bust!

    I thought of a sensible solution, but it is not how browsers work now, so it is purely theoretical.

    Because of touch devices, any browser-based interface should only rely on two types of mouse actions: 1. some point is clicked, 2. a drag starts, goes through some intermediate points, and ends.

    Now, if an user starts a drag action in browser window using a mouse, and if mouse is dragged outside the window, it could still be sending events to the page (until the drag ends), even with negative coordinates.

    It poses no security risk and is compatible with touch devices (when a touch device user hits the screen border, he has to release and start another drag to pan further).

    So in case of a FPS, shooting would have to be implemented as a keyboard-driven, and the user would have to keep a mouse button pressed all the time, but other than that, it would work as expected on desktop computers.

  5. #15
    Junior Member
    Join Date
    Dec 2010
    Posts
    10

    Re: Mouse pointer 'set position' or bust!

    @Steve: I can think of it this way: You have a camera in space. Imagine to apply actions to the camera - call this action through (an invisible) 2DOverlay/Button. So you might have 4 buttons on the screen. One for each direction. Now apply the action to the button which changes the rotation of the camera by a vector. The further you move away from center - the faster the cam spins. So even if you spin real slow, you would actually keep on spinning this way. Havenīt tried it yet. But it sounds plausible to me..

    @kguciek: we have to do better than that. I checked the control-style you mentioned before. It would still be a pain for FPSīs. This might be the best we have so far but it is not very intuitive nor user-friendly + unless there wont be some improvement you will experience that its barley capable of handling keyboard and mouse input.

    So there is still a fair bit of work to do. Lets stay in touch once anybody has a possible solution.


    Regards
    KK

  6. #16
    Senior Member
    Join Date
    May 2010
    Posts
    207

    Re: Mouse pointer 'set position' or bust!

    What you are saying (in a rather complicated way) is that you want to map the POSITION of the mouse to the VELOCITY of the camera motion. As I observed before, this is a tricky thing for the user to control because (s)he has to be able to instinctively move the mouse to the center of the screen in order to make the camera stop moving. This is tricky to do while you are concentrating on things other than where the mouse cursor is. In a FPS, you're looking for bad guys - not watching the mouse pointer.

    In practical terms, the issue is "finding the null point" - the place where all motion stops.

    It has been suggested that you have a large "dead zone" in the center of the screen to make it easier to hit - and that's certainly possible (and necessary!) - but in practical use, it still doesn't solve the problem. What happens is that once you get the mouse just into the edge of the dead zone, and the camera stops moving - the player (who, remember, is doing this on a subconscious level while trying to actually concentrate on the game action) only notices that the camera stopped. Now, the mouse pointer is right on the edge of the dead zone. If he wants to move the camera in one direction, the tiniest of movement will set it moving again - but if he wants to move in the other direction - he has to move the mouse all the way across the dead zone to get it going again. It turns out that this feels really bad.

    But no matter how you phrase it or implement it - you're down to four kinds of basic options:

    1) Mouse velocity maps to camera velocity...what conventional FPS's do.
    2) Mouse position maps to camera velocity...what you're proposing.
    3) Mouse velocity maps to camera position...unplayable!
    4) Mouse position maps to camera position...actually, the same thing as (1).

    Every scheme you can possibly imagine boils down to one of those four things...and they are the only four...unless you're going to try:

    * Mouse position maps to camera acceleration.
    * Mouse velocity maps to camera acceleration.
    * Mouse acceleration maps to...etc

    But these are even harder to control than the earlier ones.

    I suspect that in the end, we're going to have to go with some variation of (2) - because of touch-screens. But it's not nice.

    -- Steve

  7. #17
    Junior Member
    Join Date
    Dec 2010
    Posts
    10

    Re: Mouse pointer 'set position' or bust!

    True! I admit this would not work well for FPSīs. So kguciek mentioned the best solution so far (which still is not very intuitive, though).

    What else can be done? Canīt we somehow prevent people to access/manipulate the command "set position"? Any additional ideas? Anyone?!

  8. #18
    Junior Member
    Join Date
    Dec 2010
    Posts
    1

    Re: Mouse pointer 'set position' or bust!

    I have been working with something that "kind-of" works...
    It isn't something that one would hope for - it's a java applet. But that's what it is... mouse control with the Robot class in java.

    Hmm no way to attach something? Well i guess you guys will have to compile this on your own. Package it into a jar, digitally sign it and make sure it has full permissions. BlueJ (google it) will package it and give it full permissions - at least it did for me. You will still need to self sign it though. Anyway code:

    CenterMouseMain.java :
    Code :
    import java.awt.Button;
    import java.awt.event.ActionEvent;
    import java.awt.event.ActionListener;
    import java.awt.event.KeyEvent;
    import java.awt.event.KeyListener;
    import javax.swing.JFrame;
    import javax.swing.JLabel;
     
    public class CenterMouseMain extends java.applet.Applet implements ActionListener{
     
        JFrame frame = new JFrame("CenterMouse");
        JLabel label;
        Button launchButton;
     
        public void init(){ 
            resize(140,30);
     
            MouseMoveWindow win = new MouseMoveWindow();
     
            label = new JLabel();
            label.setText("<html><font color='blue'><u>Center Mouse</u></font>
     
    Alt+Tab back
    to this window
    and press Escape
    to stop it.</html>");
            win.add(label);
     
            frame.getContentPane().add(win);
            launchButton = new Button("Run CenterMouse");
            launchButton.addActionListener(this);
            this.add(launchButton);
     
            frame.addKeyListener(new KeyListener(){
                @Override
                public void keyPressed(KeyEvent event){
                    if(event.getKeyCode() == KeyEvent.VK_ESCAPE){
                        ((MouseMoveWindow)(frame.getContentPane().getComponent(0))).stop();
                        frame.setVisible(false);
                    }
                }
     
                @Override
                public void keyReleased(KeyEvent arg0){}
     
                @Override
                public void keyTyped(KeyEvent arg0){}
            });
        }
     
        @Override
        public void actionPerformed(ActionEvent arg0) {
            frame.pack();
            frame.setVisible(true);
            ((MouseMoveWindow)(frame.getContentPane().getComponent(0))).start("time", 100);
        }
    }

    MouseMoveWindow.java :
    Code :
    package CenterMouse; 
     
    import java.awt.AWTException;
    import java.awt.Color;
    import java.awt.Dimension;
    import java.awt.MouseInfo;
    import java.awt.PointerInfo;
    import java.awt.Point;
    import java.awt.Robot;
    import java.awt.Toolkit;
    import java.util.Timer;
    import java.util.TimerTask;
    import javax.swing.JPanel;
     
    public class MouseMoveWindow extends JPanel {
     
        private static final int WIDTH = 150, HEIGHT = 100;
     
        private Timer timer;
        private TimerTask resetMouse;
        private TimerTask resetMouse2;
        int condAmountSquared;
     
        public MouseMoveWindow(){
            setPreferredSize(new Dimension(WIDTH, HEIGHT));
            setBackground(Color.white);
        }
     
        public void start(String condType, int condAmt){
            if(condType.compareTo("time") == 0){
                resetMouse = new ResetMouse();
                timer = new Timer();
                timer.scheduleAtFixedRate(resetMouse, 0, condAmt);
            }else if(condType.compareTo("distance") == 0){
                condAmountSquared = condAmt*condAmt;
                resetMouse2 = new ResetMouse2();
                timer = new Timer();
                timer.scheduleAtFixedRate(resetMouse2, 0, 100);
            }else{
                resetMouse = new ResetMouse();
                timer = new Timer();
                timer.scheduleAtFixedRate(resetMouse, 0, condAmt);
            }
        }
     
        public void stop(){
            timer.cancel();
        }
     
        private class ResetMouse extends TimerTask {
            @Override
            public void run() {
                try {
                    Robot robot = new Robot();
                    Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
                    robot.mouseMove((screenSize.width/2), (screenSize.height/2));
                } catch (AWTException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            }
        }
     
        private class ResetMouse2 extends TimerTask {
            @Override
            public void run() {
                try {
                    Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
                    Point pt = (MouseInfo.getPointerInfo()).getLocation();
                    int centerX = (screenSize.width/2);
                    int centerY = (screenSize.height/2);
                    int xDiff = pt.x - centerX;
                    int yDiff = pt.y - centerY;
                    if((xDiff*xDiff + yDiff*yDiff) > condAmountSquared){
                        Robot robot = new Robot();
                        robot.mouseMove(centerX, centerY);
                    }
                } catch (AWTException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            }
        }
    }

    P.S.
    Sorry for crap coding... I dont normally use java. But I cooked this up to test the concept. Just make sure javascript can tell when the mouse was set back to the center of the screen (not too hard because it happens instantly with each timer tick). I've gotten ok results so far... So what do you guys think?

  9. #19
    Senior Member
    Join Date
    May 2010
    Posts
    207

    Re: Mouse pointer 'set position' or bust!

    Well, I don't think there was ever a doubt that you could do it in Java - but most people disable Java on their browsers.

  10. #20
    Junior Member
    Join Date
    Dec 2009
    Posts
    8

    Re: Mouse pointer 'set position' or bust!

    Actually there is a proposal for setting the mouseposition in the mozilla wiki but i can't seem to find it anymore.

    It was a bit like this.

    First you needed to request a fullscreen mode and this needed to be approved of by the user.
    secondly you needed to request the mouse setting api and this also needed to be approved by the user.
    thirdly IF both were granted then you could use them but the fullscreen would have a small bar showing the key to both disable the mouse postioning system and fullscreen.

    Also You need to be fullscreen to be able to set the mouse postion

Page 2 of 4 FirstFirst 1234 LastLast

Similar Threads

  1. Replies: 1
    Last Post: 12-27-2012, 06:03 PM
  2. Replies: 3
    Last Post: 01-22-2012, 06:29 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •