R0ger

I made small demo, but it only draws 2 lines, each 50 pixel long. Good for profiling cycles per pixel. If hope making random lines would be no problem for you. It is here: http://roger.questions.cz/atari/line.zip Main file is main.asm, rest is included. It is structure of my bigger project, I only removed unnecessary code. So it does for example turn ROM off. I can't turn it on quickly, as I'm not experienced all too well in those shadow registers, I hope you can make it faster if you need it. So far I tried 2 modifications. First using table for masks and byte offsets for each X, as in erudraw. That actually didn't help. Reason is this. When I move down, I do not increment pointer in zero page. I first add 40 to Y. Only when that overflows, I go to zero page. This was I'm saving few cycles, but I can't use Y with the table. So the table approach is marginally faster for flat angles (less then 45 degrees), it is 10% slower on steep angles. Together it is few % slower. The I tried drawing symetrically from both ends. For this it's clear I need 2 pointers, two masks .. so there is no way I could do that in registers. So the table approach is actually better for this ! And it actually seems to be faster ! For flat angles the speed increase is the largest - about 10%. For steep it's only marginal. But that gives me like 5% together. The codes is a bit longer, and I will have to correctly solve the last middle pixel (which I don't do at the moment). But it seems to be an improvement. It will take me some time to make it complete. As for the C64 code I've seen .. they use some crazy techniques with precomputed blocks of bytes. It seems to be lot faster .. but they only talk about 8 bits per pixel, where the balance can be rather different. Still I don't understand it all fully yet, so I'm not saying it's not usable.

Wow, thanks for reactions. Didn't expect so many so fast ! Some of the suggestions are actually already part of my routine. Some are irelevant, cause I'm not interested in supporting all modes at the moment. I only need this one mode. As for Eru's routine .. now we're talking. It is the mode my routine also works with, 4 pixels per byte. He uses quite simmilar approach to mine, except his uses something slightly different then Bresenham. He compares deltas in every step. It doesn't even seem to work in all cases, but the decision making seems to be quite simmilar in the end. My routine at the moment is actually faster then Eru's. I have 64 cycles per pixel, his has around 80. Still mine does not replace the color as his does, it uses OR to background, which is faster and it is sufficient for me at the moment, so in the end they would be quite simmilar in speed. Eru has few great ideads there though. I especially like his use of array with masks for whole line. That is really simple and smart, and not so memory intense. I could addapt that to my routine immediately. Also I'm thinking about that drawing from both ends at the same time .. but that would take some more time. Also 20% was overly optimistic (as always). After some thinking I guess it will be on borderline of usefullnes. But as I said, I will taky any cycle I can get. Before that I have to read through those C64 archives. I already use some of their code, like multiplication, or signed comparison. I just haven't found line routines there till now.

Well draving the point inside is of course part of my routine. The putpixel routine on the start is only used for special case where input coordinates are the same. The angle is quite important actually. With angle bellow 45 degrees you always go right, and sometimes also up. With lines above 45 degrees you always go up, and sometimes also right. This distincion simplifies the inner loops considerably. The idea with drawing from both ends at the same time sounds good though ! I would have to mask to zero page, but halving the time of decission making could bring like 20% speed boost ! As for the thread .. I failed do find it. Could someone post a link ?

Hello Atari fans ! I'm looking for some fast line algorithms. I'm using graphics mode with 4 pixels per byte, so 1 pixel is 2 bits, and all coordinates will fit into byte. After some googling I found either very basic algorithms, or something not suited to this graphics mode, or not suited for 8bit atari at all. I mean I already made some routines. And I think they are not bad. On average my routines cost 64 cycles per pixel of the line. But are they the best possible ? Did someone for example tried to disassemble some famous vector games, like Mercenary ? My routine is available here: http://roger.questions.cz/atari/line.asm It is Bresenham, with 4 variants. 2 for up and 2 for down. 2 for beyond 45 degrees and under 45 degrees. I always draw left to right, and swap coordinates when needed. I keep byte offset from starting address in Y, and index of pixel mask in X. The code is not commented very extensively, but it should be clear enough for anybody alredy doing Bresenham in their live. Please be gentle with me, this is my first 6502 project and I'm still not quite efficient in all intstruction times and such. I am interested in even slightest optimalizations though, especially in the exposed inner loops ! But some principal idea would be even better. I could quickly make some small project which would demonstrate the routine, if someone feels like debugging through it.