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.

http://forum.defence-force.org/viewtopic.php?t=563

Have fun!

thrust26

thrust26

Vertical lines (maybe nearly vertical?) are sometimes drawn wrong... as if one of the extremes was wrong.

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 know these are not good descriptions of the problems, so I will try to find some time to figure out what cases are failing more precisely.

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...

EDIT: Fixed too.

Have fun!

thrust26

thrust26

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.

Basically have an unrolled loop and a table with where to jump into the unrolled loop for the number of steps.

You shift the number of steps left (multiply by 2) to give you the offset into the table and then jump to the address pointed to by the table.

The unrolled loop could get rather large unless you have some sort of limit on the number of steps to perform at a pass.

Self modifying code would speed this up a lot. Only do the table lookup once and any math at the bottom of the unrolled loop.

Everything is calculated and modified on entry to this branch of the line routine.

*edit*

This may fall under impractical since you can't split up odd numbered steps into smaller chunks.

It should work where there are an even number of steps because you can always divide that by 2 but that only unrolls the loop a little bit so not a large improvement? But still... it's simpler than drawing from both ends like I did with my 6803 code for the MC-10 and probably a lot faster.

Horizontally would benefit from setting all bits per byte at one shot but I haven't spent time figuring out the logic.

That does not solve the divide issue btw, I'm still looking at a way to do that fast.