Alice Community  

Go Back   Alice Community > Alice 2 > Share Objects

 
 
Thread Tools Display Modes
Prev Previous Post   Next Post Next
Old
Mr Kidnapper
Senior Member
 
Status: Offline
Posts: 442
Join Date: Feb 2011
Default 01-05-2012, 02:11 AM

There are two kinds of "Bests" when it comes to that. You can either go with User Friendliness or Most Efficient.
I'm wagering you're looking for the most efficient method.

And so: There are two kinds of mouse calibration, scripted automatic calibration (Arty and I's), which is very user friendly due to its lack of interaction, and there is calibration point method, which involves the user clicking a small sphere located in the center of the window.

In terms of user friendliness, scripted calibration is quite nice in that it is very precise. Finding the center of the screen you will be at the most, one pixel off-center, which is a very precise fit. The biggest pros of this method is that it is completely immune to window moves and resizes.
For calibration points, it's a lot easier on the maker's end and requires no scripting. You can multiply the mouse's distance from the edges by 2 to find either the window length or width. The problems with this method is that it is not immune to resizing because it is typically only ever done once. After a window resize, the window length and widths will become inaccurate and any methods involving window itself will be screwed. Another notable problem is that it is not very precise—the region for error is as big as the radius of the sphere in pixels.

Now, let us look at efficiency. Efficiency is hard to judge in Alice; It's not as easy as in computer programming to figure out what method is the most efficient. In computer programming, you generally find the one that makes the least amount of actions. Alice is a bit different in that you don't really know how many actions it's taking because the code is very simplified.

In scripted calibration, what we do is set a variable, say WindowX and WindowY to the length and width respectively of the window screen and there we have our window size. Very easy, only two actions.

In calibration points, you get the user to click the sphere and set a variable WindowX and WindowY to the mouse distance from the left edge and top edge respectively. Now, I had actually read the source code for how Alice gets the mouse distance from the edges. What it does is find the window's position on the screen, and finds the mouse position on the screen, and subtracts the mouse's X or Y by the screen's X or Y. That is about five actions right there. Note that this method only finds half of the window's length and width, which is good for the next step.

And now to aeronautical mouse movement:
What Arty does in his Air Ace thing is that it makes the plan roll and turn at a speed of a calculated percent of 1 meter/second.
It first gets the mouse's location relative to the center of the screen, found in the previous method. Then it checks if the mouse is outside of a theoretical series around in the center of the screen called "Bounds", which forms a sort of thick cross in the center of the screen. If the mouse exceeds these lines, the camera will roll or turn in the direction the mouse is facing, unless the Y-Axis is inverted, in which case it will turn in the opposite direction.
So these "Bounds" are used to prevent movement at the center latitudes and longitudes of the screen.
Now for how the speed is calculated:
It subtracts the mouse distance from the respective edges by the center of the window, or the other way around depending on where the mouse is relative to the center of the screen (The total Window sizes divided by 2 if you used scripting.) So, the further away from the center of the window the mouse is, the faster you rotate, which is much like how real games act.
Then it divides this number by the center of the screen, getting a percent.
This number is used to revolve the object at the speed at a rate of 0.01 seconds (An arbitrary number which otherwise means "Constantly".) Due to the quick nature of this method you may want to divide it further and add sensitivity levels in order to reach the desired revolving speed.
Remember that you must do this for each of the four directions: turn up, turn down, roll left, and roll right (In event that you're using a plane.)

Extra:
In the event that you are using an organic being, things get a bit more complicated. You want your thing to turn up, down, left, and right, however the X axis, left and right, have to be set up in a special way. You need to create a dummy object that is aligned to the world (Or the ground, in the event that it is tilted) and this dummy object follows (not vehicled) the camera or object that is being rotated. Then, you must set up your rotation method to turn left or right as seen by the dummy object's X Axis. This will prevent accidental rolling of the camera and will be more like how cameras rotate around in real games. Optionally you can make a maximum turning angle for the Y Axis, so that the camera doesn't do any sort of somersaulting or ridiculous exorcist neck bending.
You can also make a mouselock for FPS makers. This however can only be done with scripting, because it requires the location of the window as well as the size of the window, because mouselocking is relative to the screen, and also because forcibly moving the mouse to a location requires scripting in the first place. This can be done with a calibration point (You have to find the mouse distance from the edges relative to the screen, which is an option in the More dropdown box.), however I do not vouch for it as it won't be immune to resizes or window moves.

Last edited by Mr Kidnapper; 01-21-2012 at 03:15 AM.
   
Reply With Quote
 

Tags
event1234, extra, gallery, models, objects

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



Copyright ©2024, Carnegie Mellon University
Alice 2.x © 1999-2012, Alice 3.x © 2008-2012, Carnegie Mellon University. All rights reserved.