1. If your game will be tile-based, what you can do is define 2 tiles for each tile: One is the displayed bitmap, the other holds information for your collision detection. This can be a simplified version of the displayed bitmap, for example black = road, green = grass, white = building etc. but it can also be just raw data since we don't use it to draw to the screen.So while you draw the background, you also 'draw' the tiles for collision data (but of course you won't draw them to the screen).In your game loop, you check in the collision data what the car is driving on (road, grass, building) so how the car should respond.I hope I'm making any sense here

2. I don't have experience with that, but I suspect AffineTransform will be slow. If it is, you can prerender an array of car images with different angles. Then in your game loop, simply select the correct image for the angle the car is driving in.You could also consider using openGL, where rotation etc. is hardware accellerated so you won't need to pre-render rotated images.

i did it this way for NanoMachinez (the link is placed in my signature below).i use an image that holds the resistance values for the terrain. each color represents a certain type of resistance (road, grass, ...). this can also be used for detecting if the finish line has been passed (in the correct direction).

i also use AffineTransform to rotate the car image. although this might be a bit slow it works well enough for my game.

pros: you don't have to render many car images, only one. with rendered car images you never have such smooth rotation unless you generate 360 car image or so...

cons: that the rotated image is not looking as good as the non-rotated one.

I've never had a performance problem with AffineTransform under any circumstances. As for rotation quality, here's a useful tip:

If the image gets scaled down, the rotated quality will improve. So make your image 20% larger than normal, and have the AffineTransform object scale down 20% and rotate. You'll see the quality actually improve! The reason being is that it can use real pixels from the source image for the pixels that it would normally have to interpolate in the rotation.

The concept with the tiles sound very interessting but I'm not sure if Iunderstand it completely. How would you treat tiles with different colors/undergrunds e. g. a tile that both contains part of a road and grass. Do you create sub-tiles? Or is the type of resistance depends on the most commonly used color?

It depends on how accurately you want to implement it. For a really inaccurate implementation, you could simply take the center point from the car and check the pixel of the 'collision tile' to see what the car is driving on and how it should behave. If you want some more accuracy, you could check 4 points to see what each wheel of the car is driving on and update the car's behaviour accordingly.

extending on that idea, I'd like to clarify another idea you could use. You could say that if a tile is road, there's a slowdown factor of 1. If a tile is grass, there's a slowdown factor of .9 (you could multiply these to the momentum for a reduction in speed). Then if a tile is grass and road in the same tile, the slowdown factor is .95, halfway inbetween the two. I think that would work well. Just have the slowdown factor associated with each tile type for easy reference.

Mind you, the colours of the pixels in this "collision tile" don't have to be actual colours, it can also be slowdown values like Mahlokan described.I'd do it per pixel and not per tile though, for the same reason you mentioned (loss of accuracy) but it will probably depend of the style of racing game you're making.

bauerr, 10x10 is not a power of 2. 16x16 is and 32x32 is. 16x32 is also 2^n x 2^m is what you want. It's not necessary that your tiles be of that size, but if you have plans to take advantage of OpenGL acceleration, you'd do best to build them that way. Another OpenGL acceleration helpful trick would be to put them all in a single image and just draw sub-sections of them in drawImage

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