Line routine - Second attempt

Here you can ask questions or provide insights about how to use efficiently 6502 assembly code on the Oric.
User avatar
thrust26
Officer Cadet
Posts: 49
Joined: Wed Jan 27, 2010 7:34 pm
Location: Düsseldorf, Germany

Post by thrust26 » 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
Have fun!
thrust26

JamesD
Flight Lieutenant
Posts: 352
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD » Tue Feb 09, 2010 5:21 pm

Ok, I missed the repository change. That looks much better and more like what I expected.

User avatar
Dbug
Site Admin
Posts: 2304
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » 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 :(

User avatar
Chema
Game master
Posts: 1941
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema » 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.

User avatar
thrust26
Officer Cadet
Posts: 49
Joined: Wed Jan 27, 2010 7:34 pm
Location: Düsseldorf, Germany

Post by thrust26 » 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.
EDIT: Fixed. Try latest version, please.
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.
Have fun!
thrust26

JamesD
Flight Lieutenant
Posts: 352
Joined: Tue Nov 07, 2006 7:38 am

Re:

Post by JamesD » 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.

JamesD
Flight Lieutenant
Posts: 352
Joined: Tue Nov 07, 2006 7:38 am

Re: Line routine - Second attempt

Post by JamesD » 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.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests