1) I understand a faster way to do a getpixel is to get it from a dibmap? I think I need to include a HBITMAP structure and do an api call to createdibbitmap, but how would I reference the pixels in the bitmap? Something like:

mov eax, ?

2) How would I optimize/make it go faster, for the two loops, such as below? I kind of don't want a rewrite, trying to do this stuff on my own.. maybe some pointers in the right directions.

lj2: ;loop
mov edx,eax
mov tmp,ecx
xor eax,eax

shr tmp,3 ;mulitply tmp variable by 4, for dword array
mul tmp ;multiply whatever's in eax to tmp
mov [esi+eax],edx
inc ecx ;this is the main index

inc ex
cmp ex,128
jng lj2 ;for ex=0 to 128
mov ex,0
inc fx
cmp fx,14
jng lj2 ;for fx=0 to 128

Posted on 2003-09-27 11:18:48 by drarem
1) mov eax, is not a valid opcode if ptr is memory.

2) For

xor eax,eax

shr tmp,3 ;mulitply tmp variable by 4, for dword array
mul tmp ;multiply whatever's in eax to tmp

shr tmp,3 != tmp *= 4

Also what is the point of the mul since eax will always be zero, and that means the result will always be zero.

If I was to code it, it would look something like

mov counter, 128*128
mov edx, eax
xor eax, eax ; do not know whether this is needed
push ecx
shr ecx, 2
mul ecx
mov [esi+eax], edx
pop ecx
inc ecx
dec counter
jnz loop_

The trick is to use mainyl registers and cut down on memory usage.
Posted on 2003-09-27 11:57:08 by roticv
Wouldn't it be:

shl tmp,2 = same as tmp*4 ?

when bits are shifted to the left, the number grows, right?
0001 = 1
0010 = 2
0100 = 4
1000 = 8

shr tmp,2 = same as tmp/4 ?
Posted on 2003-09-28 12:40:17 by drarem
typo... was just commenting on your code. Yea it should be shl. Was too sleepy then. :grin:
Posted on 2003-09-28 12:50:20 by roticv
No prob, I admit my code is atrocious as well as my though processes.

Ok, here is what I have... and have been burning out on too..
how would I reference a dib-sectioned bitmap?

mov eax, ; where ecx is the index and 4 is to align it to dword

what if given is an x and y value? para-coded below:

mov eax, - this way


mov eax, - this way?

below is what I have but I am getting the 'jaggies' and not an aligned picture..

:: :: :: ::
:: :: :: ::
mov eax,fx ;mov fx (y value) into eax
mov dptr,570 ;mov 570 (width of bitmap) into mem location

mul dptr ;mul eax by 570, storing in eax
shl eax,2 ;multiply by 4 for DWORD access

push ex ;push ex (x value)
pop dptr ;pop it into dptr
shl dptr,2 ;multiply by 4 for DWORD access

add eax,dptr ;add dptr to whatever is already in eax from above
; shl eax,2 ;this is commented out, tried it this way too, still got jaggies
mov dptr,eax ;mov eax total into dptr

mov eax,[edx+dptr] ;point to [edx+dptr] - works in my CopyArray but I need x/y for convenience..
:: :: :: ::
:: :: :: ::
Posted on 2003-09-28 13:47:44 by drarem
doh! I was trashing my pointer edx... it seems to be working now.

mov edx,pBitmapBits ;this was getting trashed within the loop
mov eax, ;so I need to either push/pop it or mov it into edx during usage

I have getpixels and setpixels in there could be the culprit.

thanx for your help, Roticv

UPDATE: I also just figured out, it has to be with registers for:

mov eax,

and not

mov eax,

I guess that is low-level :)
Posted on 2003-09-28 14:07:53 by drarem
consider using static table with y values, this could be faster then calcualating it all the time.
Posted on 2003-09-28 17:20:04 by AceEmbler
thnx Ace, I'll keep that in mind.. well it's all the time I have today for, so here it is:


may want to hold shift down when selecting, the older version loaded in from cache memory.

pushing 14k, the upper right button on the 'control panel' side will lighten the image, and the bottom right button (the two lines with the two red arrows between them) will blur the image..

the slider bar controls brush size

and you will notice when you blur, certain colors smear - and I'm not capping my colors correctly when lightening up the image, they tend to go on to the next color. Got an interesting side effect, after lightening it up so many times, black surrounded my mouse drawings - kind of an edge detection.

also there is a small delay after hitting blur or lighten - optimization is required.. ran it thru memproof to debug any memory leaks, appears there are none.
Posted on 2003-09-28 17:50:32 by drarem