How can I draw a line in assembly language without using decimal numbers?

[alan_longor]

i have a frame-buffer , and i want to draw a line using assembly language . i cannot work with decimal numbers . what's the best and most efficient method ?

thank you .

 

[berkeman]

i have a frame-buffer , and i want to draw a line using assembly language . i cannot work with decimal numbers . what's the best and most efficient method ?

thank you .

Sorry, but I'm not tracking your question. What kind of "frame buffer"? What are you running your assembly language program on? What IO do you have? Where and how are you drawing a line? Physically on paper? On an LCD display? What kind of display?

Much more information and maybe some pictures or links would make it much easier to answer this for you...

 

[alan_longor]

Sorry, but I'm not tracking your question. What kind of "frame buffer"? What are you running your assembly language program on? What IO do you have? Where and how are you drawing a line? Physically on paper? On an LCD display? What kind of display?

Much more information and maybe some pictures or links would make it much easier to answer this for you...

thank you for your attention Berkeman , i am using AVR assembly , and i am attempting to write this line on a TV screen , the frame buffer is 320x200px in size . it's monochrome so one bit represents a pixel . the protocol is PAL . and i am using an Atmega1284p .
i managed to get the protocol running and getting the image on the screen using interrupts . now i want to draw lines . storing things in memory and all is not a problem . since i can address any pixel on the screen easily , the problem now is in the method i will be using to draw the line . i want the most efficient way possible . the usual way "y= ax+b" is not efficient at all .

thank you .

 

[berkeman]

thank you for your attention Berkeman , i am using AVR assembly , and i am attempting to write this line on a TV screen , the frame buffer is 320x200px in size . it's monochrome so one bit represents a pixel . the protocol is PAL . and i am using an Atmega1284p .
i managed to get the protocol running and getting the image on the screen using interrupts . now i want to draw lines . storing things in memory and all is not a problem . since i can address any pixel on the screen easily , the problem now is in the method i will be using to draw the line . i want the most efficient way possible . the usual way "y= ax+b" is not efficient at all .

thank you .

What is the format of the frame buffer? Can you post a link to it? How do you change the value of each pixel from OFF to ON? Or is there a grey scale number associated with each pixel? Is upper left on the display (0,0)?

What will the inputs to your program be? End points of the line? An equation like the one you mention? How often will the line image change? Will you be trying to move the line around on the display in real time?

 

[alan_longor]

What is the format of the frame buffer? Can you post a link to it? How do you change the value of each pixel from OFF to ON? Or is there a grey scale number associated with each pixel? Is upper left on the display (0,0)?

What will the inputs to your program be? End points of the line? An equation like the one you mention? How often will the line image change? Will you be trying to move the line around on the display in real time?

the frame buffer takes 8000bytes of SRAM . every byte represents 8 pixels . every row is 40 bytes in size . i am using the SPI peripheral for this , since it can do automatic shifting quite fast . so i supply the byte to the SPI registers then set the transmission , this will get the needed data on the DATA OUTPUT pin of the SPI which will be fed to a register ladder . a 0 bit is black and 1 bit is white . at this point , the program only draws the line , that's it . then the interrupts will just continue supplying the correct signal in time using the set frame buffer . this is just a test program .
my problem is not technical , i need a good algorithm to draw the line .

thank you .

 

[berkeman]

the frame buffer takes 8000bytes of SRAM . every byte represents 8 pixels . every row is 40 bytes in size . i am using the SPI peripheral for this , since it can do automatic shifting quite fast . so i supply the byte to the SPI registers then set the transmission , this will get the needed data on the DATA OUTPUT pin of the SPI which will be fed to a register ladder . a 0 bit is black and 1 bit is white . at this point , the program only draws the line , that's it . then the interrupts will just continue supplying the correct signal in time using the set frame buffer . this is just a test program .
my problem is not technical , i need a good algorithm to draw the line .

thank you .

That info helps a lot. But once you write the image into the frame buffer, you don't have to keep re-writing it, do you? Just when you want to draw a new line, right? And again, what will be the input to your program to tell you what line to calculate? Just the two endpoints?

 

[alan_longor]

That info helps a lot. But once you write the image into the frame buffer, you don't have to keep re-writing it, do you? Just when you want to draw a new line, right? And again, what will be the input to your program to tell you what line to calculate? Just the two endpoints?

you only write the info once , you write it in the frame buffer . then the ISR code will continuously display the frames in time .
basically when interrupts are triggered after the sync of every horizontal line the code fetches row data from the correct addresses in the frame buffer at the end of the line there will be some extra time left that's when the ISR stops and the execution goes back to the main code .
exactly , the function get's the two points (x0,y0) (x1,y1) . normally i should find a = (y1 - y0) /(x1-x0) then b = y0 - a(x0) , then loop over this y=ax+b . but that involves decimal number handling and continuous division and multiplication which would be too slow and ineffective .

thank you .

 

[Tom.G]

https://www.google.com/?gws_rd=ssl#q=bresenham's+line+algorithm
The basic idea is calculate the nearest pixel center to the "ideal" location and any fractional over/under flow is maintained in an additional byte for the next calculation. Essentially fixed point math with the fractional part used only for the next calculation.

Also, when you need to erase the line, or part of it, you need to run the same algorithm with the same start and end points; otherwise you will miss a few pixels.