Hi everyone,First off let me say that I've been browsing this forum as a guest for a while now, and the community really seems to be friendly compared to some places I've seen in the past and I hope that I can contribute as much as I've seen people do. It really is a pleasure not seeing anyone being flamed because of the level of intellect they may or may not have

Moving on to business then. As much as I've scoured the internet in search of information concerning Java game programming, I've found that this forum in addition to some other sources are close enough to the best you can be lead to. I've got a problem with positioning and rotation in a top down car game I'm building and all the resources I've seen so far do not go through as much detail as I would hope concerning certain aspects.

The following code is what I have presently, and it would be of great help if someone could point me in the right direction or tell me what is actually being done wrong.

Well there is your problem If you keep adding a double to an int, the decimal part gets chopped off. So if you start out with 0, you add 0.5 to it, x is still 0!Change x and y to double then in your render() method, use (int)Math.round(x) and (int)Math.round(y) in your drawImage() method

Ahhhh! that seems to have fixed the problem somewhat, but I believe there is still a problem relating with the rotation of the image in the render? In addition to that, it the movement for the rotation doesn't feel smooth, and I think the problem for that is because it doesn't move in the direction the sprite is headed towards. Can you think of any idea why?BTW, I should have thought of changing the x and y variables then typecasting them to integers inside my render but I've been on this problem for quite a while, at least a week and I couldn't figure out why! so I guess a second pair of eyes really do help!

Hahaha the problem was indeed the rotation!, but if you notice my call to the rotation function in the graphics2d class used degrees instead of radians, which required a simple solution Math.toRadians(rotation) and voila the trick is done. Everything seems to be fine for now, I'll just run a few tests a see what gives!

The variables for speed and acceleration are initialized with 0 and .3 respectively...

You'll probably find that the movement feels very strange at the moment, because you're using a one-dimensional speed which rotates with the car. I don't have any worthwhile experience with car games, but I would guess that you'll want to use a full vectorial speed and then add a friction component to damp speed perpendicular to the facing of the car so that you corner in a way which feels right.

The variables for speed and acceleration are initialized with 0 and .3 respectively...

You'll probably find that the movement feels very strange at the moment, because you're using a one-dimensional speed which rotates with the car. I don't have any worthwhile experience with car games, but I would guess that you'll want to use a full vectorial speed and then add a friction component to damp speed perpendicular to the facing of the car so that you corner in a way which feels right.

Actually movement on the level of acceleration in any angle feels relatively smooth, but the actual problem is while steering the car left or right. It feels choppy and I think thats due to the rotation step, but I don't know how to calculate a smooth rotation other then trial and error. Any ideas?

EDIT: Also forgot to mention something about handling acceleration and reverse for the car. I think this is probably a bad way to handle things but here it is anyway. If you also have any ideas how to handle this any better, please share

The variables for speed and acceleration are initialized with 0 and .3 respectively...

You'll probably find that the movement feels very strange at the moment, because you're using a one-dimensional speed which rotates with the car. I don't have any worthwhile experience with car games, but I would guess that you'll want to use a full vectorial speed and then add a friction component to damp speed perpendicular to the facing of the car so that you corner in a way which feels right.

Actually movement on the level of acceleration in any angle feels relatively smooth, but the actual problem is while steering the car left or right. It feels choppy and I think thats due to the rotation step, but I don't know how to calculate a smooth rotation other then trial and error. Any ideas?

It seems that trial and error is the best way here. Try lowering the rotation step and analyzing the output.

EDIT: Also forgot to mention something about handling acceleration and reverse for the car. I think this is probably a bad way to handle things but here it is anyway. If you also have any ideas how to handle this any better, please share

When I release my key, I want it to decelerate to 0, thus the slowdown variable, although I could just shove the speed -= acceleration in the keyreleased which would probably increase performance... hmmm, well good eye!

EDIT: Actually removing the variable wouldn't work because there would be no deceleration and I can't just currentSpeed -= .1 inside keyReleased since the action is only being done once.

When I release my key, I want it to decelerate to 0, thus the slowdown variable, although I could just shove the speed -= acceleration in the keyreleased which would probably increase performance... hmmm, well good eye!

EDIT: Actually removing the variable wouldn't work because there would be no deceleration and I can't just currentSpeed -= .1 inside keyReleased since the action is only being done once.

You don't want -=, you want *=, as per usual with friction. Then set it to 0 if it gets too low.

The best to do this is to have an update() method that is called at a regular interval. Then when a user presses a key, you set the rotation and acceleration accordingly so they would be updated next time udpate() is called. When a user releases a key, you set it so next time update() is called, you start decelerating.

The best to do this is to have an update() method that is called at a regular interval. Then when a user presses a key, you set the rotation and acceleration accordingly so they would be updated next time udpate() is called. When a user releases a key, you set it so next time update() is called, you start decelerating.

Conceptually I disagree with you. In my opinion, friction should be applied at all times, given that it is in fact friction. Even when you are accelerating you are under the effect of a small amount of friction (like 0.05). When you are decelerating, you would be increasing the friction (you're hitting the brakes), but that doesn't change that friction should always be applied.

The best to do this is to have an update() method that is called at a regular interval. Then when a user presses a key, you set the rotation and acceleration accordingly so they would be updated next time udpate() is called. When a user releases a key, you set it so next time update() is called, you start decelerating.

Conceptually I disagree with you. In my opinion, friction should be applied at all times, given that it is in fact friction. Even when you are accelerating you are under the effect of a small amount of friction (like 0.05). When you are decelerating, you would be increasing the friction (you're hitting the brakes), but that doesn't change that friction should always be applied.

Yes, in the update() method, you would apply friction and all the other variables.

I know using Math.round(currentSpeed) is probably not the smartest thing, but its what halts my vehicle once the speed gets near 0. In addition, what would be the proper way of implementing friction, should I change to use vectors? I'm sure that would simplify the process, but would that work without using a grid?

1. Do you only call move() when you start slowing down?2. Friction is best implemented by taking a tiny percentage off the currentSpeed, eg. currentSpeed *= 0.95;3. Let us focus on what is malfunctioning. Is the rotation still not working?

2. Friction is best implemented by taking a tiny percentage off the currentSpeed, eg. currentSpeed *= 0.95;

Implementing this makes my coordinates go 'wako'.

Quote

3. Let us focus on what is malfunctioning. Is the rotation still not working?

Rotation is functioning but is 'choppy' as I stated earlier. I would have thought there would be a better way then trial and error, but the rotation really doesn't feel smooth. And well reverse is fixed but like I said, I'm sure there is a better way for doing it instead of rounding currentSpeed.

3. Let us focus on what is malfunctioning. Is the rotation still not working?

Rotation is functioning but is 'choppy' as I stated earlier. I would have thought there would be a better way then trial and error, but the rotation really doesn't feel smooth. And well reverse is fixed but like I said, I'm sure there is a better way for doing it instead of rounding currentSpeed.

There really is no reason to round. If the car is not moving then the currentSpeed == 0. If the speed is between 0.0 and 0.5, your code will interpret that as stationary when you're actually moving.

I also just noticed: Why do you subtract 1 from the ay after the Math.cos()?

then the x and y coordinates seem to radically shift in one update loop. I don't know if you understand what I mean, but I can post my whole class here if need be to illustrate? what is actually happening when I use friction. Note that it's very possible I'm the one messing something up, since my math skills aren't exactly up to par.

As for not rounding... I know in a normal situation you probably wouldn't need to, but if I consider not rounding inside my update function, the car still travels with minimal speed whether it be in forward or in reverse.

And I multiply* but -1 so that my y coordinate travels in the proper direction, instead of going backwards (or in a car someone might think of it as going in reverse)

then the x and y coordinates seem to radically shift in one update loop. I don't know if you understand what I mean, but I can post my whole class here if need be to illustrate? what is actually happening when I use friction. Note that it's very possible I'm the one messing something up, since my math skills aren't exactly up to par.

I still don't understand why you would apply the friction to the x and y! Friction is applied to acceleration!

2. If I change the move method to integrate friction as Eli Delventhal mentioned giving

1 2

x *= (1-friction);y *= (1-friction);

Eli suggested doing that to the velocity, not the position (or the acceleration).

I think there are two problems which might explain your choppy rotation. First, you should just use the keyPressed()/keyReleased() functions to set/clear boolean variables leftPressed, upPressed, etc. Never put code that updates game objects in those functions. Move your 'maths' code into the move()/update() functions instead, and make it use leftPressed, etc.

Second, you've got a value deltaTime that you're not using. I'm assuming from that that your game loop uses variable time steps, i.e., the time between calls to update() may be different each time. (You could try printing out the value of deltaTime to check this.) If so, you will need to multiply speeds and accelerations by (something proportional to) deltaTime to compensate. For example, if the car is moving at one metre per second, but the time between calls to update() is sometimes one second, sometimes ten seconds, you can see that the amount you need to move the car isn't simply equal to the current speed.

I know using Math.round(currentSpeed) is probably not the smartest thing, but its what halts my vehicle once the speed gets near 0. In addition, what would be the proper way of implementing friction, should I change to use vectors? I'm sure that would simplify the process, but would that work without using a grid?

You are essentially using vectors split out into components, that's fine. You don't want to add or subtract .1, you want to multiply by 0.9 or 0.95.

And friction is not applied to acceleration, it's a separate force upon the object, so you apply it to the closest thing we have to cumulative force - velocity. Force is just velocity times mass, so we're merely taking mass out of the picture as it's rarely needed for simpler physics simulations like this. The car's acceleration from its engine and the friction applied from the ground are separate forces (aka separate changes in velocity) so they are applied separately.

dishmoth has all good points, definitely try to implement what he's talking about.

Alright so I fixed up the code to use 4 booleans for the keys pressed and came out with this. I know the proportion isn't included because I'm not sure to go about it. If anyone code share some thoughts on it I'd appreciate it!

That whole thing with the seconds variable looks weird.Multiplying acceleration (0.1) with seconds (which is likely to be less than 1) is going to output an even smaller number, causing your acceleration to be tiny.

deltaTime is the difference of time between the last iteration and this iteration of the call to move().You should be checking to see if the deltaTime is different from the actual deltaTime you want, eg, 60 times a second or 16-17 milliseconds (preferably 16,667 nanoseconds)Then have a scale variable to adjust accordingly.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org