Would this be a useful addon for PB ?

[Chris Boss]

I am considering making an addon for PB, but I am not sure if there would be much interest in it.

The PB Graphic command set appears to be popular, but one area which it does not touch are sprites.

What is a sprite ?

To create animation in a graphic window can be difficult, especially if one must constantly redraw the image to produce the animation.

The term sprite dates back to the old days (remember the Commodore 64?), where the computers hardware could store small images called sprites, which could be moved over the background window. The advantage of a sprite is two fold. One is the sprite can have transparent pixels. Two the sprite was not actually drawn on the background image. The hardware actually combined the sprite image and the background image on the fly, so they appeared like they were drawn together, but you never had to redraw the background (unless the background changed), but only needed to move the position of the sprites,

EZGUI 4.0 Pro already has a Sprite engine, but I am considering making a version just for DDT's Graphic command set. You would be able to create, show/hide, move, animate (multiple frames), flip, anti-alias and alphablend the sprite images directly onto a PB Graphic control (which is technically a ownerdraw static control). You would not need to modify the background. The sprite engine would merge the background and the sprites for you on the fly.

So the question is:

Would there be sufficient interest in a sprite engine just made for the PB Graphic control ?

Some details:

The sprite engine would not be dependent upon any high level graphic engines in Windows, such as DirectX, OpenGL, GDI+, etc. This means it would run on Windows 95 to Vista.

The following commands would most likely be supported:

EZ_InitSpriteBuffers (initializes the sprite engine and buffers)
EZ_DefSpriteByPict (creates a sprite based on a standard bitmap)
EZ_FreeSprite (frees and existing sprite)
EZ_AssignSprites (assign a group of sprites to a Graphic control)
EZ_ShowSprites (show a group of sprites)
EZ_MoveSprites (move a group of sprites)
EZ_SetSpritesFrame (selects current animation frame for a group of sprites)
EZ_SetSpritesEfffect (sets the alphablending effect (0 to 100%) for group of sprites)
EZ_SetSpritesFlip (sets the horizonal and/or vertical flip state of a group of sprites)
EZ_GetSpriteXY (get position of a sprite)
EZ_TestSpriteClick (tests a coordinate position of a click to see what sprite gets the click)
EZ_GetSpriteFR (get a sprites maximum and current frame)
EZ_GetSpriteWH (get a sprites width and height for a single frame)
EZ_GetSpriteST (get a sprites current state such as flip, effect, etc.)
EZ_SwapSpriteOrder (swaps the zorder of two sprites)
EZ_TestSpriteColl (test sprites for collision)

Another question is ...

Would there be interest in a non-PB Graphic control version, so it could work with other types of graphic windows ?

Lastly, the price would be very reasonable (not sure of the price yet, but possibly in the $50 range).

[Chris Boss]

Today I have gotten the sprite engine working with Static style controls.

So far it has been tested with the DDT Label control, DDT Picture control and the DDT Graphic control.

I need to tweak it for speed though. Right now just concentrating on making it work with different controls.

As far as I can tell, it won't be restricted to DDT created controls.
It should work with SDK created controls as well.

The sprite engine also impliments support for WM_PRINTCLIENT so it will work even when a control is animated using AnimateWindow.

All of this in just a 34 KB DLL too !

Some screenshots of sprites and alphablended sprites on a DDT Label, DDT Graphic and DDT Picture control.

[Chris Boss]

One nice feature about this sprite engine is that you do not need a dedicated graphic control for it to work. The engine should be able to overlay itself onto any static style graphic control, even ones you create as long as the control supports the WM_PRINTCLIENT message.

If you don't know whether the graphic type control you use supports WM_PRINTCLIENT, this is easy to test.
To find out if a control class you use for graphics supports WM_PRINTCLIENT simply do the following:

Try the AnimateWindow API function on the control and see if Windows can animate it (animate means it will show or hide the control using an effect, like slide).
If it doesn't work, then the control does not support WM_PRINTCLIENT

[Chris Boss]

Some code to see how this looks when you use the sprite engine:

Initialize the sprite engine: (initializes the maximum window size to size of screen)

EZ_InitSpriteBuffers 100,-1,-1

Prepare a DDT control to be sprite ready:

CONTROL HANDLE hForm1, ID& TO hCtrl&
EZ_AttachSprites hCtrl&

Create a Sprite:

' defines a sprite called "MYSPRITE" using the bitmap (hBmp&) previously 
' loaded in above code, with 1 frame, using default transparent color of 
' purple (-1) and anti-aliased using a value of 50
'
EZ_DefSpriteByPict "MYSPRITE", hBmp&, 1, -1, 50

Show the Sprite:

EZ_ShowSprites "MYSPRITE", 1

Some fancy code in a timer event that moves the sprites (as a group with names stored in global variable App_Sprites$) up and down the control (at an angle) with the sprites solid one way and then 50% transparent the other way:

          CASE %WM_TIMER
              IF CBWPARAM=900 THEN
                  IF App_Frames&=0 THEN App_Time!=TIMER
                  IF CT&=0 THEN
                      D&=2
                      CT&=1
                      EZ_SetSpritesEffect App_Sprites$, 0,0
                  END IF
                  CT&=CT&+1
                  EZ_MoveSprites App_Sprites$, D&,D&,1
                  IF CT&=50 THEN
                      D&=-D&
                      CT&=1
                      IF D&>0 THEN
                          EZ_SetSpritesEffect App_Sprites$, 0,0
                      ELSE
                          EZ_SetSpritesEffect App_Sprites$, 50,0
                      END IF
                  END IF
                  App_Frames&=App_Frames&+1
                  App_LastTime!=TIMER
              END IF

EZ_SetSpritesEffect is used to set the transparency of the sprites (alphablending) and EZ_MoveSprites is moving them a "relative" amount each iteration. You can move sprites to an absolute position or more them relative to the current position.

[Chris Boss]

The Sprite engine is running reasonably well now.

It can attach sprites to the DDT Label, Picture and Graphic controls.

I did a benchmark test with 3 controls (Label, Picture, Graphic), each with 12 large sprites (140 x 140 pixels) for a total of 36 sprites.

Half the time the sprites were solid and half the time they were alphablended. While moving the sprites back and forth, I was able to get a decent 27 to 30 fps.

Now remember, this is not a dedicated graphic control. Actually there is no control in the engine. The sprite engine overlays the sprites on top an existing control class, such as a label, picture or graphic control.

You should be able to use it on any static image type control, even your own custom controls. As long as the control supports WM_PRINTCLIENT it should work.

Some screenshots of the test app, with 36 large sprites (smaller sprites draw faster):

[Chris Boss]

If I make the sprites only 64 x 64 pixels, I can move 16 sprites per control (total of 48) at a nice 50 fps.

Not too bad for a software based sprite engine.

[Chris Boss]

One nice use of the sprite engine is for graphic overlays.

You could create one (or a couple) large sprites the same size as the control. Then you could use them as an overlay on top of the control.

To modify the overlay, simply free the sprite and create a new one to replace it.

DDT Graphic commands allow you to build a Bitmap in memory, so you can use any DDT Graphic commands to draw on the overlay bitmap.

[Brice Manuel]

I would be very interested in this.

[Chris Boss]

I decided to add some extra graphic features to this tool.
Rather than just a sprite engine, it may be best to make it a graphic engine (including sprites) containing a number of things not provided by DDT's Graphic command set. Because it would be designed to be integrated with DDT Graphic code (ie. sprite engine can work with a DDT Graphic control) it would extend the abilities of DDT Graphics.

Some added features:

Complete Turtle Graphic (vector graphics) drawing engine.
This is not a control, but the drawing engine for my Turtle graphics engine.

One call like this:

    ' fill string with Turtle Graphics macro string
    D$="V1,602,322;"
    D$=D$+"U0;P1;F0;B4;W8;M10,10;E300,200,0;H13;M50,50;P2;W3;E300,200;H0;P2;M340,10;B14;W15;E100,100;"
    D$=D$+"H3;P2;W1;M360,130;B10;E80,120;H0;W5;P1;B3;M10,210;E400,100,4;M450,30;E121,121,7;"
    D$=D$+"M480,200;E100,100,17;M495,215;E70,70,12;W3;B15;M503,220;E15,15;M543,220;E15,15;"
    D$=D$+"X1;M530,45;P1;B5;E120,80;P2;B16;E60,40;"
    '
    EZ_DrawTurtle hDC&, D$, 0,0, W&, H&

Here is the Turtle Graphic Macro language document: http://cwsof.com/turtleinfo.rtf
Another command is the Gradient drawing command:

EZ_DrawGradient hDC&, 10,10, 40, 200, RGB(255,0,0),RGB(255,255,255), 0, 4

You just pass two RGB colors, the coordinates and the mode and it draws a gradient. The modes are:

0 - Left to right

1 - Right to left
2 - Top to Bottom
3 - Bottom to top
4 - 3D affect - Left to right/right to left
5 - 3D affect - right to left/left to right
6 - 3D affect - top to bottom/bottom to top
7 - 3D affect - bottom to top/top to bottom

The 3D affects split the object in half and uses opposite directions for
the gradient in each half.

[Chris Boss]

Fun with Aero !!!

I decided to test out the sprite engine on Windows Vista Home Premium with its Aero.

Now remember, the sprites are being displayed on standard DDT controls (Label, Picture and Graphic control).

Just take a look at the screenshots with this post.

The sprite appears to work perfectly with Aero, even in 3D mode (where all the windows are displayed in a sort of sideways 3D mode) and also the task bar preview popup. Not only that, but the sprites are still moving in both views.

As long as the original window class used with the sprites supports the WM_PRINTCLIENT message it should work fine.

[Chris Boss]

The beauty of this sprite engine is that it is not a dedicated graphic control. It overlays itself on top of the graphic control you are using.

It will also likely be inexpensive and small in size.

For example, let's say you have a custom window class you have written for your own unique graphics display. As long as you impliment the WM_PRINTCLIENT message (which is not hard to do), then the sprite engine should be able to overlay itself on top of your custom control.

Its not as fast as hardware based graphics (ie. DirectX, OpenGL), but it does have the advantage of being able to attach itself to the custom graphic controls you write (including the PB Graphic control).

Also many have invested a lot of time into learning how to get the most out of the PB Graphic commands (which is basically an ownerdraw Static control). You don't have to lose all of that. This sprite engine embeds itself into the PB Graphic control, so you can continue to use it like before, but now with some new features (Sprites and some added Graphic drawing commands).

The downside of a dedicated graphic control is that you can't use the PB Graphic commands with it. This is a good alternative IMO.

It is not limited to the PB Graphic control either.

I have tested it so far with the DDT Label, Picture and Graphic controls (all are static class).
The sprite engine is not limited to DDT only either. It can be used with SDK style coding.

[Chris Boss]

More Fun with Aero

More fun with Aero.

I added another command to the sprite/graphic engine:

ie.

EZ_SetWindowAttrEx hForm1, rgb(255,0,255),50, "AT"

This command converts a top level window (dialog) to either/both transparent or alphablended.

Here is the sprite example, using both, displayed in Aero's 3D view on Vista Home Premium (screenshot attached).

[Chris Boss]

Once again, I feel compelled to clarify something:

If one is looking for a high end graphics engine, including sprites, which takes advantage of the many advanced features found in the Windows DWM (Desktop Window Manager), then a tool like GDImage is the perfect solution, no questions asked.

Now it is a bit pricy ($695 from what I see on the web site), so I doubt many hobby programmers will be buying it, but for commercial programmers with the need it is well worth the investment.

What I am working on here, is a tool which can extend the PB Graphic controls features for those who work with it a lot. The feature set also is designed to work with older versions of Windows (ie. Win95,98) as well as current ones.

Also I am targeting a lower priced market, so it will be affordable for even hobby programmers.

Also it can overlay itself on top of your own custom window classes, so if you write your own graphic controls (ie. say a CAD control) it should be able to overlay sprites on top, as long as the control supports WM_PRINTCLIENT.

The DWM (Desktop Window Manager) in Vista takes advanced of DirectX 10 and actually buffers your windows so it can do a lot of tricks. If you need all the "glassy" effects and stuff it is really nice.

There are many different levels of graphics programming and one should use the tool best suited to your specific needs. If you need very high end, photorealistic graphics, then be willing to pay for a quality high end tool. For others, their needs are a bit more modest, their resources (money) a bit tighter, other tools, with less power but for a lower cost may do. Each programmer must decide which to use based on their needs.

Many hobby and even business applications don't need all the "bells and whistles" and the graphic needs are quite modest. The PB Graphic control will suffice for much of that. My sprite engine may be a low cost alternative to add a few extra features, but still within modest requirements.

[Patrice Terrier]

Chris i have answered you in my thread.

[Chris Boss]

Patrice,

No matter what the virtues of a programming tool is, price can be a big determining factor for many.

There is a big difference between something for say $50 and something for $695.

Now if a programmer is writing commercial software, then a large investment of $695 may well be worth it.

But for many, thats a lot of money and definitely out of the "ballpark" for hobby programmers. I write software professionally and anything over $100 is a lot, over $500 definitely better be a "must have tool" and $695 simply put, "not likely right now".

I consider my own GUI tool (EZGUI 4.0 Pro) to be well worth the money at $249. It is an extensive product with a huge feature set and may well be all that a programmer needs beyond the compiler. Yet, I know times are tough right now and I have offer sales as low as $99 (now thats reasonable). Now if it is hard for many to justify $249 for EZGUI 4.0 Pro, then how about $695 ?

I do not in anyway demean GDImage or any of your other work.
You are an excellent programmer in the area of Graphics.
Your tools are also of very high quality.

But please do not take offense at my honest comment of it being a "bit pricy". I can honestly recommend GDImage to others, but it is only fair that I include the fact it is not cheap. I can't just go around telling everyone, that they should all purchase GDImage just because of its feature set. To be fair and honest to others I also have to state that it is priced at a level for commercial programmers and not hobbiests.

It is difficult to determine whether to target the high priced or low priced markets for ones products. If development costs are high, then maybe one should only target the high priced market which can afford it (professionals). If one can afford to do so, pricing a product so even the "common man" can buy it is a choice some make. There are risks in this, I know.

If you target the high priced market, don't waste time trying to compare your product to every low priced (less featured) competitor that comes along. They have their market and your higher quality tool has its. Be content with that.

[Brice Manuel]

Chris, would you consider a version without the turtle graphics? Just a straight sprite engine?

[Chris Boss]

Yes.

Do you think many would prefer just the sprite engine alone ?

Ok, I recompiled it with just the sprite engine alone (no turtle graphics, no gradients, etc.) and it comes out to a whopping:

33 KB DLL for the entire sprite engine alone.

[Brice Manuel]

I can't speak for others, but you already offer the turtle graphics in its own package for those who need it.

Personally, I am only interested in a sprite engine, and keeping it as compact (size-wise) as possible.

[Chris Boss]

Here is a simple demo of the sprite engine in action:

http://cwsof.com/ezsprite.zip

The current runtime DLL (only the sprite engine) is only 36 KB .

Note: the demo download has compressed the runtime DLL using UPX, down to 16 KB.

In the demo you can slow down the animation (click button to add 50 ms sleep to each cycle) so you can see the animation of the sprites better, particularly the balloon sprite which flips frames.
(thats why the screenshot only shows 13 fps)

With 24 large sprites (140 x 140 pixels) you can get about 50 fps out of it.

48 sprites, the balloon sprites can get about 29 fps.
100 sprites, the balloon sprites can get about 15 fps.

[Brice Manuel]

With the demo, I am getting:

70 FPS - non alpha blended
65 FPS - alpha blended

Amazing framerate, especially since it appears the sprites (balls) by default are being anti-aliased.