bitsplit wrote:
What are the ranges for b and c in your calculation?
They are coordinates within the level map, so they are both 16-bit values, anything from 0 to 65535.
However, since there are few angles (168 for the whole circle), I can probably get rid of a number of lower bits in order to make the calculations faster and the final result would most likely be the same, or pretty close. There are 512 units inside each block, but I already reduce that to 128 in some points to make it faster, and it's hardly noticeable.
Quote:
Also, ask yourself if you really need to calculate the distance.
That is needed to know how large a sprite should be drawn (distant = small; close = big). I can't think of any other way to calculate the exact size without knowing how far it is from the player.
Quote:
As to the angle, what are you using it for?
I use it to know where to place the sprite on the screen horizontally. Rays are cast from the player from left to right and for each one the angle is incremented. I need to know the angle of an object/enemy and find where the matching angle was rendered to on the screen (if at all) in order to know where to place the center of the sprite.
Quote:
A lot of times, it is better to use a dot product in that case.
I don't really know what a dot product is, but if it can help me I'd sure like to learn about it! =)
Quote:
There might be alternatives to what you want to do, even if there are none to the calculation of h and a.
I know. For the walls I considered many different kinds of calculations that would result in the final values I needed, instead of sticking to a set of pre-defined formulas from the start. The exact solution I found can't be seen in any existing games or tutorial on the internet.
For the objects however, I couldn't think of anything better/faster than what I presented here. Currently, my best be is to reduce the precision of that division.
tepples wrote:
But a quicker and more physically correct way to determine distance to a wall is to dot-product the ray from the camera to the wall with the "forward" ray; this method has the "cosine correction" built in as well.
You kind lost me because of the dot product, but I'm fairly sure that the more correct way would be too slow for the NES. I move my rays across the grid a step at a time, and it's working pretty well. I have a resolution of 28 columns (much less than 320!), meaning that I have only 14 relative angles for which the "cosine correction" is necessary (the right side is a mirror of the left side), So I actually pre-corrected all the distances in my distance table for the 14 possible angles, so I don't need to do anything to get rid of fish eye distortion either.
I'm not really worried about objects/enemies right now, I'm just happy because I got the walls working on the NES and it's not dead slow, it's actually pretty playable. So I'll spend some time polishing that part up before I try to place any objects in. I still welcome suggestions of course, so if anyone has any I'd be glad to hear about them.
PS: I'll soon make a thread to display my achievements with this, and I'll let everyone play the demo by themselves once it's a bit less messy.