also the Alpha part is unusable , cuz i didn't find a good way(any suggestion?) to let the user input a transparency value , so i initial the transparency value as 76.
edit: revision to achieve flicker-free and a test bitmap and a test bitmap
(http://images.cjb.net/465f3.bmp)
http://images.cjb.net/465f3.bmp
quite often, they will use the color value of the pixel in the upper left corner of the image to identify the transparent color
you can use GetPixel to discover it's value, then use it with GdiTransparentBlt or to create a mask
what i do is [Image'Color*x%+Background'Color*(100-x)%] to imitate the transparent ,
the target is the whole image,
and dave, what's your circumstance?
Quoteand dave, what's your circumstance?
what do you mean ?
He is not available if that is what you mean :-) He is married.
lol
yah - semi-retired Electronics Engineer
married with a daughter
i have written software professionally in certain specialized cases - back in the DOS days and before
it's mainly a hobby
oh my god!!!! what are you thinking about?
i just want to know in which situation will
the color value of the pixel in the upper left corner of the image to identify the transparent color
be functional , your 'transparent' is not the same with mine
so tell me which kind of picture can apply the method dave offers work?
in this image...
(http://img854.imageshack.us/img854/3561/file2000.png)
the purple area can be made transparent to create icons
here is some example code...
http://www.masm32.com/board/index.php?topic=18800.0
there is one post in that thread where i use TransparentBlt
GdiTransparentBlt might be a better choice
and another where i create a mask to achieve the same thing
yah, maybe i used the wrong word to
drive you mad , lol
Quote from: dedndave on May 21, 2012, 12:25:36 AM
the purple area can be made transparent to create icons
here is some example code...
http://www.masm32.com/board/index.php?topic=18800.0
there is one post in that thread where i use TransparentBlt
GdiTransparentBlt might be a better choice
and another where i create a mask to achieve the same thing
finish your example, the purple is replaced by the background color while the main image doesn't
change to let it look merged into the background, just cool !
but my code is to do what the Alpha channal does, make the image entirely looked transparent
yes - google for "opacity"
Google says: (http://en.wikipedia.org/wiki/Alpha_compositing)
outRGB = srcRGBsrcA + dstRGB(1-srcA)
The value of alpha in the color code ranges from 0.0 to 1.0
the same as mine
[Image'Color*x%+Background'Color*(100-x)%] x = alpha value
besides , any optimizition to my code
"optimization" - there is always a way to optimize code - even after it has been optimizied - lol
it's looking better and better, each time
however, the program crashes if i try to open certain bmp files
not sure why that is, but it may be something to do with accessing addresses in the heap that aren't allocated
i would just work on general "clean-up"
i.e., organize the source code a little better, is all
we could use a second compatible DC in the WM_PAINT code to get rid of the flicker when sizing the window
about the flicker i googled it and found is because i
set the CS_HREDRAW or CS_VREDRAW when i fill the WNDCLASSEX structure
besides every time my window is coverd by other window then it again get the focus to
display topmost it will flicker anyway
http://www.catch22.net/tuts/flicker-free-drawing the same as the article points out
the system first send the WM_ERASEBKGND ,then WM_PAINT, so the window flicked
but when i write this
.elseif uMsg == WM_ERASEBKGND
.if hbmp
mov eax,1
jmp @f
.endif
xor eax,eax
it behaves flicker-free , but before i load a certain bmp , the bkgnd is already un-erased
why?
edit: i discover the reason ,cause i didn't call the DefWindowProc
xor eax,eax
jmp def
...
.else
def:
invoke DefWindowProc,hWnd,uMsg,wParam,lParam
ret
it seems in my wm_paint handler except paint the bmp , i have paint the rest bkgnd in the
PAINTSTRUCT retrieved by the beginpaint
Quote from: dedndave on May 21, 2012, 12:00:54 PM
however, the program crashes if i try to open certain bmp files
not sure why that is, but it may be something to do with accessing addresses in the heap that aren't allocated
can you send me a sample bitmap with that problem yahoo-email:xia_han@yahoo.cn
Quote from: dedndave on May 21, 2012, 12:00:54 PM
i would just work on general "clean-up"
what do you mean
by general clean-up, i mean better organize the flow of the source
for example, the INC files and the preamble are a bit out of whack :P
.386
.model flat,stdcall
option casemap:none
Viewer proto :DWORD,:DWORD,:DWORD,:DWORD
;
;
SaveBmp proto
include bmp.inc
.code
start:
then, in bmp.inc...
include variables.inc
pixel_offset struct
;
;
.code
then, in variables.inc...
.data
ClassName db "BmpView",0
;
;
;
lPixel dw 3
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
include \masm32\include\comdlg32.inc
include \masm32\include\gdi32.inc
include \masm32\include\comctl32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\comdlg32.lib
includelib \masm32\lib\gdi32.lib
includelib \masm32\lib\comctl32.lib
.data?
hInstance dd ?
:bg
it's like a jig-saw puzzle with a couple pieces missing
look at some of the example programs to see how they are organized
as for erasing the background, i will tell you a little trick i use :U
make a child window with no caption or borders for the image to be displayed in
you really only need 3 style flags: WS_CHILD or WS_VISIBLE or WS_CLIPSIBLINGS
when you load an image, size the child window to the same size as the image
when you register the class for the child, use NULL as the brush handle
the background will never be seen
if you have no image, hide the child window
in the child window WndProc, the only messages you have to handle is WM_PAINT and WM_CLOSE
in the WndProc for the main window, you do not have to handle WM_PAINT
so - it's basically moving some code around a little and registering a class :P
you can also get rid of the code in WM_PAINT that takes the lesser of the image size and the rcPaint size
here are a couple files - one is 256-color - the other is 16-color
one causes the program to crash - the other does not display