Page 5 of 5
Posted: Tue Feb 09, 2010 4:56 pm
JamesD wrote:Well, I'm getting 664 so I think the latest code isn't in the repository.
Did you look in the public path?

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

Posted: Tue Feb 09, 2010 5:21 pm
Ok, I missed the repository change. That looks much better and more like what I expected.

Posted: Tue Feb 09, 2010 8:57 pm
I need to find a way to make the deleted and moved stuff to not appear in the depot anymore.

That's disturbing

Posted: Sun Feb 14, 2010 6:03 pm
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.

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.

Posted: Sun Feb 14, 2010 6:10 pm
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.
Not sure what changed in the clipping code, but when used in 1337 it hangs in an infinite loop when I try to launch...
Sorry. But shit happens when you are trying hard to optimize.

EDIT: Fixed too.

### Re:

Posted: Thu Jan 23, 2014 12:45 pm
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.
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.

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.

### Re: Line routine - Second attempt

Posted: Sat Jan 25, 2014 12:53 am
That does not solve the divide issue btw, I'm still looking at a way to do that fast.