I'm using PixelToaster (a C++ library to draw to a framebuffer) for a simple 3D (ehm.. 2.5D) raycasting engine. I use the old school WASD key configuration to move the camera around (W=forward, S=backward, A=turn left, D=turn right) however I want to use the mouse for the modern freelock approach (WASD for moving and strafing, the mouse to turn head around).
I noticed that PixelToaster gives a mouselistener in which only the ABSOLUTE mouse coordinate x,y are given (relative to the window width,height). Using such coordinate system is not what I want because the turning stops as soon as the mouse x coordinate reaches the margin of the screen. (in all the commercial games you can turn around endlessly by swiping continuously the mouse in one direction).
How can I get the same behaviour using the PixelToaster mouse listener?
What you need is fairly simple to implement.
Simply reset the mouse pointer to the centre of the screen when you hit the margins.
Note that for this to work you should not "map" your 2D screen space coordinates to the angular rotation of your character. Instead have an accumulator that keeps adding up incremental changes in angle (calculated from 2D screen space movements of the mouse pointer).
Alternate Approach: You could detect when you are at the edges of your screen and keep rotating the character until you leave that edge. This way you don't need to reset the mouse pointer. For some reason I assumed that you wouldn't have a cross-hair in your game so I suggested my former approach first. :)
Related
I have some problems with the intersection functionality in SFML when I am resizing the window.
So I do fairly know how to detect intersections or if something is clicked and so on when the window is in the predefined size.
But when resizing the window, the golbal bounds of the shapes/sprites in sfml stay exactly the same while their presentation in the window changes.
So when I now click on something it may happen that the normal SFML contains method of an object tells me that the mouse pointer is not inside, even if it seems to be like that on the screen.
The only thing I have in mind is to have a variable (e.g sf::vector2f) that stores the current change of the window compared to the original size and then not use the mouse position relative to the current window but the (with the change multiplied) projected mouse position.
But this may not be the best solution, so I wonder if I am missing something and therefore I am asking for advice, what to do here?
You can use the sf::RenderWindow::mapPixelToCoords method to find out the correct position of the mouse.
From the SFML documentation:
Convert a point from target coordinates to world coordinates.
This function finds the 2D position that matches the given pixel of
the render target. In other words, it does the inverse of what the
graphics card does, to find the initial position of a rendered pixel.
Initially, both coordinate systems (world units and target pixels)
match perfectly. But if you define a custom view or resize your render
target, this assertion is not true anymore, i.e. a point located at
(10, 50) in your render target may map to the point (150, 75) in your
2D world – if the view is translated by (140, 25).
For render-windows, this function is typically used to find which
point (or object) is located below the mouse cursor.
This version uses a custom view for calculations, see the other
overload of the function if you want to use the current view of the
render target.
I'm self learning C++ and playing around 2D tile mapping.
I have been reading through this scrolling post here, which is based on this tiling tutorial.
Using the above tutorial and some help from the Pearson, Computer Graphics with OpenGL book I have written a small program that draws a 40x40 tiled world and a Sprite (also a tile).
In terms of drawing/render order, the map(or world) itself is that back layer and the Sprite is the forward most (or top) layer. I'm assuming that's a good way of doing it as its easier for 2 tiles to interact than a tile and a custom sprite or rectangle. Is that correct?
I have implemented a Keyhandling() function that lets you move the map inside the viewport using the keyboards arrow keys. I have a variable called offsetx, offsety that when a key is pressed increases or decreases. Depending on whether I assign the variable to the map or sprite, I can more one or the other in any direction on the screen.
Neither seems to work very well, so I assigned the variables to both (map and sprite) but with positive values for the sprite, and negative for the map. So upon a key press, this allows my Sprite to move in one direction whilst the map moves in the opposite direction.
My problem is, the sprite soon moves enough to leave the window and not enough to bring the more of the map into the scene. (The window only shows about 1/8th of the tiles at any one time).
I've been thinking all day, and I think an efficient/effective way to solve this issue would be to fix the sprite to the centre of the screen and when a key is pressed the map moves around... I'm unsure how to implement this though.
Would that be a good way? Or is it expected to move the viewport or camera too?
You don't want to move everything relative to the Sprite whenever your character moves. Consider a more complicated world where you also have other things on the map, eg other sprites. It's simplest to keep the map fixed, and move each sprite relative to the map, (if it's a movable sprite). It just doesn't make much sense to move everything in the world whenever your character moves around in the world.
If you want to render your world with your character always at the center, that's perfectly fine. The best thing to do is move the camera. This also allows you to zoom your camera in/out, rotate the camera, etc. with very little hassle in keeping track of all the objects in the world.
Be careful with your usage of the word "viewport". It means a very specific thing in OpenGL. (ie, look at the function glViewport). If your book uses it differently, that's fine. I'm just pointing this out because it's not 100% clear to me what you mean by it.
I am working on a simple mesh viewer implementation in C++ with basic functionality such as translation, rotation, scaling.
I'm stuck with with implementing the rotation of the object along z-axis using the mouse. What I want to implement is the following:
Click and drag the mouse vertically (almost vertical will do, as I use a simple threshold to filter slight deviations along the horizontal axis) to rotate the object along y-axis (this part is done).
Click and drag the mouse horizontally just as described above to rotate the object along x-axis (this part is done too).
For z-axis rotation, I want to detect a circular (or along an arc) mouse movement. I'm stuck with this part, and don't know how to implement this.
For the above two, i just use atan2() to determine the angle of movement. But how do I detect circular movements?
The only way to deal with this is to have a delay between the user starting to make the motion and the object rotating:
When user clicks and begins to move the mouse you need to determine if its going to become a straight line movement, or a circular one. This will require a certain amount of data to be collected before that judgement can be made.
The most extreme case would be requiring the user to make one complete circle first, then the rotation begins (in reality you could do much better than this). Just how small you are able to cut this period down to will depend on a) how precise you dictate your users actions must be, and b) how good you are with pattern recognition algorithms.
To get you started heres an outline of an extremely poor algorithm:
On user click store the x and y coordinates.
Every 1/10 of a second store the new coordinates and process_for_pattern.
in process_for_pattern you're looking for:
A period where the x coordinates and the y coordinates regularly both increase, both decrease, or one increases and one decreases. Over time if this pattern changes such that either the x or the y begins to reverse whilst the other continues as it was, then at that moment you can be fairly sure you've got a circle.
This algorithm would require the user to draw a quarter circle before it was detected, and it does not account for size, direction, or largely irregular movements.
If you really want to continue with this method you can get a much better algorithm, but you might want to reconsider your control method.
Perhaps, you should define a screen region (e.g. at window boundaries), which, when was clicked, will initiate arc movement - or use some other modifier, a button or whatever.
Then at a mouse click you capture the coordinates and center of rotation (mesh axis) in 2D screen space. This gets you a vector (mesh center, button down pos)
On every mouse move you calculate a new vector (mesh center, mouse pos) and the angle between the two vectors is the angle of rotation.
I don't think it works like that...
You could convert mouse wheel rotation to z-axis, or use quaternion camera orientation, which is able to rotate along every axis almost intuitively...
The opposite is true for quarternion camera: if one tries to rotate the mesh along a straight line, the mesh appears to rotate slightly around some other weird axis -- and to compensate that, one intuitively tries to follow some slightly curved trajectory.
It's not exactly what you want, but should come close enough.
Choose a circular region within which your movements numbered 1 and 2 work as described (in the picture this would be some region that is smaller than the red circle. However, when the user clicks outside the circular region, you save the initial click position (shown in green). This defines a point which has a certain angle relative to the x-axis of your screen (you can find this easily with some trig), and it also defines the radius of the circle on which the user is working (in red). The release of the mouse adds a second point (blue). You then find the angle this point has relative to the center of the screen and the x-axis (just like before). You then project that angle onto your circle with the radius determined by the first click. The dark red arc defines the amount of rotation of the model.
This should be enough to get you started.
That will not be a good input method, I think. Because you will always need some travel distance to discriminate between a line and a curve, which means some input delay. Here is an alternative:
Only vertical mouse having their line crossing the center of the screen are considered vertical. Same for horizontal. In other cases it's considered a rotation, and to calculate its amplitude, calculate the angle between the last mouse location and the current location relatively to the center of the screen.
Alternatively you could use the center of the selected mesh if your application works like that.
You can't detect the "circular, along an arc" mouse movement with anywhere near the precision needed for 3d model viewing. What you want is something like this: http://thetechartist.com/?p=80
You nominate an axis (x, y, or z) using either keyboard shortcuts or on-screen axis indicators that you can grab with the mouse.
This will be much more precise than trying to detect an "arc" gesture. Any "arc" recognition would necessarily involve a delay while you accumulate enough mouse samples to decide whether an arc gesture has begun or not. Gesture recognition like this is non-trivial (I've done some gesture work with the Wii-mote). Similarly, even your simple "vertical" and "horizontal" mouse movement detection will require a delay for the same reason. Any "simple threshold to filter slight deviations" will make it feel dampened and weird.
For 3d viewing you want 1:1 mouse responsiveness, and that means just explicitly nominating an axis with a shortcut key or UI etc. For x-axis rotation, just restrict it to mouse x, y-axis to mouse y if you like. For z you could similarly restrict to x or y mouse input, or just take the total 2d mouse distance travelled. It depends what feels nicest to you.
As an alternative, you could try coding up support for a 3D mouse like the 3dConnexion SpaceExplorer.
I've been using OpenGL with SFML 1.6 for some time now, and it has been a blast! With one exception: I can't seem to implement a camera class correctly. You see, I am trying to create a C++ class called "Camera". Here are my functions:
Camera::Strafe(float fSpeed)
checks whether the WASD keys are pressed, and if so, move the camera at "fSpeed" in their respective directions.
Camera::MouseMove(int currentX, int currentY)
should provide a first-person mouse look, taking in the current mouse coordinates and rotating the camera accordingly. My Strafe() implementation works fine, but I can't seem to get MouseMove() right.
I already know from reading other resources on OpenGL mouse look implementations that I must center the mouse after every frame, and I have that part down. But that's about it. I can't seem to get how to actually rotate the camera on the spot from the mouse coordinates. Probably need to use some trig, I bet.
I've done something similar to this (it was a 3rd person camera). If I remember what I did correctly, I took the change in mouse position and used that to calculate two angles (I did that with some trig, I believe). One angle gave me horizontal rotation, the other gave me vertical rotation. Pitch, Yaw and Roll specifically, although I can't remember which refers to which direction. There is also one you have to do before the other, or else things will rotate funny. I'm pretty sure it was pitch first, then yaw or roll.
Hopefully it should be obvious what the change in mouse position did. It allowed mouse senesitivity. If I moved the mouse fast, I would have a larger change, and so I would rotate "faster."
EDIT: Ok, I looked at my code and it's a very simple calculation.
This was done with C#, so bear with me for syntax:
_angles.X += MathHelper.ToDegrees(changeInX / 100);
_angles.Y += MathHelper.ToDegrees(changeInY / 100);
my angles were stored in a 2 dimensional vector (since I only rotated on two axes). You'll see I took my changeInX and changeInY values and simply divided them by 100 to get some arbitrary radian value, then converted that number to degrees. Adjust the 100 for sensitivity. Keep in mind, no solid-math was done here to figure this out. I just did some trial-and-error until I got something that worked well.
os:: windows xp sp3
Qt:: 4.6
I am playing with some 3D stuff and need to implement mouse moving. I tried with Qt mouseMoveEvent but found that is not good because mouseMoveEvent does not handle with every pixel when mouse is moved. I need somethig that register EVERY pixel of movement.
Searching for solution I cheked Qt online documentation && found QCursor class && its member pos().
Questions:: Does QCursor::pos() register every pixel in movement? Have somebody better idea for precise handling of camera wiew in 3d (i am not using openGL , building my engine in painter(it is for fun && hoby) ) ?
No, mouse may move several pixels at once.
If you need the midway points for something then calculate them. Calculate all points on line between two positions of mouse. It is still unclear to me why you need the points, but that should help.
This most likely does not have much to do with Qt, but with your mouse polling rate. You might want to refer to this quite informative blog post on Coding Horror.
Some time ago I had similar issue (I didn't use QT). Your system does not have that precise information.
What I did, was computing mouse position change (dx, dy) and using that information to move the camera. In many frameworks you don't have to compute (dx,dy) as you get that information with the event (for example SDL).
Alternatively you could compute position change and then interpolate positions between current and previous mouse position - then you could use those positions to move your camera.
You would have the same problem if you wanted to draw mouse movement on the screen. You can then use Bresenham's algorithm http://en.wikipedia.org/wiki/Bresenham's_line_algorithm to generate pixels between two given points
No, QCursor does not prvide that information, as it has no signal giving you this. You have to explicitly query its position and doing that in the mouseMoveEvent limits the precision again. The underlying window system just does not deliver that precision. Like the others said, just work with arbitrary wide movements or compute the intermediary points yourself.