This site requires JavaScript, please enable it in your browser!
Greenfoot back

nccb's Comments

Back to nccb's profile

Shooting Rocks was about the intersection of a line and a circle, whereas this is about the intersection of two circles (which is actually easier).
zapnine7: I've now published the explanation of how to do image rotation, you can find it here:
It's very similar to this post: That post looks at rotating the position of the wheel to work out where to place the tyre tracks. But instead of rotating a wheel position, you rotate the position of every pixel in the image. As I said, I will write the full post for you soon :)
The gist of rotating an image is that if you want a 30 degree clockwise rotation, then for each position in the new image, you rotate the position by 30 degrees anti-clockwise and, use the pixel from the old image that is at that position. I can add the idea to my list, but I have a bit of a pipeline going, so it will be a while before it shows up :)
The answer to Builderboy2005 and MatheMagician is the same: I used Wu (which gives thick lines) rather than Bresenham because the same algorithm can be used to do things like shooting: and visibility calculation: the latter of which is used again in the raycasting 3D example: Bresenham is not very suitable for these other purposes because it would let the shot/visibility pass through walls -- not so good!
You're right that you can calulcate the angle from the two points. But how would you draw the line from the angle and two points? There are ways to do it, but they tend to either be potentially imprecise (will miss pixels in some circumstances) or slow. If you think you know a way, try implementing it to see if it works.
@Builderboy2005: Yes -- that's true. Did you know that the original Wolf3D raycasting engine actually pre-compiled all the line-scaling routines that it needed, for speed? At least, wikipedia claims: "The secret behind engine's performance is vertical scanline scaling algorithm. Unlike later engines and hardware rasterizers, the texture coordinate for the pixel is not calculated at runtime. Instead, a fixed set of several hundred rendering functions is generated during game startup (or viewport size change) where all memory offsets are fixed. To keep the number of these procedures small, height is quantized, which can be easily seen when player is close to the wall, but not looking at it at a right angle."
That would be fine -- go for it!
Details on how to implement the line-of-sight mechanism is here (building on previous posts):