InputController should be a private inner class of Game so it can use Game's instance variables and methods.

Hahahahaha I actually thought about this in the beginning, seeing as it is how it is done in one of my Java books that I own and occasionally use as a reference. I guess I just really wanted to see if I could have used a separate file as it seems like my game class will be huge with the controller included inside it. Also having made the change I feel like the code really IS much neater and easier to understand with the usage of the entity class of course.

On a side note: I really hate going back to the move function but to be totally honest I really need clarity. I was playing around with it and I just want to know if you guys can tell me why it isn't working the way I want it to. Easy example is I want the to travel 100 pixels in 4 seconds. This is the current way that its being done, and odviously the wrong way. It is really making me angry as to why I can not get such a simple concept through my head.

Do you mean that you want the car to cruise at a maximum speed of (100/4=)25 pixels per second? Or that you want the car to accelerate from zero to its maximum speed in 4 seconds, and to have travelled 100 pixels while doing so?

The first statement is correct. But I don't know what you mean by the second statement. If (100/4) is the speed, then (100/4)*deltaTime is the distance travelled...?

I'm going to claim that the following code will do what you want if you set the correct values for acceleration, topSpeed and rotationSpeed. I think you should probably convince yourself that everything else is working before including friction, etc. (Two specific problems with your old code. First, the two separate speed variables vx and vy didn't make sense. Second, if your function is using the time step length deltaTime, then when that equals zero the function should do nothing - your code was failing that sanity check.)

Alright finally that really clears it up. I guess I was just being confused all around with friction and multiple velocities instead of just using a single velocity for both x and y. Here is what it comes out to. Note that I did add friction . I am really pleased with how that turned out, and hopefully it is done the correct way . I'm glad to say I understand what is actually happening now that its done step by step.

I would also appreciate it if anyone could tell me exactly what the difference is between using the graphics object or using an AffineTranform object. Lastly I would like to say that I apologize for all the jumping around between the code I've been doing. Can't seem to stick around one area long enough to complete it! I guess once I get confirmation that the move method is now correct I can say at least one task is complete.

I would also appreciate it if anyone could tell me exactly what the difference is between using the graphics object or using an AffineTranform object.

The Graphics2D object is where you put the graphics (think bitmap) and the AffineTranform says how you put them there.So you load an image, rotate it (AffineTranform) and draw it on a piece of paper (Graphics).I doubt using Graphics2D.rotate() is very efficient - I'd use Graphics2D.drawImage(image, affineTrans... instead.Also, ditch all the toRadians() stuff! Work in radians: 360 degrees = 2PI radians, 90'=1.571 rad . (*blush* I still have a circular chart on my wall showing degrees/radians conversion).

To me it does seem strange though that I need to have a rotationSpeed of 90 for it to rotate at a decent rate.

A rotation speed of 90 degrees per second means it will take 4 second for the car to turn all the way around (360 degrees). Which doesn't seem unreasonable.

Quote

And on a kind of related note, I'm having troubles with collision detection because of the rotation.

Start with a Rectangle2D object. Create an Area object from it. Apply an AffineTransform (rotation) to that object. (You may need to browse the JDK documentation for some of this...) Then use it to check for collisions.

Here's the important bit: Use Graphics2D.draw() to display the Area object each frame, or you won't have a clue what's going on. (I guess I didn't need to say that though, because you're doing it already with the bounding boxes.)

Quote

I guess once I get confirmation that the move method is now correct I can say at least one task is complete.

I'd suggest creating (and rotating) a new Area object each frame. The cost in terms of efficiency is negligible (unless your game features a very large number of cars ). And it's better to always transform from fresh each time, rather than accumulating transforms, because otherwise numerical rounding errors will mean that the Area will slowly (admittedly very slowly, but let's not risk it) drift away from the car's true (x,y,carAngle) location.

So you rotate the Area (rectangle) object when you create it, not just when you draw it. And you can see that everything is working because (fingers crossed!) the rotated rectangle will follow the car around the screen. (Obviously you'd disable that effect in the released version of the game.)

I'd suggest creating (and rotating) a new Area object each frame. The cost in terms of efficiency is negligible (unless your game features a very large number of cars ). And it's better to always transform from fresh each time, rather than accumulating transforms, because otherwise numerical rounding errors will mean that the Area will slowly (admittedly very slowly, but let's not risk it) drift away from the car's true (x,y,carAngle) location.

You can also use a bunch of Polygon objects for your collision. I typically know where the 4 vertices are so it's easy for me.

Even better, if your car isn't super long compared to its width, you can just use a single radius collision for everything. That is almost always what I do in games that are not meant to be physics-heavy. It's the cheapest check possible and conceptually it's easy to think about. None of this dealing with Polygons or Areas or anything. A cartoony-looking car usually would have a bounding box where the height is about 1.5 times the width, or less. That means a bounding circle with a radius of about 1.25 times the width will work great, and just making it the height also works great too (you don't usually want a car to be exactly next to another one anyway).

I can say this works from experience, because I took this exact approach for cars in a professional game.

You can also use a bunch of Polygon objects for your collision. I typically know where the 4 vertices are so it's easy for me.

Even better, if your car isn't super long compared to its width, you can just use a single radius collision for everything. That is almost always what I do in games that are not meant to be physics-heavy. It's the cheapest check possible and conceptually it's easy to think about. None of this dealing with Polygons or Areas or anything. A cartoony-looking car usually would have a bounding box where the height is about 1.5 times the width, or less. That means a bounding circle with a radius of about 1.25 times the width will work great, and just making it the height also works great too (you don't usually want a car to be exactly next to another one anyway).

I was actually thinking of using polygons for all my objects that way I can have any shape really, but it isn't really a necessity right now. I will definitely keep it in mind though!

Even better, if your car isn't super long compared to its width, you can just use a single radius collision for everything. That is almost always what I do in games that are not meant to be physics-heavy. It's the cheapest check possible and conceptually it's easy to think about. None of this dealing with Polygons or Areas or anything. A cartoony-looking car usually would have a bounding box where the height is about 1.5 times the width, or less. That means a bounding circle with a radius of about 1.25 times the width will work great, and just making it the height also works great too (you don't usually want a car to be exactly next to another one anyway).

Agreed. Generally, bounding circles or axis-aligned (unrotated) bounding boxes are the best place to start. I was probably a bit hasty jumping in with the stuff about Areas. Ah well, so long as it works.Simon

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