Did you look in the public path?JamesD wrote:Well, I'm getting 664 so I think the latest code isn't in the repository.
http://forum.defence-force.org/viewtopic.php?t=563
Did you look in the public path?JamesD wrote:Well, I'm getting 664 so I think the latest code isn't in the repository.
EDIT: Fixed. Try latest version, please.Chema wrote:Updated to the latest version as of feb,14th ;451 refactored to make x-direction always positive (37.07)) and found some issues...
Vertical lines (maybe nearly vertical?) are sometimes drawn wrong... as if one of the extremes was wrong.
Sorry. But shit happens when you are trying hard to optimize.Not sure what changed in the clipping code, but when used in 1337 it hangs in an infinite loop when I try to launch...
I finally figured out a way to do this due to how I planned to redo my color cycling routine on the Amiga. Not sure why I didn't think of it before.JamesD wrote:Ok, so someone else can mull over the math concept and possibly come up with a solution...
Here is the simple part of the math:
X1 - X2 = DX
Y1 - Y2 = DY
If DX > DY THEN
DX / DY = number of steps in Y per step in X
ELSE
DY / DX = number of steps in X per step in Y
However... that isn't an even number often so you have DIV and MOD results, plus a divide is slow.
So, somehow the steps must be adjusted for each inner loop based on the MOD. Perhaps the steps + a table lookup based on the MOD before each inner loop.
Then the inner loop just uses a counter based on that in the Y direction or sets that number of bits in the X direction. Or something along those lines.