The MASM Forum

Here's a cute/stupid little project. Run it, you'll see what it is.

I'm thinking of making this into a retro-looking progress indicator, but a lot smaller.

Made the bitmaps with CorelDraw, massaged with Paint Shop Pro.

I used TransparentBlt() to draw the outline with transparency; saved a lot of hassle messing around with bitmap masks and other crap. Two problems: it's not in the MASM library, even though it's been around since Windows 2000 (solved with LoadLibrary() and GetProcAddress() ), and I discovered that contrary to what the documentation says, it won't work at all if the source and destination DCs (in other words, the source bitmap and the destination DC) aren't exactly the same size. (The Microsoft docs say that the source bitmap will be stretched to fit the destination rectangle, but apparently that's a lie.)

I was going to make a wisecrack about its potential practical usefulness  :mrgreen: , but the program is actually useful  :biggrin: . It demonstrates how to use TransparentBlt.  :thumbsup:
There is an occasional white flicker in the barber pole interior, but otherwise the animation is smooth.

Yeah, I was bothered by that flicker too. If I make a nice little BarberPoleProgressBar, it'll probably be small enough not to flicker. Not gonna obsess over it and work on double-buffering or whatever.

Very cute, David :thumbsup:

OK, while you guys were cracking wise**, I had my nose to the grindstone (bloody grindstone!), and now the barber pole is a bona fide Windows control. Meaning you could put it into your own program as a progress indicator. For now just posting the demo program; you can see that there are 3 completely independent poles, each one a child control in the dialog. I'll post the complete control code shortly. Love to see someone actually use this in a program. (Hey, maybe we could come up with a whole retro user interface, maybe kind of a steampunk look ...)

** Not in this thread ...

How quaint.  :thumbsup:   Still a bit of flickering.

Hmm; so any suggestions on how to get rid of flickering? I can post source later; for now, my WM_PAINT handler uses exactly two calls per animation "frame" (spaced at 30msec), one to BitBlt(), the other to TransparentBlt(). CPU usage is 0, according to Task Manager. (Oop,, miswrote there: only 1 animation call every 30ms, BitBlt(). The TransparentBlt() only gets called when the "frame" needs redrawn.)

With all 3 controls running I see little flashes maybe every 10-15 sec.

For anyone interested in trying out this control, everything you need is attached here. There are two batch files, one to assemble the control, the other to compile the test program. You'll need the 2 bitmaps as well (for the control), loaded through the resource file.

To start and stop the control, use the private messages:


; To turn the pole on:
INVOKE SendMessage, <control handle>, WM_BARBERPOLE_ON, 0, 0

; To turn it off:
INVOKE SendMessage, <control handle>, WM_BARBERPOLE_OFF, 0, 0


Let me know how it works for you. Oh, and be sure to call InitBarberPole() before creating a window or using it in a dialog.

Quote from: NoCforMe on January 02, 2023, 02:11:02 PM
Hmm; so any suggestions on how to get rid of flickering?

Nope. Some of my programs were notorious for the same thing.  :toothy:


Edit = correction.  :tongue:

Oops--forgot one of the files needed to build the testbed. Attached below.

Quote from: zedd151 on January 02, 2023, 04:30:58 PM

Quote from: NoCforMe on January 02, 2023, 02:11:02 PM
Hmm; so any suggestions on how to get rid of flickering?

Nope.

But I may look into it at some point in the future. :cool:

Since your handling the background of the control yourself, I would add in

CMP EAX, WM_ERASEBKGND
JE do_paintbg

to the message section, and then:

do_paintbg:
   mov eax, 1
   ret



Probably some double buffering is required to eliminate any flickering. Also I would create the background brush beforehand and use the brush handle in the WM_PAINT rather than creating it each time, so at init of program gui stuff, or WM_INITDIALOG, but if not no worries, no harm with the way your doing it now anyhow.

TransparentBlt can be found in the msimg32.inc, so add this to the program to use it:

includelib msgimg32.lib
include msgimg32.inc

Quote from: fearless on January 03, 2023, 05:27:33 AM
TransparentBlt can be found in the msimg32.inc, so add this to the program to use it:

includelib msgimg32.lib
include msgimg32.inc

That is good to know, fearless. Also I found there ... AlphaBlend and GradientFill.
These might be handy for me one day. Odd that they are here (msgimg.inc) instead of gdi32.inc. Microsoft, sometimes I wonder ...  :rolleyes:

WinGdi.h:
WINGDIAPI BOOL WINAPI TransparentBlt(
    __in HDC hdcDest,
    __in int xoriginDest,
    __in int yoriginDest,
    __in int wDest,
    __in int hDest,
    __in HDC hdcSrc,
    __in int xoriginSrc,
    __in int yoriginSrc,
    __in int wSrc,
    __in int hSrc,
    __in UINT crTransparent);

Quote from: fearless on January 03, 2023, 05:27:33 AM
Since your handling the background of the control yourself, I would add in

Code Select Expand

CMP EAX, WM_ERASEBKGND
JE do_paintbg

to the message section, and then:

Code Select Expand

do_paintbg:
   mov eax, 1
   ret


Thanks for that. But wouldn't I have to do this:


INVOKE BeginPaint, hWin, ADDR ps
INVOKE EndPaint, hWin, ADDR ps


in order to remove the paint request from the queue? or does just returning TRUE, as you suggested, do that?

So now I have a packaging problem with this project.

The problem is that the barber-pole control requires some resources, two bitmap files. I'm loading these via a resource (.rc) file that gets converted to an .obj file.

Problem #1: Now I have two files that need to be linked instead of just one. OK, fine. My first move was to look for a tool that could combine multiple object files into one. Turns out such a thing probably doesn't exist. (This was covered in this thread here (https://masm32.com/board/index.php?topic=6813.0) a few years ago.) I did find an online tool (https://fileproinfo.com/tools/merger/obj) that said it could merge OBJ files; I tried it, but the linker said the file was corrupted. So scratch that. (* See below for more info.)

OK, so I took Hutch's suggestion from that thread and created a library with the BP control code and the BP resource. Linked it.

Problem #2: That doesn't work: the control initialization code failed when it tried to load the bitmap resources ("The specified resource type cannot be found in the image file"), even though the resource was in the library. And no, I don't have anything at all in my code with the same resource IDs (400 & 401).

Alright then; so I went back to just using .obj files. I have the following files:

• BPcontrol.obj: the control code
• BP_resources.obj: the bitmap resources
• BPtest.obj: the testbed program code
• VisualStyles.obj: the magic resource that gives the less-ugly look to everything

Tried linking all 4 of those together (this is to create the demo testbed program).

Problem #3: it linked, but the linker threw a warning:

VisualStyles.obj : warning LNK4059: BP_resources.obj already specified; additional resource file ignored

So I got a working demo program, but one with ugly "old-style" buttons. Yuck. It looks like the linker only allows you to have one single resource file per .exe? is that right? Seems like a ridiculous restriction.

So how do I package both the control code (BPcontrol.obj) and the resources it needs (BP_resources.obj) together so the user can easily include the control in their program?

I got around before this by putting the Visual Styles junk (xpmanifest.xml) into the resource file. But that's the wrong way to do it, because this resource should be put in for the final executable, not as part of the control.

Help!

p.s.: I found something in this Stack Overflow post (https://stackoverflow.com/questions/531502/vc-resources-in-a-static-library) that seems to confirm what I suspected about putting resources in a static library:

QuoteNote that you can't lib in object files created with cvtres. If multiple object files are provided, lib complains as though as multiple .res files were given; if a single object file is provided, lib does not complain, but the linker simply ignores the embedded resource data in the lib file.

Embed the icons in .data rather than putting them in the .rc file? I don't have an example to show you, but I know that it is possible.

Quote from: NoCforMe on January 03, 2023, 12:25:51 PM
does just returning TRUE, as you suggested, do that?

Yes

And I also embed resources as static data declarations in libraries. I use Hutch's bin2db/bin2dbex (found in the masm32 install folder) to convert images to data. Then you can use something like vortex's functions to load bitmaps from memory - using the address of the static resource. I think this is the relevant post: https://masm32.com/board/index.php?topic=4642.msg49923#msg49923

Quote from: fearless on January 03, 2023, 03:15:04 PM
And I also embed resources as static data declarations in libraries. I use Hutch's bin2db/bin2dbex (found in the masm32 install folder) to convert images to data. Then you can use something like vortex's functions to load bitmaps from memory - using the address of the static resource. I think this is the relevant post: https://masm32.com/board/index.php?topic=4642.msg49923#msg49923

Yes! Thats where I read about embedding resources in the data section. Exactly the sort of thing that I was referring to. I was going to search for this later, unil I saw your posting, fearless.

Our minds apparently run in the same gutters; that's exactly what I'm doing now. I was all set to write my own "DB generator" when I realized there's one in the MASM tools folder. I'm converting the BMPs to DBs (not that big, doable), then using CreateBitmapIndirect() to "open" them.

Screw the resource compiler anyhow.

Its actually a good technique if you want to make resources much harder to find as you cannot just acces the resource with a resource hacker.

If security is not the issue, you can embed resources in the resource section with the following.

20 RCDATA "toolbar.png"

Hutch, did you read my post above? I can't use resources with a library at all; just doesn't work. (The library says it puts them in the .obj but it doesn't.)

And I can't have more than one resource file for the .exe, so the .exe builder can't use any resources either. So I'm stuck doing things this way.

Are you talking about putting 20 RCDATA "toolbar.png" in an .rc file and converting it? That won't work for me for the reasons I gave above. Unless I'm missing something here.

The DB format works fine in a library module, I added the comments about 20 RCDATA "toolbar.png" as not everyone knows how to use it.

Strangely enough, there is good reason why I produced the tool to convert either data or code to DB format, I am pleased you have found one of them.  :biggrin:

"The DB format works fine in a library module". What do you mean? In an .asm file, right? but one that's going to get put into a library? I already told you: I cannot use a library here.

 :biggrin:

The basics are, if you can read a DB format block ANYWHERE in code, it will work, in an EXE, DLL, Library module or even as a remote file, its just bytes. I have missed what your compliants is here.  :rolleyes:

Well, OK. Moving on here: I've encoded both bitmaps as data (DBs), and have a loader coded for them which (apparently) loads successfully, using CreateBitmapIndirect(). At least it gives back a handle and not an error. But the bitmaps don't render at all, so now I'm in the swamp: am I working with DDBs here? or DIBs? top-down? bottom-up?

First strange thing is that I produced both bitmaps with the same tool (Paint Shop Pro), yet they have different headers: one uses the BITMAPCORHEADER format, while the other uses the BITMAPINFOHEADER format. So I have code to handle both formats. But how do I know whether I'm creating a DDB or a DIB?

The bitmap stuff in GDI makes my head hurt ...

If you can tolerate quirky work arounds, write the DB data to a temp file then load it as an external file.

Quote from: NoCforMe on January 03, 2023, 12:57:19 PM
So now I have a packaging problem with this project.

The problem is that the barber-pole control requires some resources, two bitmap files. I'm loading these via a resource (.rc) file that gets converted to an .obj file.
...
p.s.: I found something in this Stack Overflow post (https://stackoverflow.com/questions/531502/vc-resources-in-a-static-library) that seems to confirm what I suspected about putting resources in a static library:

QuoteNote that you can't lib in object files created with cvtres. If multiple object files are provided, lib complains as though as multiple .res files were given; if a single object file is provided, lib does not complain, but the linker simply ignores the embedded resource data in the lib file.

From the same SOF post:

QuoteThe only thing you need to do to use resources (images, dialogs, etc...) in a static library in Visual C++ (2008), is include the static library's associated .res file in your project. This can be done at "Project settings/Linker/Input/Additional dependencies".

With this solution, the resources of the static library are packed into the .exe, so you don't need an extra DLL. Regrettably, Visual Studio does not include the .res file automatically as it does for the .lib file (when using the "project dependencies"-feature), but I think this small extra step is acceptable.

I have looked for a very long time for this solution, and now it surprises me it is that simple. The only problem is that it is totally undocumented.

It is an interesting problem, and I wonder whether polib has a solution for assembler programmers :cool:

Actually I got the wrong function and post. It was Vortex though, and it was his CreateBmpFromMem function: http://www.masmforum.com/board/index.php?topic=16267.msg134453#msg134453

I adapted it slightly to create a version that doesn't require the hWin param as it creates a DC to use to create the bitmap and return that bitmap handle:
https://github.com/mrfearless/ModernUI/blob/master/ModernUI/MUICreateBitmapFromMemory.asm

And I adapted a CreateIconFromData function from Donkey as well: http://www.masmforum.com/board/index.php?topic=16267.msg134434#msg134434
https://github.com/mrfearless/ModernUI/blob/master/ModernUI/MUICreateIconFromMemory.asm


I use that function in the checkbox control to load the static icons that are stored in https://github.com/mrfearless/ModernUI/blob/dd20260d03bc0be68cd8921eced697a83442d6b4/Controls/ModernUI_Checkbox/ModernUI_Checkbox_Icons.asm

https://github.com/mrfearless/ModernUI/blob/dd20260d03bc0be68cd8921eced697a83442d6b4/Controls/ModernUI_Checkbox/ModernUI_Checkbox.asm#L600

Also it occurred to me that the barber pole bitmaps could be made smaller and used with CreatePatternBrush (https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createpatternbrush) to paint that image / fill the control with that image. You can also use it with PatBlt function.

You could also do one barberpole bitmap each for vertical or horizontal and depending on orientation of control as specified by some property or message or custom style on creation you can switch brushes and fill the control with the proper image.

Quote from: NoCforMe on January 03, 2023, 12:57:19 PM
So now I have a packaging problem with this project.

Have fun with the attachments - just drag your bmp file over EmbedData.exe :biggrin:

Usage:
include \masm32\include\masm32rt.inc
.DATA
include \Masm32\Members\NoCForMe\BarberPole\_BPoutline.inc

.code
start:
  mov esi, offset BPoutline-4
  lodsd

  MsgBox 0, cat$(str$(eax), " is the file size"), "Embedded data:", MB_OK
  exit

end start

Thanks to the lodsd, esi now points to the "resource", and you know it has 1674 bytes :cool:

EDIT: Modified version generates the *.asm file for testing. For example, a 160k jpg image generates a 3,400 lines inc file :biggrin:

Thanks, Fearless. Good ideas there.

So: I finally accomplished getting the control into one module; only one .obj file, so easier for users to deal with it. (There's an .inc file as well for the user.) I must say this was quite a painful process to get it to work. Here's what I had to do:

1. Create the bitmaps as data within the control code:
I used Hutch's bin2db tool which worked very nicely to create assembler DB text from both bitmaps, then just pasted them into the code. This was actually the easiest and most trivial part of the process.

2. Copy values out of the bitmaps into a BITMAP structure:
I found that the two bitmaps I was using had different header structures: one used the BITMAPCOREHEADER structure while the other used BITMAPINFOHEADER. (I have no idea why this is: both bitmaps are close in size and were created with the same tools, CorelDRAW and Paint Shop Pro.) So I needed to get the values into a consistent form. The way to tell these two structures apart, by the way, is to look at the biSize (or bcSize, same difference) element to get the size of the structure: BITMAPCOREHEADER is 12 bytes, while the other one is 40. First pain in the ass.

3. Create a bitmap:
Seems strange, doesn't it? I've got a bitmap here, all the bytes in memory, but I can't use it for anything. So I have to create a new bitmap. I first tried using CreateBitmapIndirect(), but that didn't work at all. So now what I have to do is this:

3a. Create a dummy window:
Since the next step requires a handle to a DC, I need to create a dummy window so I can get a DC from it. I created a zero-size window of type "static" (no need to mess with RegisterClassEx()).

3b. Get a DC:
That's easy, just use GetDC, dummyWinHandle.

3c. Copy values from BITMAP to BITMAPINFO:
Since the next step requires a BITMAPINFO structure, do another copy. (I just realized: why didn't I just copy to this structure in the first place? Will go back and simplify my code later.)

3d. Copy the palette from the in-memory bitmap to the BITMAPINFO struct:
I copy the RGBQUAD structures from the in-memory bitmap to the bmiColors element of the BITMAPINFO struct. Slight pain in the butt here: you can't create this as a local variable because bmiColors is defined as only a single RGBQUAD element; we need 16 of them in this case (since I know that the bitmaps will always be 16 colors). So I had to define a static variable of type BITMAPINFO, then follow it with 15 RGBQUAD structs so the data would fit.
Further pain in the ass: Depending on which type of header (BITMAPCOREHEADER or BITMAPINFOHEADER) the file had, the RGBQUAD entries are either 3 or 4 bytes, so I had to be sure to move the right number of bytes depending.

3e. Create the bitmap:
Phew! Finally I can create the bitmap, using CreateDIBSection(). After looking online and trying several other methods, this is the one that finally worked. It's easy; you pass it a pointer to the filled-out BITMAPINFO struct, with the palette entries copied into it, and it gives you back a pointer to where the actual bitmap data goes. It returns a handle to the bitmap, which I store for the paint handler.

4. Copy the bitmap bits into the new bitmap:
Easy peasy; you get a pointer where they should go, you know where they are in the in-memory bitmaps, and the count of bytes to move is just height X width.

All that's left at this point is to clean up (release the DC and destroy the dummy window).

Like I said, pain in the ass, but it works.

But wait, there's more. No project like this is complete without an ugly workaround. There's a gnarly problem I couldn't solve: I got both bitmaps to render, but for some reason the "animation" bitmap (the barber-pole stripes) had an ugly red blotch at the top. I could not figure out why this was happening: I tracked the bitmap data through my code, and it wasn't getting corrupted. I also discovered that the bitmap data in the file did not exactly correspond to the pixels I could see when I edited the images; I still am stumped by this.

Turned out that for some unknown reason, everything worked fine if I flipped the image vertically by setting the height value to a negative number; this changes the image from top-down to bottom-up. To compensate I had to flip the actual image from side to side (mirroring). So it's a kluge, but hey, it works.

The other strange thing is that if I take a screenshot of the control, the pixels I see on-screen are not at all the same pixels in the bitmap, as I would have thought. Obviously a lot of processing is going on there behind the scenes to render it, and I suspect that's maybe why I was getting that big red blotch at the top (the first non-white color in the image is red, and maybe it's using that as some kind of default fill color or something; who the hell knows?).

Hi, NoCfor me. How's it going frying this fish? Yes, I know you got sidetracked  :tongue: . Any good progress here?

Can probably skip a good few of the steps just using the function that vortex has, or the one I adapted from it. I include a simple example to show how to use it.

99% done. I'm pretty sure. We'll see.
NOTE: .zip archive has been updated (forgot to include the control's .obj file)

Here's the whole package, the control module and the demo program, ready for use. There's even a readme file. I hope someone's silly enough to take the time to try this out. I'd love to see this in someone's program.

The demo program shows how you can vary the speed of the animation by setting the delay time. This can be set through messages to the control. You can also set the background color to something other than the default (which is the standard Windows dialog BG color).

Have fun! I did when I wrote this.

Quote from: fearless on January 05, 2023, 05:16:40 AM
Can probably skip a good few of the steps just using the function that vortex has, or the one I adapted from it. I include a simple example to show how to use it.

Ack! You're absolutely right. I used the wrong function (CreateDIBSection() instead of CreateDIBitmap(), which copies all the data for you). My code works, but with unnecessary effort copying the RGBQUADS and bitmap bits. Will change it at some point. For now, since it ain't broke I don't want to fix it.

I also didn't realize you could use CreateDC() to create a DC out of thin air without having to create a dummy window like I did. Live and learn.

 :tongue:  When you are finishing that 1%, probably would be a good time to try fearless's improvements. I have yet to look at your current progress. Will do so when I'm back in the house.  :biggrin:

So Fearless, regarding your suggestion to try using patterned brushes instead of a bitmap: interesting idea. I'm familiar with patterned brushes, but I wanted to check something with you.

Currently my animation has 13 iterations; does this mean I would need to create 13 brushes and alternate them? So far as I know you can't change the starting position of a brush like you can a bitmap with BitBlt(). Would I still get a performance improvement over using a bitmap?

Quote from: NoCforMe on January 05, 2023, 06:51:40 AM
I hope someone's silly enough to take the time to try this out.

Fantastic! "Look ma, no resources!"
Your little testpiece works well. I cannot detect any flicker in the animations.  :thumbsup:

later: Played with the delay as well, works good.

QuoteThere are two files for this control:
   - BPcontrol.obj:  link this with your program
   - BarberPole.inc: include file for your .ASM source file

No BPcontrol.obj in the archive :rolleyes:

Quote from: NoCforMe on January 05, 2023, 07:12:41 AM
So far as I know you can't change the starting position of a brush like you can a bitmap with BitBlt(). Would I still get a performance improvement over using a bitmap?

You can use SetBrushOrgEx to change the start position of the brush if its just the full bitmap image, so you probably want to account for the size of the bitmap to account for that for the animation.

    Invoke SetBrushOrgEx, hdcMem, dwXOrg, dwYOrg, 0; //Set the brush origin (relative placement)     
    Invoke FillRect, hdcMem, Addr rect, hBackBrush
    Invoke SetBrushOrgEx, hdcMem, 0, 0, 0; // reset the brush origin (relative placement)

I think patblt will repeat the brush. Might have to try out both options to see what works. I imagine if the patblt fills the entire control size, then you can set the start coords position outside of the control (say -12) and increment the position to make the animation so that the last position is 0 if you follow my thought.

Ive used SetBrushOrgEx before to fake a transparent background for a child control - based on a large bitmap for the background dialog (was a picture of a old yellowed pages of a book). I had to calc the window rect of the child control relative to the parent to use that for the brush x y coords, which then paints that backbrush starting at those coords onto child control, thus making it look like the child control background is transparent.

(https://i.postimg.cc/1nSMQrVb/tom.png) (https://postimg.cc/1nSMQrVb)

Two things:
1. I updated the .zip archive in reply #34 to include BPcontrol.obj. Glad someone's interested in it!
2. fearless: Thank you. I reduced that mess o'code I had to just 16 lines. So much simpler! Here's what I ended up with:


;====================================
; GetBP_BMPdata (bmpPtr)
;
; "Opens" BMP "file" (from memory), massages it.
;
; Returns handle to bitmap.
;
; Hat tip to "Fearless" of the MASM forum for
; vastly simplifying this process!
;====================================

GetBP_BMPdata PROC bmpPtr:DWORD
LOCAL hDC:HDC

INVOKE CreateDC, OFFSET CreateDCdeviceName, NULL, NULL, NULL
MOV hDC, EAX
MOV EDX, bmpPtr
LEA ECX, [EDX + SIZEOF BITMAPFILEHEADER] ;Point to BITMAPINFOHEADER header.
MOV EAX, [EDX].BITMAPFILEHEADER.bfOffBits ;Offset of bitmap bits.
ADD EDX, EAX ;Pointer to bitmap bits.
INVOKE CreateDIBitmap, hDC, ECX, CBM_INIT, EDX, ECX, DIB_RGB_COLORS
PUSH EAX
INVOKE DeleteDC, hDC
POP EAX
RET ;Return w/handle.

GetBP_BMPdata ENDP


Very nice :thumbsup:

GuiParas equ "Barber Pole", w200, h444, m0, b LiteGrey
include \masm32\MasmBasic\Res\MbGui.asm
  include BarberPole.inc
  invoke InitBarberPole, rv(GetModuleHandle, 0)
  SetGlobals hCurrent
  GuiControl MyStatic, "static", "Left-click to start, right-click to stop", y50, x600, w400, h0+80
  GuiControl bp1, "barberpole", y50, x50, w0+32, h0+96
  GuiControl bp2, "barberpole", y150, x200, w0+32, h0+96
  GuiControl bp3, "barberpole", y250, x350, w0+32, h0+96
  GuiControl bp4, "barberpole", y350, x500, w0+32, h0+96
  GuiControl bp5, "barberpole", y450, x650, w0+32, h0+96
  GuiControl bp6, "barberpole", y550, x800, w0+32, h0+96

Event Message
  .if uMsg_==WM_SETCURSOR
        m2m hCurrent, wParam_
  .elseif uMsg_==WM_PARENTNOTIFY
        mov eax, WM_BARBERPOLE_ON
        .if word ptr wParam_==WM_RBUTTONDOWN
                inc eax
        .endif
        invoke SendMessage, hCurrent, eax, 0, 0
  .endif
GuiEnd         ; OPT_DebugL    BPcontrol.obj

Quote from: NoCforMe on January 05, 2023, 11:47:08 AM
I reduced that mess o'code I had to just 16 lines. So much simpler! Here's what I ended up with: ...

Congrats!

Quote from: jj2007 on January 05, 2023, 11:57:06 AMVery nice :thumbsup:

I second that... 
jj, nice example.

JJ--very cuuute! (And yes, that's a compliment; I likes cute.)

Now we just need to design a whole steampunk-looking interface to incorporate that. I actually looked into that a little; turns out that that topic has already been pretty well covered by game designers.

BTW, do you know why barber-pole stripes are red and blue? The answer: blood. Back in the day, barbers were also surgeons and doctors of a sort. Amputated limbs and stuff. (Sweeney Todd is a good look at that time ...)

Quote from: NoCforMe on January 05, 2023, 12:09:03 PM
Back in the day, barbers were also surgeons and doctors of a sort.

And 'dentists', well they did pull teeth at least (without anasthesia I've heard). Ouch!

Version 2 attached, a whopping 25 lines long. Now you can save a barberpole image with a right-click :cool:

That's pretty cool, JJ.

I swear, every time I see "GuiParas" I think "GUI paragraphs", which of course makes no sense.

I need to look into your code to discover how to save a bitmap back to a file. Something I'll be doing soon in another project.

Quote from: NoCforMe on January 05, 2023, 03:26:04 PM
I need to look into your code to discover how to save a bitmap back to a file. Something I'll be doing soon in another project.

This might be helpful, I converted to 32 bit from Vortex's 64 bit screen capture tool
32 bit screen capture (http://masm32.com/board/index.php?topic=7289.msg79390#msg79390) yes I know that esi, edi was not preserved there :tongue:  but it should give you a starting point ... for writing the file headers, etc.


Disclaimer: That code is over four years old, and I don't remember much about it. I just remember I was experimenting converting 64-->32 bit code at that time.  :biggrin:  The code worked, so I left it as is ... after a little dabbling with it.
I should one day, check my older attachments for errors such as that (register preservation) and fix it to reattach a better example in its place.  :tongue:

Don't worry, those are just details. All I really need to get started is the general idea of what functions to use, and where to find the data I need. That all seems to be there. I'm sure I can write bitmaps using [most of] that code. Doesn't matter if a few PUSHes or POPs are missing.

Quote from: NoCforMe on January 05, 2023, 04:19:52 PM
Don't worry, those are just details. All I really need to get started is the general idea of what functions to use, and where to find the data I need. That all seems to be there. I'm sure I can write bitmaps using [most of] that code. Doesn't matter if a few PUSHes or POPs are missing.

:biggrin:  There is a link to Vortex's 64 bit version in that post if anything in my code is unclear. Even though it is 64 bit, may prove useful as well. Just returning the favor, as you have provided me with useful code in another project.  :cool:

Quote from: NoCforMe on January 05, 2023, 03:26:04 PM
That's pretty cool, JJ.

Thanks :thup:

QuoteI swear, every time I see "GuiParas" I think "GUI paragraphs", which of course makes no sense.

GUI parameters it is, of course. In hindsight, I should have chosen the long GuiParameters (GuiArgs?) version, but now it's too late to adapt hundreds of old sources :sad:

QuoteI need to look into your code to discover how to save a bitmap back to a file. Something I'll be doing soon in another project.

It's mostly public, in \Masm32\MasmBasic\Res\MbGui.asm

Without GuiParas and other bells & whistles, it's a six-liner :biggrin:

include \masm32\MasmBasic\Res\MbGui.asm
include BarberPole.inc
  SetGlobals hCurrent=rv(InitBarberPole, rv(GetModuleHandle, 0))
  GuiControl bp1, "barberpole", y50, x50, w0+32, h0+96
  invoke SendMessage, hbp1, WM_BARBERPOLE_ON, 0, 0
GuiEnd         ; OPT_DebugL         BPcontrol.obj