Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: LincolnB on February 20, 2012, 12:35:35 pm
-
So I decided to make my very own (extremely hard to see) disco-caster for my Flashlight Demo thread. It was actually really easy, from what I already in the the flashlight demo.
(http://img.removedfromgame.com/imgs/discocaster.gif)
(in retrospect I went a little crazy on the psychedelic wall effects)
-
Waoufh :crazy:
In what langage did you do that ?
-
Axe :D
-
Axe? Hmm..
A lot of your work is done in ion, right?
-
Ion? What do you mean?
-
Waaaah O.O
That's a bad thing that nobody already made a tuto on raycasting (3D is the ultime goal of an on-calc programmer XD )
-
hehe you know there are two other raycasters right?\
Runer's:
http://ourl.ca/8272
and Squidgetx's:
http://ourl.ca/8144
-
yeah, but that's compressed programs, with ununderstable code (what, I'm a newbie ?)
-
Compressed programs? Neither of the three have any sort of compression going on (that I know of), it's just regular Axe.
-
Yeah, but I meant without any explication of how it work (bad English powaaa)
-
Lol, that looks like it has some of the same display glitches that mine had...sigh, i never did figure out how to get mine to work properly :P
-
I assume you're refferring to the "fishbowl" type effect, with non-linearly sloped walls and whatnot?
-
Looks quite nice actually. I was surprised at the speed too. :)
-
I assume you're refferring to the "fishbowl" type effect, with non-linearly sloped walls and whatnot?
Yeah. I know the theory behind how to deal with it but iirc whenever I tried to implement it it never worked...I should work on that again sometime
-
I believe to fix the fishbowl effect you just need to multiply the ray distance by the Cos() of the angle between your front view and the angle of the ray. Obviously this would be a bit tricky in Axe since Cos() returns a number from -127 to 128 so you would need to make sure you handled that properly, or got a hold of a trig routine that returns x256 format, or better yet, make a 96 byte table for the 96 possible cos values.
-
Yeah, if you have a 96 byte table stored in 0.8 fixed point, you could just do Dist**{X+Table}.
-
By the way, Axe internally calculates sine by the following pseudo code:
Mod the argument X by 256 (Sine is cyclic)
If X < 128 return X*(128-X)/32 (An approximation of a sine hump)
If X > 128 return (256-X)*(128-X)/32 (An approximation of a negative sine hump)
Cosine is just sin(X+64) of course. Each of these use only a single multiplication so it's going to be fairly fast. If you want the result to be in the full range [-32768 to 32767] instead of [-128 to 127] multiply by 8 instead of dividing by 32 in your custom routine. Or for 8.8 format, just divide by 16 instead.
-
Why didn't you divide by 16 in the first place? 8.8 format seems a lot more useful than the current range of the trig functions.
-
yeah, but that's compressed programs, with ununderstable code (what, I'm a newbie ?)
Compressed programs? Neither of the three have any sort of compression going on (that I know of), it's just regular Axe.
Yeah, but I meant without any explication of how it work (bad English powaaa)
The term you're looking for is "optimized," not "compressed." Compression is where a set of data is encoded in such a way that the resulting data is smaller in size than the original data. Optimization is when a program is modified so it runs faster or uses less memory, or otherwise becomes more efficient than before.
-
@Quigibo: Wow, that is nice O.O
-
I believe to fix the fishbowl effect you just need to multiply the ray distance by the Cos() of the angle between your front view and the angle of the ray.
What does this mean???
-
Let's say you cast a ray. Your player will already be facing a certain angle, and the ray will be cast at an angle that is at an offset to the angle the player is facing. You take the cosine of the difference between the ray's angle and the player's angle, and then you multiply that by the ray's distance. This new value is the new ray distance.
-
Why didn't you divide by 16 in the first place? 8.8 format seems a lot more useful than the current range of the trig functions.
I wish I had. I added the sin/cos routines before I introduced 8.8 operations and so at the time, I chose the range because it would be convenient to be able to store the result into a single byte in memory. Its too late to make a change like that now unfortunately, but when it comes down to it, it only costs 1 byte to convert it in Axe and the resolution you lose is small since the routine is an approximation anyway.
Also, the pseudo code is not literal to how Axe does the operation. Its far more optimized without multiplication or division, but rather a single routine that does everything together bit by bit.
-
OK Builder, I think I get it.
Is it possible to take the inverse cosine of an 8.8 number in Axe? If not, I'd like to request that feature.
-
Not that I know of, but you should probably check the commands list, that will tell you anything you need to know. What do you need inverse cosine for?
-
More 3D related stuff - I'm trying to set up some code that detects whether or not a given object on the unit circle (centered at your character, radius=distance between you and object) is in your FOV.
-
Hmm there is probably a way to do that with dot products to avoid a large amount of trig, but couldn't you just use inverse tangent?
-
Explain how to do stuff with dot products? (I've never even heard of them)
-
If you have two vectors A and B, the dot product returns this computation:
Dot(A,B) = Mag(A)*Mag(B)*Cos(Angle between A and B).
Not only is this an interesting and potentially useful value, the dot product can also be calculated using simple multiplication and addition:
Dot(A,B) = Ax*Bx + Ay*By
Roughly speaking, the dot product returns how much the vectors point in the same direction. If the vectors point in the exact same direction, the result will be positive. If the vectors are at right angles to each other, the dot product will return zero. And if the vectors are pointing in opposite directions, the dot product will return a negative number.