A modified Mikl__-AVCaballero-Bresenham line

[HSE]

Finally is working a modification for 32bit BITMAPs!

Code Select Expand

_swap macro a , b
push a
push b
pop a
pop b
endm

horizontal proc X1:dword,Y1:dword,X2:dword, ScreenWidth:dword, color:dword

mov eax, X1
cmp eax, X2
jbe @f
_swap X1, X2

@@:
xor edx , edx
mov eax , Y1
mov ecx , ScreenWidth
mul ecx
mov edx , X1
shl edx , 2
add eax , edx
mov edx , eax ; edx = Y1 * ScreenWidth + X1
xor ecx , ecx
@@:
mov eax, X2
sub eax, X1
cmp ecx, eax
ja @f
mov eax , color
mov esi, edi
push ecx
shl ecx , 2
add esi, ecx
pop ecx
add esi , edx
mov [esi], eax
inc ecx
jmp @b
@@: ret
horizontal endp

vertical proc X1:dword,Y1:dword,Y2:dword, ScreenWidth:dword, color:dword

mov eax, Y1
cmp eax, Y2
jbe @f

_swap Y1, Y2
@@:
xor edx, edx
mov eax, Y1
mov ecx, ScreenWidth
mul ecx
mov ecx , X1
shl ecx, 2
add eax, ecx
mov edx, eax ;edx = Y1 * ScreenWidth + X1
xor ecx, ecx
@@:
mov eax, Y2
sub eax, Y1
cmp ecx, eax
ja @f
mov eax , color
mov esi, edi
add esi , edx
mov [esi], eax

add edx, ScreenWidth
inc ecx
jmp @b
@@: ret
vertical endp


BresLine proc uses esi edi X1:dword,Y1:dword,X2:dword,Y2:dword, color:dword
local var_4:dword
local var_8:dword
local var_C:dword
local var_10:dword
local var_14:dword
local var_18:dword
;-----------------
local ScreenWidth : dword
local buffer1:dword

; Convert RGB to BGR format (Siemanski)
mov eax, color
bswap eax
ror eax, 8
mov color,  eax


mov ecx , [esi].grafico.right ; Screen Width in pixels
shl ecx, 2
mov ScreenWidth , ecx ; now is width in bytes
mov edi , [esi].grafico.array3D ; Buffer containing data bits

mov eax, Y1
cmp eax, Y2
jnz @f

push color
push ScreenWidth
push X2
push Y1
push X1
call horizontal
jmp fin

@@: mov eax, X1
cmp eax, X2
jnz @f
push color
push ScreenWidth
push Y2
push Y1
push X1
call vertical
jmp fin

@@: mov eax, X2
sub eax, X1
mov var_4, eax
cmp eax, 0
jge @f
neg var_4

@@: mov eax, Y2
sub eax, Y1
mov var_8, eax
cmp eax, 0
jge @f
neg var_8

@@: mov eax, X1
cmp eax, X2
jge @f
mov var_C, 1
jmp loc_401601


@@: or var_C, -1

loc_401601:
mov eax, Y1
cmp eax, Y2
jge @f
mov var_10, 1
jmp loc_401624


@@: or var_10, -1

loc_401624:
mov eax, var_4
sub eax, var_8
mov var_14, eax

loc_40162F:
mov eax, Y1
xor edx, edx
mov ecx , ScreenWidth
mul ecx
mov ecx , X1
shl ecx, 2
add eax, ecx      ; eax = Y1 * ScreenWidth + X1

mov esi, edi
add esi, eax
m2m [esi], color
mov eax, X1
cmp eax, X2
jnz @f
mov eax, Y1
cmp eax, Y2
jz fin

@@: mov eax, var_14
shl eax, 1
mov var_18, eax
mov eax, 0
sub eax, var_8
cmp var_18, eax
jle @f
mov eax, var_14
sub eax, var_8
mov var_14, eax
mov eax, X1
add eax, var_C
mov X1, eax

@@: mov eax, X1
cmp eax, X2
jnz @f
mov eax, Y1
cmp eax, Y2
jnz @f
xor edx, edx
mov eax, Y1
mov ecx , ScreenWidth
mul ecx
mov ecx , X1
shl ecx , 2
add eax, ecx ; eax = Y1 * ScreenWidth + X1

mov esi , edi
add esi , eax
m2m [esi], color
jmp fin

@@: mov eax, var_18
cmp eax, var_4
jge loc_40162F
mov eax, var_14
add eax, var_4
mov var_14, eax
mov eax, Y1
add eax, var_10
mov Y1, eax
jmp loc_40162F
fin:
ret
BresLine endp


I still don't know why Get/SetDIBits manage BGR instead of RGB colors  8)

Regards. HSE.

Later: Convert RGB to BGR format (Siemanski)

[aw27]

What this IDA disassembly is all about?   ::)

[hutch--]

> I still don't know why Get/SetDIBits manage BGR instead of RGB colors

I think you will find that it is due to the way x86/x64 hardware stores numbers. Text goes left to right, numbers are stored right to left byte order.

[aw27]

> I still don't know why Get/SetDIBits manage BGR instead of RGB colors

I also don't know why British people use pounds when everybody and their dog use Kg. 

[Siekmanski]

Just wondering, is the routine for vector graphics line drawing?

Some suggestions to speed the routine up,
Reverse (bswap) the ARGB/XRGB color order once and use it for each other line and keep it outside the line drawing routine.
You could improve the speed by using fixed point arithmetic and get rid of the muls.
Create a reciprocal look-up table for the X steps, ( 1 mul to calculate the slope of the whole line )
Now you have only 2 additions left to calculate all the screen X,Y positions for your line pixels.
This way you could also use SIMD instructions and create a slope position process for 4 or 8 pixels at once.

[avcaballero]

Is there enough interest in reattach my tutorial on aowg graphics? Some time ago I had it attached on my site, received visits, but no feed-back, much less recognition. We have all learned it all by ourselves, have not we?

> What this IDA disassembly is all about?   ::)
There are times when you do not want to teach the code of your program for multiple factors and it is quite ugly that someone decompile it and show it to you.

Anyway, aowg needs some fixes, like in creating the palette for plasmas, and also gave some false positives especially in some tinyc codes. But even so, if there is interest, I could reattach it up again. Waiting to have time to correct and expand it.

[HSE]

What this IDA disassembly is all about?   ::)

I think that (but the code is stored in the forum)

... the way x86/x64 hardware stores numbers.

That was the first idea, but numbers are ABGR (instead of ARGB) and the A (null) part is in place. Later I discover in MSDN that ABGR is a BitMap valid format.

>I also don't know why British people use pounds when everybody and their dog use Kg. 

Yes, perhaps british dogs also use Kg. The confusing thing (for me of course) is that flag in use is DIB_RGB_COLORS, clearlly refering to origin format (and one think is stored in same way  )

Some suggestions to speed the routine up,

:t :t   :redface: :t

Anyway, aowg needs some fixes,..

Yes, we know that problems. There is a lot in your site, but for now is enough for me to draw a simple line  At some point perhaps could be interesting the Wu's line (and crossing Wu's lines  ). BTW Masm examples requiere includes and libraries that I don't find, but I'm sure you are working in that things. :t