gdiplus tests

[jj2007]

I remember when JJ would be posting in astonishment at the prospect of such a simple task needing to import 10 dlls and nearly 300 functions. What happened to that guy? Looks like he's gotten into bed with  the bloat industry

A Hello World in MasmBasic weighs in at 32kBytes. That is bloat in Masm terms, I agree - but it's still tiny in comparison to a QT Hello World at several MB.

If you choose Say "Hello World" instead of Print, that adds only 512 bytes: no external libs, just a call to a built-in Windows feature.

The animated GIF in seven lines of source code costs 57kBytes. Serious bloat, of course

It's a compromise: some bloat, yes, but in turn you get comfortable graphics, string handling, file io (e.g. GetFiles) and much more. Hutch managed to keep all modules of Masm32 separate, they don't depend on each other, and therefore you can indeed produce a 1024 byte Hello World. But you have to add a lot of work for even simple things. MasmBasic has a core block of over 200 functions that costs around 32kBytes, and they do depend on each other, so no way to keep them as tiny as pure Masm32. I can live with that

I attach another example. Here is the source:

Code Select Expand

include \masm32\MasmBasic\MasmBasic.inc
  Init
  Say FileRead$(uCL$())
EndOfCode
The text in the file passed via the commandline (e.g. by dragging over the exe) must be UTF-16. I'd like to know whether it works for those of you who have an OS in Russian, Chinese or Arabic. I get an Italian voice ;-)

Don't drag TheHolyBible.txt over the exe, it might choke

[zedd151]

But it was a cute feature.    animate on resizing

Well, not really a feature

Do you realize how many mistakes, accidents, or otherwise 'not by design' inventions there are, that are multimillion dollar industries today?   

[sinsi]

My attempt at GDI+ GIF animation.
I've tried to make it MASM32 compatible 
No comments though 

[zedd151]

@sinsi:

Seems a little off. I opened the .gif in ImageReady and the animation displays properly there, RoadRunner runs.
But in your example, looks like RoadRunner has the shakes or is shivering, rather than running.

At least it shows the concept of getting the individual .gif frames. And working with multi frame gifs in general.

Used this your gif with jochens example from #59, and it animates better with his, but still not perfect.

Carry on with your gdiplus tests, guys. The more the merrier. 

[sinsi]

It's on a timer, changing the delay helps a little.
The main problem is that the background doesn't get erased.

It was a quick test to see the steps involved in actually getting it to animate.
The next step is smoothing it out.

Not too bad for ~10 lines of gdiplus code and an hour of frustration on google

[zedd151]

It's on a timer, changing the delay helps a little.

tried that, to no great improvement

The main problem is that the background doesn't get erased.

Sounds like a likely possible cause

It was a quick test to see the steps involved in actually getting it to animate.
The next step is smoothing it out.

okay, so it really is experimental test code

Not too bad for ~10 lines of gdiplus code and an hour of frustration on google

[sinsi]

Updated. Now double buffered and resizable (looks crap when embiggened).
Might try a bigger GIF with more frames next.

[zedd151]

Thats better. You're getting there.

btw I had to, in both cases, complete the path to "gdiplus.lib":
to --> "includelib  \masm32\lib\gdiplus.lib"

otherwise no problem assembling and linking

[sinsi]

Thats better. You're getting there.

Gee, thanks grandpa

btw I had to, in both cases, complete the path to "gdiplus.lib":
to --> "includelib  \masm32\lib\gdiplus.lib"

Yeah, I use a VS batch file and the Windows SDK libraries and binaries.

[zedd151]

Thats better. You're getting there.

Gee, thanks grandpa

btw I had to, in both cases, complete the path to "gdiplus.lib":
to --> "includelib  \masm32\lib\gdiplus.lib"

Yeah, I use a VS batch file and the Windows SDK libraries and binaries.

Ok, that's fine. It wasn't a major job to fix it.
You young whippersnappers... 

[NoCforMe]

Regarding terminology: since when did "functions" become aggrandized to "APIs"? An API ("application programming interface") is the entire collection of things--functions, structures, enumerations, etc.--that accomplish certain tasks. GDI+ is an API; GdipDeleteGraphics() is just a function within that API.

To nitpick further, traditionally a "function" was a procedure you called and got a result back.
Not all Windows procedures return a result, so not all Windows procedures are functions.
Perhaps we could use the term "Windows API call"?

Welll, to expand on the pedantry just a bit more, technically speaking a "function" is, in mathematical terms, a black box (formula, etc.) that for each input value (x) produces a single output value (y) (so a parabola is a function while an ellipse is not).

However, as you point out, not all Win32, ahem, things that you call behave this way; some produce no output, while others produce more than a single value. So mathematically speaking they ain't functions.

But we need to call these things something, right? (My instinct is to call them "subroutines".) So Micro$oft, and practically everyone else out there has chosen to call them "functions". Which pretty much works for me; no need for hairsplitting here, even if it's not mathematically correct.

I just came up with another name: why don't we call them "Flamzingers"? That oughta settle it for good. (Somehow, though, I don't really see this catching on ...)

[Vortex]

Hello,

Here is a GdipCreateBitmapFromGdiDib example. This demo reads a bitmap file from disc and retrieves the handle of the image with help of GdiPlus function :

Code Select Expand

   .IF uMsg==WM_CREATE

        mov     eax,OFFSET StartupInfo
        mov     GdiplusStartupInput.GdiplusVersion[eax],1
        mov     GdiplusStatus,eax

        invoke  GdiplusStartup,ADDR token,ADDR StartupInfo,0

        invoke  ReadFileToMem,ADDR filename,ADDR pMem,\
                ADDR pBytesRead

        mov     eax,pMem
        mov     ecx,BITMAPFILEHEADER.bfOffBits[eax]
        lea     edx,[eax+ecx]                               ; points the array of bytes that contains the pixel data
        add     eax,SIZEOF BITMAPFILEHEADER                 ; points the BITMAPINFO structure

        invoke  GdipCreateBitmapFromGdiDib,eax,edx,\
                ADDR BmpImage
                                                            ; creates a Bitmap object based on a BITMAPINFO structure and
                                                            ; an array of pixel data                                                                                                                       
        invoke  GdipCreateHBITMAPFromBitmap,BmpImage,\
                ADDR hBitmap,0

        invoke  VirtualFree,pMem,0,MEM_RELEASE

[zedd151]

@: NoCforMe
How about if we just call it a thingy. 

If I or anyone else calls it an api, function, or anything else while also mentioning it by name, I am 100% certain that you or anyone else here that reads it will know exactly what I am talking about. Semantics, pedantics or any other kind of antics aside. 

Stop being a buzzkill. 

@Vortex:
Nice example, Vortex.

We are testing using gdiplus functions, for some of us, using gdiplus for the first time. Most of what is posted here is experimental or test code, not fully debugged examples. Thanks for your excellent contribution, it is appreciated.

[jj2007]

Updated

You might use a lighter background. The animated-looney-toons-image-0017.gif is transparent (tweetie isn't)

[NoCforMe]

@: NoCforMe
Stop being a buzzkill. 

No.