Tag Info

Hot answers tagged

16

There's a number of options: Do as you do. You've already said it doesn't look smooth. There are some flaws with your current method though. For x, you could use the following: tempx += speed * dt while (tempx > 0.5) move sprite to x+1 tempx -= 1 while (tempx < -0.5) move sprite to x-1 tempx += 1 this should be better. I've switched the ...


14

One way in which many old-skool games solved (or hid) this problem was to animate the sprite. That is, if your sprite was going to move less than one pixel per frame (or, especially, if the pixels/frame ratio was going to be something odd like 2 pixels in 3 frames), you could hide the jerkiness by making an n frame animation loop that, over those n frames, ...


6

The sprite's position should be kept as a floating point quantity, and rounded to an integer only just before display. You can also maintain the sprite at super resolution and downsample the sprite before display. If you maintained the sprite at 3x display resolution,you'd have 9 different actual sprites depending on the subpixel position of the sprite.


5

Start by adding a variable for the angle that the car is moving at. float angle = Math.Pi / 2; Then add a variable for the current speed. float speed = 0.0; Now create three constants: public static final float acceleration = 0.1; public static final float maxSpeed = 5.0; public static final float rotationRate = Math.Pi / 50; For starters, get your ...


3

The only real solution here is to use bilinear filtering. The idea is to let the GPU compute the value of each pixel based on the four sprite pixels that are overlapping with it. It's a common and effective technique. You simply need to place the sprite on a 2d-plain (a billboard) as a texture; then use the GPU to render these plains. This works well but ...


1

Movement should never be dependent on framerate. Bob Nystrom wrote an excellent summary of how to write a game loop that is independent of framerate. Check it out here. He starts with the most basic game loop then makes incremental improvements, discussing the motivation behind each iteration. I've added his code here but you should really check the article ...


1

You need to separate your games logic from display logic. Game logic should run at some fixed rate (e.g. 100 ms). Display should query the state of the game and display it at unconnected rate (e.g. 10-20 ms). That way your display performance never affects the game.


1

In addition to the other answers here you can use dithering to some extent. Dithering is where the edge of an object's pixels are lighter/darker in color to match the background making for a softer edge. For example, say you had a 4 pixel square I'll aproximate with: OO OO If you were to move this 1/2 a pixel to the right, nothing would really move. But ...


1

I didn't read your code, but I would recommend having a position for "the group" and then have each alien have its own "offset" position from that group position. Then when you draw them you add the two together, and to move the group you move the one group position.


1

First use Zehelvion answer to make the car turn correctly, then: Use the timestamp, you measure how much time it took for your last iteration and use that to modulate the speed at which you are changing things. void RunGame(float deltatime) { if (key.KeyCode == Keys.Up) { Player1.speed += accelaration * deltatime Player1.speed = ...



Only top voted, non community-wiki answers of a minimum length are eligible