I try to make 2D game with C++ using SFML. I have drawn sprite and now I want to make that sprite moving automatically to random direction and when it hit wall then it bounce away and change direction. I don't know how to do auto moving sprite what bounce from wall... So please help me.
sf::Sprite has a member function setPosition (float x, float y) that you can use to set the position of the sprite before it's drawn. By moving the sprite to a new position each frame you create the impression of movement, much like a cartoon. By comparing the position of the sprite with the position of other elements in your scene, like the walls, you can calculate when 2 objects hit and take appropriate action. Typically it works like this:
Reset a clock at the beginning of a new frame, you can use sf::Clock or C++'s chrono for example.
Update the position of all elements in the scene that should be moving with something like: ObjectSpeed * Previous frame time
Draw the frame
Save time elapsed for calculating the next frame
Loop
Related
I have data for an actors movement which is being read in from a file at the start of the game. The data that gets read in contains Vector positions where the Actor should move to next. I currently have the Actor moving from Position to Position no problem... until I start to add animation to a Skeletal Mesh attached to the Actor.
My problem: How can I found out the velocity to work out which animation to play idle, walk, jog and running? It currently doesnt have a velocity as i am lerping the position:
SetActorLocation(FMath::Lerp(GetActorLocation(), newPos, 0.01));
Any thoughts on how to set the right animation based on distance travel and speed?
Should I move my Actors movement to Character so I can use AddMovementInput to get velocity. Then, If i go down that route, how to I say:
Move this character from my current position, to my next position in X amount of time giving the character the correct velocity to use in the animation selection.
Can you normalize the difference between the two vector lengths (GetWorldLocation) and use the abs(floating point) result as the X variable to put into 1D Blend Space to do idle, walk, jog, run in your Animation BP? Also be sure to account for an "acceptance radius" or else once it gets to location it won't quite get it and keep turning quickly.
Not sure why you're Lerping from Vector to Vector. I would've personally used (MoveToActor or MoveToLocation):
AMyPawn->MoveToActor(AMyActor, 90.f,true,true,false,0,true);
So much cleaner! Also MoveToLocation, using BT/BB.
On tapping on screen I`m gonna apply impulse and angular rotation to sprite to move it to the sides. But after some time OR parameters of physics body attached to sprite should go back to initial (impulse 0, angular speed = 0). What are the best ways to do that (use CCAction or on update detect parameters of physics body and change them to initial)?
If i were in your position, I would probably start a timer at the first collision of the sprite and then use a CCAction to transition to the initial state to make it look smooth. Don't know if its the best way though.
I'm working on a Little Mobile Game with Cocos2D-X and Box2D.
The Point where I got stuck is the movement of a box2d-body (the main actor) and the according Sprite. Now I want to :
move this Body with a constant velocity along the x-axis, no matter if it's rolling (it's a circleshape) upwards or downwards
keep the body nearly sticking to the ground on which it's rolling
keep the Body and the according Sprite in the Center of the Screen.
What I tried :
in the update()- method I used body->SetLinearVelocity(b2Vec2(x,y)) to higher/lower values, if the Body was passing a constant value for his velocity
I used to set very high y-Values in body->SetLinearVelocity(b2Vec2(x,y))
First tried to use CCFollow with my playerSprite, which was also Scrolling along the y-axis, as i only need to scroll along the x-axis, so I decided to move the whole layer which is containing the ambience (platforms etc.) to the left of my Screen and my Player Body & Player sprite to the right of the Screen, adjusting the speed values to Keep the Player in the Center of the Screen.
Well...
...didn't work as i wanted it to, because each time i set the velocity manually (I also tried to use body->applyLinearImpulse(...) when the Body is moving upwards just as playing around with the value of velocityIterations in world->Step(...)) there's a small delay, which pushes the player Body more or less further of the Center of the Screen.
... didn't also work as I expected it to, because I needed to adjust the x-Values, when the Body was moving upwards to Keep it not getting slowed down, this made my Body even less sticky to the ground....
... CCFollow did a good Job, except that I didn't want to scroll along the y-axis also and it Forces the overgiven sprite to start in the Center of the Screen. Moving the whole Layer even brought no good results, I have tried a Long time to adjust values of the movement Speed of the layer and the Body to Keep it negating each other, that the player stays nearly in the Center of the Screen....
So my question is :
Does anyone of you have any Kind of new Approach for me to solve this cohesive bunch of Problems ?
Cheers,
Seb
To make it easy to control the body, the main figure to which the force is applied should be round. This should be done because of the processing mechanism of collisions. More details in this article: Why does the character get stuck?.
For processing collisions with the present contour of the body you can use the additional fixtures and sensors with an id or using category and mask bits. For of constant velocity is often better to use SetLinearVelocity, because even when using impulse velocity gets lost at sharp uphill or when jumping. If you want to use the implulse to change the position of the body, then you need to use the code for the type of this:
b2Vec2 vel = m_pB2Body->GetLinearVelocity();
float desiredVel = mMoveSpeed.x; //set there your speed x value
float velChange = desiredVel - vel.x;
float impulse = m_pB2Body->GetMass() * velChange;
m_pB2Body->ApplyLinearImpulse( b2Vec2(impulse, mMoveSpeed.y), m_pB2Body->GetWorldCenter());
This will allow maintain a constant speed most of the time. Do not forget that these functions must be called every time in your game loop. You can combine these forces, depending on the situation. For example, if the at the beginning you need to make a small acceleration, it is possible to use ApplyForce to the body, and when a desired speed is to use ApplyLinearImpulse or SetLinearVelocity. How correctly to use it is described here: Moving at constant speed
If you use world with the normal gravity(b2Vec2(0, -9.81)), then it should not be a problem.
I answer for this question here: Cocos2D-x - Issues when with using CCFollow. I use this code, it may be useful to you:
CCPoint position = ccpClamp(playerPosition, mLeftBounds, mRightBounds);
CCPoint diff = ccpSub(mWorldScrollBound, mGameNode->convertToWorldSpace(position));
CCPoint newGameNodePosition = ccpAdd(mGameNode->getPosition(), mGameNode->getParent()->convertToNodeSpace(diff));
mGameNode->setPosition(newGameNodePosition);
P.S. If you are new to box2d, it is advisable to read all the articles iforce2d(tuts), they are among the best in the network, as well as his Box2D Editor - RUBE. At one time they really helped me.
I do not know if this is possible but I have an idea:
Keep the circle at a fixed position and move the background relatively. For example, during the course of the game, if the circle has a velocity of 5 towards left then keep circle fixed and move screen with velocity 5 towards right. If circle has 5 velocity towards left and screen has 3 velocity towards right, then keep circle fixed and move screen with 8 velocity towards left and so on. This should allow you to fix the circle at the center of the screen.
Another method would be to translate the entire screen along with the ball. Make everything on the screen an object that can have a velocity. And the x-component of the velocity of the ball (circle) should be the velocity of all other objects. This way, whenever the circle moves, all the other objects will try and keep up with it.
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 kinda new to all this but I am trying to make myself a simple 2D game in c++.
I have decided to do a kind of a maze type game and what I am doing for this is drawing out the maze as a texture and then having another texture as my character move around inside this maze.
However I am hugely struggling with the collision detection so that my character doesn't just walk through the walls. I have been told that I can use glReadPixels to find the colour of the background but whenever I try this it just ignores the colour and still continues on through the walls.
Can anybody please help me with this and tell me how I can do it as I cannot find anything anywhere which can help.
Thanks in advance.
Depending on the maze type, if you only have vertical and horizontal walls of unit length, you could reprezent the maze and current position in a 2D array/matrix and decide whether the new position is OK to move into based on the content of the new position in the maze matrix.
You will have to do some translation to/from matrix coordinates and screen coordinates
Advantages:
you don't need to read from the screen
maze can be larger than what fits on the screen -- draw the relevant portion only
Disadvantages:
you can only have "bolck" type terrain (e.g. vertical/horizontal walls)
if you want to add movign enemies, the collision detection can be too coarse (you cannot avoid the monster "just by a hair/pixel")