News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Line Drawing

Started by tda0626, May 19, 2024, 06:22:25 AM

Previous topic - Next topic

sudoku

Quote from: tda0626 on May 28, 2024, 08:51:21 PMAlso, what is
@f in the code? I have never seen that.

it means jump forward to the next (anonymous) label.
@@:  is an anonymous label --- Its kind of a shortcut. if you ever need a quick label and cant come up with a good name.

you can jump forward to it " jxx @f" or jump backward to it "jxx @b" with any of the jxxx jumps
The @f and @b can be either case, upper or lower. short example of usage:
jnz @f
some code here
@@: <---- anonymous label
some other code
jmp @b

Mistakes can happen if used multiple times, without taking care where the next anonymous label is located - resulting in jumping to wrong anonymous label, or worse getting stuck in endless loop. Best to use named labels if that happens to you too often.  (from experience
 :tongue:  )
:azn:

_japheth

Quote from: tda0626 on May 28, 2024, 08:51:21 PMWould you mind going into more detail why PCorrect is wrong? I got the PCorrect calculation from the Bresenham Line Algo page:

Ok, I cannot comment the "Bresenham Line Algo page" - what I coded is about 28 years old, but IMO it's pretty straitforward:

For a flat line ( dx > dy ), the "PCorrect" is initialized with "-dx". Then a loop is entered, where
- x is incremented
- dy is added to PCorrect
- if PCorrect "overflows" ( meaning the total of dy's exceeds dx ), y is incremented/decremented and dx is subtracted from PCorrect.

That seems intuitively correct to me and - as an aside - it works.
Dummheit, gepaart mit Dreistigkeit - eine furchtbare Macht.

tda0626

@Sudoku Thanks for explanation.

@_japheth I will have to study your code when I get a chance. Thanks for offering it!


I found what was wrong with my code. I knew it was something to do with the PlotLineLow routine and the PCorrect calculation because that would be the routine it would be using. The negative deltay was not playing nicely with my PCorrect calculation so I added an ABS(deltay) in the code with the conditional statements when determining which branch it should take depending on the value of PCorrect. Now it seems to be drawing correctly from right-top to bottom-left and vice versa, see picture attached to this thread.


Tim



NoCforMe

Quote from: tda0626 on May 28, 2024, 08:51:21 PMAlso, what is
@f in the code? I have never seen that.
Easy one, I can answer that:
@@: creates an "anonymous" jump target label so you don't have to scratch your head to come up with a name.
@F (or @f, doesn't matter) used with a jump instruction jumps forward to the next @@: label. @B jumps back to the next previous label:
    CMP  AX, -1
    JE  @F
    . . .
@@: NEG  AX
    . . .
    CMP  AX, -1
    JE  @B

BTW, I second what sudoku said above. Anonymous jump labels are really useful but can easily get you into trouble. My general rule is to only use them when the jump instruction and the target are within just a few lines of each other. Otherwise use a named target.
Assembly language programming should be fun. That's why I do it.

NoCforMe

Quote from: tda0626 on May 29, 2024, 08:15:26 AMNow it seems to be drawing correctly from right-top to bottom-left and vice versa, see picture attached to this thread.

Now all you need is some anti-aliasing code ...
Assembly language programming should be fun. That's why I do it.

tda0626

Quote from: NoCforMe on May 29, 2024, 09:23:41 AM
Quote from: tda0626 on May 29, 2024, 08:15:26 AMNow it seems to be drawing correctly from right-top to bottom-left and vice versa, see picture attached to this thread.

Now all you need is some anti-aliasing code ...

Surely you jest  :cool: . I don't even know where to start with that.  :joking: 

It draws vertical and horizontal lines as is so I didn't have to do a separate routine for those. However, I found another problem. For deltay > deltax, it will draw them from top to bottom fine but not the other way around. It should swap the values if the deltay is negative but for some reason that is not happening so there is something up in my PlotLineHigh routine or so I suspect.

tda0626

This is odd. I was having trouble with one case in my line drawing program that didn't make sense to me. If the deltay > deltax (steep slope) but the deltax was negative, it would not draw the line correctly. Right before the conditional code to determine which line to draw and to either swap the x and y values, I had NoCforMe's ABS() code that I used to convert the negative to a positive.

mov ax, deltax
cwd
xor ax, dx
sub ax, dx

Fired up DOS debug and got to that part of code that does that ABS() routine but it does not sign extend to DX after the CWD instruction. Anyone know why? As far as I know, that instruction is supported on 386 and higher. The DX register contents are zero after the instruction is executed.

In the meantime, I just used this bit of code to convert it and now it works but still curious to why CWD isn't working because that is a pretty good method if you ask me to get the ABS().

mov ax, deltax
.if ax  & 08000h
neg ax
.endif

Tim

NoCforMe

CWD was supported way back from the beginning, on the 8086.

What was the value of AX before CWD? Are you sure it was negative?
Assembly language programming should be fun. That's why I do it.

tda0626

Quote from: NoCforMe on May 30, 2024, 09:41:44 AMCWD was supported way back from the beginning, on the 8086.

What was the value of AX before CWD? Are you sure it was negative?

Wish I took a screen shot of it. I can't remember unfortunately but my conditional statement code fixed it. I will add your bit of code back in there and test for that condition again but this time I will take screenshots of it and let you know.

Made a loop to test for all cases and it appears to draw everything correctly now, see picture.



NoCforMe

Assembly language programming should be fun. That's why I do it.