How to simulate mouse cursor movement in C++ - c++

I'm creating a program on my spare time and I'm trying to simulate mouse cursor movements.
I'm trying to make it so that when I start my program it'll move my cursor from [x,y] to [0,0] (which is the top-left corner of my screen).
Is there anyway to do this without having it teleport?
Here is what I have so far for my mouse cursor movement program:
POINT p;
GetCursorPos( &p );
double mouseX = p.x;
double mouseY = p.y;
SetCursorPos(0, 0);
Any way to actually see my mouse being moved instead of just teleporting to [0,0] instantly?

You will need to gradually progress your mouse a little bit at a time. Consider, for example the following pseudo-code function:
def moveMouse (endX, endY, stepCount, stepDelay):
GetCurrentPosTo(startX, startY);
for step = 1 to stepCount
currX = startX + (endX - startX) * step / stepCount
currY = startY + (endY - startY) * step / stepCount
SetCurrentPosFrom(currX, currY)
DelayFor(stepDelay)
endfor
enddef
This calculates the current position (within the loop) as some fraction of the journey from (startX, startY) to (endX, endY), adjusting for the number of steps you wish to take.
So using a stepCount of 100 and stepDelay of ten milliseconds, the mouse cursor would smoothly move over the period of a second.
There could be other possibilities such as moving the cursor at a specific speed rather than taking a specific time, or specifying a minimum speed and maximum time to combine both methods.
I'll leave that as an extra exercise. Suffice to say it would involve the same method of moving the cursor a little at a time rather than just setting its position to the final value immediately.

Heres my little concoction from around the web!
It spins the mouse, and rather fluidly, in an Archimedean spiral from the center of the screen outward. You can also mess with the math in the loop, specifically the `cos()` and `sin()` functions to get it to do different movements. Purely for educational purposes only.
Enjoy :)
#include <Windows.h>
#include <iostream>
void moveMouse(int x, int y){
int count = 800;
int movex, movey;
float angle = 0.0f;
// set mouse at center screen
SetCursorPos(x/2, y/2);
// begin spiral! :)
for(int i = 0; i <= count; i++){
angle = .3 * i;
movex = (angle * cos(angle) * 2) + x/2;
movey = (angle * sin(angle) * 2) + y/2;
SetCursorPos(movex, movey);
Sleep(1);
}
}
int main(){
int Height = GetSystemMetrics(SM_CYSCREEN);
int Width = GetSystemMetrics(SM_CXSCREEN);
moveMouse(Width,Height);
return 0;
}

You will have to call SetCursorPos multiple times with coordinates first close to your point, then gradually closer to (0,0). Without some intentional delay it will just appear to happen instantly anyway, so keep that in mind.

Try this code I used to debug inputs.. I put it where it runs every frame. Get the mouse position, and set the mouse position. Your mouse should not be moving or the math is wrong..
{
POINT pos;
GetCursorPos(&pos);
INPUT input[1];
memset(&input, 0, sizeof(input));
int left = GetSystemMetrics(SM_XVIRTUALSCREEN);
int top = GetSystemMetrics(SM_YVIRTUALSCREEN);
int width = GetSystemMetrics(SM_CXVIRTUALSCREEN);
int heigth = GetSystemMetrics(SM_CYVIRTUALSCREEN);
// 0x1000 because 0 to 0xffff is not 65535, its 65536.
// we add 0.5f to the location to put us in the center of the pixel. to avoid rounding errors. Take it out and your mouse will move up and to the left.
POINT Desired;
Desired.x = ((float)(pos.x - left ) + 0.5f) * (float) (0x10000) / (float) (width);
Desired.y = ((float)(pos.y - top) + 0.5f) * (float) (0x10000) / (float) (heigth);
// move to new location
input[0].type = INPUT_MOUSE;
input[0].mi.dx = Desired.x;
input[0].mi.dy = Desired.y;
input[0].mi.mouseData = 0;
input[0].mi.dwFlags = MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE_NOCOALESCE | MOUSEEVENTF_MOVE | MOUSEEVENTF_VIRTUALDESK;
input[0].mi.time = 0;
SendInput(1, &input[0], sizeof(INPUT));
}

Related

A ball animation in simple harmonic motion using SDL2 and C++

I'm trying to emulate the following ball. Notice the simple harmonic motion of the ball, with the very ends of the ball bounce having a smaller velocity compared to the velocity in the middle:
I'm able to implement a bouncing ball, however it's not simple harmonic motion:
The corresponding code is as follows:
Dot::Dot() {
//Initialize the offsets
mPosX = 300;
mPosY = 0;
//Initialize the velocity
mVelX = 0;
mVelY = 4;
}
void Dot::move() {
//Move the dot up or down
mPosY += mVelY;
//If the dot went too far up or down
if( ( mPosY < 0 ) || ( mPosY + DOT_HEIGHT > SCREEN_HEIGHT ) )
{
//Move back
mVelY = -mVelY;
}
}
I have a simple harmonic motion model, like so:
The corresponding code is as follows:
Dot::Dot() {
//Initialize the offsets
mPosX = 300;
mPosY = 0;
//Initialize the velocity
mVelX = 0;
mVelY = 0;
}
void Dot::move() {
time_t current_time;
current_time = time(NULL);
mPosY = int(((460) - 10) * sin(2.4 * 2 * 3.141592 / 60 * current_time + (SCREEN_HEIGHT / 2)
));
//const int SCREEN_HEIGHT = 480
}
The issues with this implementation are that:
(1). the ball image appears every now and then, rather than continuously like in the blue ball model I tried to emulate at the very beginning
(2). the ball goes well beyond the top frame of the window, rather than slowing down at the very top of the window, again like the blue ball model.
For (2), I understand that I need to add a phase shift, i.e x in A*sin(wt + x), however changing this value doesn't do anything to prevent the ball from disappearing at the top of the window.
Any ideas on how to solve these issues?
Edit: I was able to solve (1) by doing += to mPosY rather than =, such as:
mPosY += int(4 * cos(2.4 * 2 * 3.141592 / 60 * current_time + (SCREEN_HEIGHT / 2) ));
However, I'm still unable to get the ball to bounce up and down within the frame of the window I created.
I recommend using actual simple harmonic equations.
For example, if your display dimensions are (500, 500), the center Y is 250. from there say your equation is in the form of x = acos(nt + m) + c where x is displacement (meters), a is amplitude n is for the period, for example the period (T) = 2PI/n t is time (seconds) and m is for phase shift and c is for the center. That way when you need the velocity of the object, you have a function that follows along the lines of
double Velocity(double time){
double vel = derivative_of_displacement_equation(time);
return vel;
}
And so in the program, you adjust the equation to suit the display dimensions, then you set the objects X/Y coordinates as the value returned from the displacement equation (PLUS THE CENTER OFFSET, in this example, if the center is at the middle of the screen, you would set the Y coordinate to the equation PLUS 250). Keep in mind coordinates begin at (0,0) so your displacement equation (at least the part where it involves the proportional factor, which in this case is time), you make that negative instead.
Here is some code that I believe answers your question:
#include <SDL2/SDL.h>
#include <chrono>
#include <math.h>
#include <iostream>
const double PI = 3.14159265358979;
void draw_circle(SDL_Renderer *renderer, int x, int y, int radius, SDL_Color color)
{
SDL_SetRenderDrawColor(renderer, color.r, color.g, color.b, color.a);
for (int w = 0; w < radius * 2; w++)
{
for (int h = 0; h < radius * 2; h++)
{
int dx = radius - w; // horizontal offset
int dy = radius - h; // vertical offset
if ((dx*dx + dy*dy) <= (radius * radius))
{
SDL_RenderDrawPoint(renderer, x + dx, y + dy);
}
}
}
}
double Displacement(double time, double a, double n, double m, double c)
{
double displacement = a*cos(n*time + m) + c;
return displacement;
}
int main(int argc, char* argv[])
{
SDL_Init(SDL_INIT_VIDEO);
SDL_Window *window = SDL_CreateWindow("SHM", 0, 30, 500, 500, SDL_WINDOW_OPENGL|SDL_WINDOW_RESIZABLE);// | SDL_WINDOW_SHOWN);
SDL_Renderer *renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED );
double timeDifference;
std::chrono::steady_clock::time_point start, finish;
start = std::chrono::steady_clock::now();
finish = start;
SDL_Event event;
bool running = true;
while (running){
while (SDL_PollEvent(&event)){
if (event.type == SDL_QUIT){
running = false;
break;
}
}
SDL_SetRenderDrawColor(renderer, 255,255,255,255);
SDL_RenderClear(renderer);
finish = std::chrono::steady_clock::now();
timeDifference = std::chrono::duration_cast<std::chrono::nanoseconds>(finish - start).count();
timeDifference = timeDifference / 1000000000;
///The "-(250-20) is the center y (250) minus the radius of the circle (20), and its - out the front as negative a due to coordinates
double yPosition = round( Displacement(timeDifference, -(250-20), 2, 0, 250 ) );
draw_circle(renderer, 250, yPosition, 20, {255,0,0});
SDL_RenderPresent(renderer);
}
SDL_DestroyRenderer(renderer);
SDL_DestroyWindow(window);
SDL_Quit();
return 0;
}
In general you have a0 + a/2*cos (2*𝝥*t/T + 𝝫) where a0 is the vertical position of the half of the vertical travel, a is the height of the travel, t is time, T the period ie., the time to do a complete cycle for going and coming back to the same state or uple { position, momentum }, and 𝝫 the time shift, ie., the moment where the height is at zero of the cos.
So if you want the ball to be on the floor at t=0, you want cos at the minimum, ie., 𝝫 = -𝝥/2.
You want to manage your position in function of your game's time t, so you can decouple the time to compute (which depend on your compute calpabilities) and the game's time (that you want constant from a machine to another).
Therefore you want:
auto VerticalPosition(double t)
-> double { return CorrectedScreenHeight/2*(1 + cos(2*PI*t/T + phi)); }
And you define CorrectedScreenHeight = SCREEN_HEIGHT - DOT_HEIGHT, T and phi outside, as properties of your system.
Between two consecutive images, you increment t, in order to have the correct experienced time. Typically you have 60 images/s (WPF, DirectX, web, etc), hence a period of 1.0/60s between consecutive images, this goes in your function that modifies t. The speed of your ball then depend on T, that you can tune independently.

SDL Infinite Tile Background

I'm trying to create a tiled background in SDL, one that scrolls and continues to scroll indefinitely.
So, I came up with some code and tested it out. It works well enough, but only can travel 1920 pixels along the x axis and 1080 along the Y.
Here's my code:
void Background::render(SDL_Renderer *renderer){
int Xoffset = 0;
int Yoffset = 0;
for(int y = 0; (y * 411) < 1080; y++){
for(int x = 0; (x * 405) < 1920; x++){
Xoffset = 0;
Yoffset = 0;
if(GameManager::GetInstance().getGlobalX() + (405 * x) + 405 < 0){
Xoffset = 1920;
}
if(GameManager::GetInstance().getGlobalY() + (411 * y) + 411 < 0){
Yoffset = 1080;
}
SDL_Rect backRect = {GameManager::GetInstance().getGlobalX() + (405 * x) + Xoffset, GameManager::GetInstance().getGlobalY() + (411 * y) + Yoffset, 405, 411};
SDL_RenderCopy(renderer, ResourceManager::GetInstance().getTexture("background"), 0, &backRect);
}
}
}
The getGlobalX() and getGlobalY() are where the object should be relative to the player.
You should be able to draw the 1920x1080 background more than once.
The algorithm would look something like this.
Draw a background starting at (-1920,0) (completely out of the screen)
Draw another copy of the background, this time starting at (0,0).
Every frame, draw both backgrounds one pixel to the right, so you'll have a scrolling illusion, the end of the background exiting the right will come out from the left.
Once your background at step 1 has come to (0,0), draw another background at (-1920,0) and keep scrolling.
So basically, you push two backgrounds to the right and keep putting one on the left every time you need to. This should be simple to code.

Drawing a circle in SDL 2, but each circle uses CPU a lot

i wrote a code that draw filled circle, but it uses CPU a lot.
The thing is i draw pixel by pixel, first outter circle with radius n the second circle with radius n-1 and so on while n is not equal to 0.
I'm drawing 4 pixel in e cycle, for each circle part. Every part, as i thought, has ~ Pi/(2*R) pixels, but it is not enough and circle fill wrong, so i used Pi/(4*R) and now circle fills normaly.
Deg0 = 0;
Deg90 = M_PI / 2;
DegStep = Deg90 / (R * 4);
CurrDeg = Deg0;
OffsetX = R;
OffsetY = 0;
TmpR = R;
while(TmpR>0 )
{
while(CurrDeg < Deg90)
{
OffsetX = cos(CurrDeg) * TmpR;
OffsetY = sin(CurrDeg) * TmpR;
SDL_RenderDrawPoint(Renderer, CX+(int)OffsetX, CY+(int)OffsetY);
SDL_RenderDrawPoint(Renderer, CX-(int)OffsetY, CY+(int)OffsetX);
SDL_RenderDrawPoint(Renderer, CX-(int)OffsetX, CY-(int)OffsetY);
SDL_RenderDrawPoint(Renderer, CX+(int)OffsetY, CY-(int)OffsetX);
CurrDeg+=DegStep;
}
CurrDeg = Deg0;
TmpR-=1;
}
So, is there any way to improve my realisation?
You could use the circle drawing capabilities of SDL, or you could optimize your own code by not actually using cos and sin. Use lookup tables instead.

Making balls bounce off each other (openGL)

I'm trying to make an application where balls bounce off the walls and also off each other. The bouncing off the walls works fine, but I'm having some trouble getting them to bounce off each other. Here's the code I'm using to make them bounce off another ball (for testing I only have 2 balls)
// Calculate the distance using Pyth. Thrm.
GLfloat x1, y1, x2, y2, xd, yd, distance;
x1 = balls[0].xPos;
y1 = balls[0].yPos;
x2 = balls[1].xPos;
y2 = balls[1].yPos;
xd = x2 - x1;
yd = y2 - y1;
distance = sqrt((xd * xd) + (yd * yd));
if(distance < (balls[0].ballRadius + balls[1].ballRadius))
{
std::cout << "Collision\n";
balls[0].xSpeed = -balls[0].xSpeed;
balls[0].ySpeed = -balls[0].ySpeed;
balls[1].xSpeed = -balls[1].xSpeed;
balls[1].ySpeed = -balls[1].ySpeed;
}
What happens is that they randomly bounce, or pass through each other. Is there some physics that I'm missing?
EDIT: Here's the full function
// Callback handler for window re-paint event
void display()
{
glClear(GL_COLOR_BUFFER_BIT); // Clear the color buffer
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glEnable(GL_BLEND);
// FOR LOOP
for (int i = 0; i < numOfBalls; i++)
{
glLoadIdentity(); // Reset model-view matrix
int numSegments = 100;
GLfloat angle = 0;
glTranslatef(balls[i].xPos, balls[i].yPos, 0.0f); // Translate to (xPos, yPos)
// Use triangular segments to form a circle
glBegin(GL_TRIANGLE_FAN);
glColor4f(balls[i].colorR, balls[i].colorG, balls[i].colorB, balls[i].colorA);
glVertex2f(0.0f, 0.0f); // Center of circle
for (int j = 0; j <= numSegments; j++)
{
// Last vertex same as first vertex
angle = j * 2.0f * PI / numSegments; // 360 deg for all segments
glVertex2f(cos(angle) * balls[i].ballRadius, sin(angle) * balls[i].ballRadius);
}
glEnd();
// Animation Control - compute the location for the next refresh
balls[i].xPos += balls[i].xSpeed;
balls[i].yPos += balls[i].ySpeed;
// Calculate the distance using Pyth. Thrm.
GLfloat x1, y1, x2, y2, xd, yd, distance;
x1 = balls[0].xPos;
y1 = balls[0].yPos;
x2 = balls[1].xPos;
y2 = balls[1].yPos;
xd = x2 - x1;
yd = y2 - y1;
distance = sqrt((xd * xd) + (yd * yd));
if(distance < (balls[0].ballRadius + balls[1].ballRadius))
{
std::cout << "Collision\n";
balls[0].xSpeed = -balls[0].xSpeed;
balls[0].ySpeed = -balls[0].ySpeed;
balls[1].xSpeed = -balls[1].xSpeed;
balls[1].ySpeed = -balls[1].ySpeed;
}
else
{
std::cout << "No collision\n";
}
// Check if the ball exceeds the edges
if (balls[i].xPos > balls[i].xPosMax)
{
balls[i].xPos = balls[i].xPosMax;
balls[i].xSpeed = -balls[i].xSpeed;
}
else if (balls[i].xPos < balls[i].xPosMin)
{
balls[i].xPos = balls[i].xPosMin;
balls[i].xSpeed = -balls[i].xSpeed;
}
if (balls[i].yPos > balls[i].yPosMax) {
balls[i].yPos = balls[i].yPosMax;
balls[i].ySpeed = -balls[i].ySpeed;
}
else if (balls[i].yPos < balls[i].yPosMin)
{
balls[i].yPos = balls[i].yPosMin;
balls[i].ySpeed = -balls[i].ySpeed;
}
}
glutSwapBuffers(); // Swap front and back buffers (of double buffered mode)
}
**Note: Most of the function uses a for loop with numOfBalls as the counter, but to test collision, I'm only using 2 balls, hence the balls[0] and balls[1]
Here are some things to consider.
If the length of (xSpeed,ySpeed) and is roughly comparable with .ballRadius it is possible for two balls to travel "thru" each other between "ticks" of the simulation's clock (one step). Consider two balls which are traveling perfectly vertical, one up, one down, and 1 .ballRadius apart horizontally. In real life they would clearly collide but it would be easy for your simulation to miss this event if .ySpeed ~ .ballRadius.
Second, you change in the vector of the balls results in each ball coming to rest, since
balls[0].xSpeed -= balls[0].xSpeed;
is a really exotic way of writing
balls[0].xSpeed = 0;
For the physics almost correct stuff, you need to invert only the component perpendicular to the plane of contact.
In other words take collision_vector to be the vector between the center of the balls (just subtract one point's coordinates from the other's). Because you have spheres this also happens to be the normal of the collision plane.
Now for each ball in turn, you need to decompose their speeds. The A component will be the one aligned with the colision_vector you can obtain it by doing some vector arithmetic A = doc(Speed, collision_vector) * collision_vector. This will be the thing you want to invert. You also want to extract the B component that is parallel to the collision plane. Because it's parallel it won't change because of the collision. You obtain it by subtracting A from the speed vector.
Finally the new speed will be something like B - A. If you want to get the balls to spin you will need an angular momentum in the direction of A - B. If the balls have different mass then you will need use the weight ratio as a multiplier for A in the first formula.
This will make the collision look legit. The detection still needs to happen correctly. Make sure that the speeds are significantly smaller than the radius of the balls. For comparable or bigger speeds you will need more complex algorithms.
Note: most of the stuff above is vector arithmetics. Also It's late here so I might have mixed up some signs (sorry). Take a simple example on paper and work it out. It will also help you understand the solution better.

gluLookAt Issues

I've been trying to create a roller coaster simulator in OpenGL which uses a series of gluLookAt calls to make the camera 'ride' the roller coaster. The coaster itself is based on a b-spline curve with control points in the coords array. b0(u), b1(u) etc are the blending functions for b-spline curves, with bprime0(u) etc being their derivatives. Here's the relevant part of my code:
for (int i = 0; i <= 10; i++){
for (float u = 0; u <= 1.1; u+=0.1){
x = (b0(u)*coords[(i)%10].x + b1(u)*coords[(i+1)%10].x
+ b2(u)*coords[(i+2)%10].x + b3(u)*coords[(i+3)%10].x)*2.0f;
y = (b0(u)*coords[(i)%10].y + b1(u)*coords[(i+1)%10].y
+ b2(u)*coords[(i+2)%10].y + b3(u)*coords[(i+3)%10].y)*2.0f;
z = (b0(u)*coords[(i)%10].z + b1(u)*coords[(i+1)%10].z
+ b2(u)*coords[(i+2)%10].z + b3(u)*coords[(i+3)%10].z)*2.0f;
xprime = (bprime0(u)*coords[(i)%10].x + bprime1(u)*coords[(i+1)%10].x
+ bprime2(u)*coords[(i+2)%10].x + bprime3(u)*coords[(i+3)%10].x)*-2.0f;
yprime = (b0(u)*coords[(i)%10].y + bprime1(u)*coords[(i+1)%10].y
+ bprime2(u)*coords[(i+2)%10].y + bprime3(u)*coords[(i+3)%10].y)*-2.0f;
zprime = (b0(u)*coords[(i)%10].z + bprime1(u)*coords[(i+1)%10].z
+ bprime2(u)*coords[(i+2)%10].z + bprime3(u)*coords[(i+3)%10].z)*-2.0f;
Coords nvector = {xprime,yprime,zprime};
float magn = sqrt(nvector.x*nvector.x+nvector.y*nvector.y+nvector.z*nvector.z);
nvector.x= nvector.x/magn;
nvector.y= nvector.y/magn;
nvector.z= nvector.z/magn;
glLoadIdentity();
if (rotateCam == 1){
theta+=0.0001;
if (theta > 360) {
theta = 0;
}
gluLookAt(20*cos(theta),15,20*sin(theta),0,0,0,0,1,0);
}//if
else{
printf("%f\t%f\t%f\n", x+xprime,y+yprime,z+zprime);
gluLookAt(x,y+1,z,x+xprime,y+yprime,z+zprime,0,1,0);
}//else
}//for
}//for
The spacebar switches the 'rotateCam' variable, which is supposed to switch between two viewing modes; one which circles the camera around the coaster (the 'if' statement) and one which rides the coaster (the 'else' statement).
Here's the thing: the circling mode works fine, and switching between modes works fine, but the camera is always stationary in the 'ride' mode. The printf statement shows that x, xprime, y, yprime etc are all changing with each timer tick, but the camera never moves.
If more code is needed let me know.
gluLookAt doesn't position the cemera, it only rotates it to the correct angle. After this it is up to you to also translate it. So this should do the trick:
gluLookAt(x,y+1,z,x+xprime,y+yprime,z+zprime,0,1,0);
gluTranslated(x,y+1,z);