EZSprite coming soon

[Chris Boss]

My Sprite Engine is basically finished and I am now working on the help files and sample apps.

The plan is to offer two different products:
(the details below are subject to change before final release)

EZSprite Lite 1.0 for $39 (US)

and

EZSprite Plus 1.0 for $69 (US)



EZSprite Lite 1.0 will be for use primarily with DDT Graphics, while there is no reason it could not be used with other coding styles such as SDK.

The command set will be:

Sprite Commands:

EZ_AttachSprites (Attach Sprite Engine to a control)
EZ_InitSpriteBuffers (Intialize Sprite engine)
EZ_FreeSprite (Free an existing Sprite)
EZ_SwapSpriteOrder (Swap Zorder of two Sprites)
EZ_AssignSprites (Assign a group of sprites to a control)
EZ_MoveSprites (Move a group of sprites)
EZ_ShowSprites (Show/Hide a group of sprites)
EZ_SetSpritesEffect (Set AlphaBlend effects for a group of sprites)
EZ_SetSpritesFrame (Set current Frame for a group of sprites)
EZ_SetSpritesFlip (Set Flip state for a group of sprites)
EZ_DefSpriteByPict (Create a new Sprite using a Bitmap)
EZ_GetSpriteXY (Get X,Y coordinates of a sprite)
EZ_GetSpriteWH (Get a sprites width and height)
EZ_GetSpriteFR (Get a sprites current frame)
EZ_GetSpriteST (Get a sprites current state, Show/Hide, Effect, Flip))
EZ_TestSpriteColl (Test for collisions between a sprite and other sprites)
EZ_TestSpriteClick (test for top most sprite under a click coordinate)
EZ_CloneSprite (clone an existing sprite)

Support Commands:

EZ_UpdateBKGND (Force control to redraw itself internally)
EZ_GetBitmapSize (Get size of a Bitmap)
EZ_FreeBitmap (Free a Bitmap)
EZ_UpdateClient (Force control to update client area based on current paint region)
EZ_UpdateClientAll (force control to update entire client area)

The sprite engine will work with basically any type of static (fixed image) control, such as the DDT label, Image (picture) and Graphic controls.
If you use the engine with SDK style coding, you need to use a control which you can change its background and it must support the WM_PRINTCLIENT message.

This version will support up to 200 Sprites.




EZSprite Plus 1.0 can be used with either DDT or SDK style coding and it adds extra support for SDK style coding. For example, you can convert a simple STATIC control into something even more powerful, to create your own custom Graphic control.

It will support all the commands in EZSprite Lite, plus also add the following commands:

Additional Sprite commands for Fast Sprite mode access:
(these commands can speed up sprite updates as much as 20% when many sprites are used)

EZ_GetFastSPIndex (Get Fast Sprite access index pointer)
EZ_MoveSP (Move sprite using index pointer)
EZ_SetSPAttr (set sprite attributes, show/hide,effect, flip, frame using index pointer)

Additional commands for custom painting a control such as a STATIC control:

EZ_DefNextCustomPaint (hook into controls WM_PRINTCLIENT and WM_PAINT)
EZ_StartDCDraw (start a DC draw cycle for custom paint)
EZ_EndDCDraw (end DC draw cycle for custom paint)
EZ_DefStyles (define current brush and pen styles)
EZ_BeginBrush (define current brush)
EZ_BeginBmpBrush (define current brush using a bitmap)
EZ_EndBrush (end current brush)
EZ_BeginPen (define current pen)
EZ_EndPen (end current pen)

Additional Bitmap commands:

EZ_Create32BitDIB (create a 32 bit DIB Bitmap and get address pointer)
EZ_StartBitmapDraw (prepare a Bitmap to be drawn on)
EZ_EndBitmapDraw (end drawing on bitmap)
EZ_DrawBitmap (draw a bitmap into a DC)
EZ_DrawGradient (draw a gradient into a DC)
EZ_LoadBitmapFile (load a bitmap from a file)

Additional Precision Timer and Frame Timing commands:

EZ_GetPTime (get current precision timer)
EZ_StartFrame (start timing a Frame for animation)
EZ_EndFrame (end current frame and wait until time up)
EZ_GetFrameInfo (get info about last frame)

Additional DoEvent commands:

EZ_DefDoEventCallback (define callback for EZ_EndFrame)
EZ_DoEvents (DoEvent replacement)

This version will support up to 1000 (one thousand) sprites.

If you code using the SDK style of coding, the PLUS version is recommended, but you can use the Lite version if you wish.

[Chris Boss]

If you are wondering ....

The EZSprite Lite DLL is only:

38 KB

in size.

The EZSPrite Plus DLL is only:

47 KB

in size.

Both versions use a proprietary sprite engine and do not use or require DirectX, OpenGL or GDI+.

It should work on any version of Windows from 95 to Windows 7.

So far it has been tested on XP Home and Vista Home Premium (64 bit) without any problem.

When I get a chance I'll do some tests on Windows 95. It should work though, since the core sprite engine came from EZGUI 4.0 Pro and it worked in 95 and up.

For those who are interested, here is the current draft of the software license:

http://cwsof.com/ezsplic.txt

Here is a previous demo of the sprite (old version, but you will get the point from it):

http://cwsof.com/ezsprite.zip (865 KB zip file)

[Chris Boss]

Some more details on this Sprite engine:

Sprites can be multiple frames so you can flip through the frames for creating animation. You can have to 100 frames in a sprite.

There is no limit on the size of a sprite.

You can define a single transparent color for the sprite to make specific pixels (that color) transparent. This means the sprite can be non-rectangular in nature.

Sprites can be flipped Horizontally and/or Vertically.

Sprites can be alphablended (to the background and other sprites). This means a sprite can be semi-transparent. You set an effect value of 0 to 100.

0 means the sprite is solid (no alphablending)
1 is nearly totally transparent and 100 is totally solid.
You can define the effect from 1 to 100 for any degree of transparency.
This can be changed dynamically at runtime.

Sprites can have their edges anti-aliased. You can define an anti-alias value when you create the sprite.

Sprites are not something just for games.

They can be used for all sorts of graphic animations for business.

Gaming usually is best left to things like 2D and 3D DirectX for the best results.

EZSprite alllows you to create animations for business/home style apps which don't require a lot of hardware power, so they run on any machine. Simple games also can be created using EZSprite as well (please read the software license noted above, since it does have some restrictions specific to games).

For a software based sprite engine, not using any of the hardware features of DirectX capable video cards, it is quite fast.

[Brice Manuel]

Additional Sprite commands for Fast Sprite mode access:
(these commands can speed up sprite updates as much as 20% when many sprites are used)

EZ_GetFastSPIndex (Get Fast Sprite access index pointer)
EZ_MoveSP (Move sprite using index pointer)
EZ_SetSPAttr (set sprite attributes, show/hide,effect, flip, frame using index pointer)

Is there any chance you would consider a version of the basic engine that had these commands included?

This version will support up to 200 Sprites.

Is there any chance you would consider a version of the basic engine that did not have this drastic limitation?

[Chris Boss]

Yes, I am willing to rethink this.

I do need to differentiate between the lower cost product and the more expensive one.

Do you think the rest of the extra command set is enough to differentiate the two ?

What do you think the minimum sprite number should be for the lower cost version ?

[Brice Manuel]

Do you think the rest of the extra command set is enough to differentiate the two ?

To be honest, no.

How about this...

Both versions have 1000 sprites and both versions have the fast sprite-indexing commands. (I am literally begging you on this)

The Plus version (which is mainly aimed at SDKers) you put back in the turtle graphics commands I kind of nixed earlier, but that was before you had two versions. For SDKers, the turtle graphics commands would be a huge benefit and it would make the plus version capable of being used for a variety of purposes.

What do you think?

[Chris Boss]

Yes, the Turtle Graphics would be more useful to SDK style programmers.

Thats a good idea.

Brice, what is the bare minimum that you would require for the # of sprites ?

[Brice Manuel]

Brice, what is the bare minimum that you would require for the # of sprites ?

Many of my games are turn-based and really would be pushing 1,000 sprites.

Perhaps you could make the high-end version have unlimited sprites?

[Chris Boss]

Brice,

Now you know, the sprite engine can free sprites when not needed and reuse the slot for new sprites.

Also, a single sprite can be used for multiple sprites if only one need be displayed at a time.

For example, a sprite could have multiple sprite frames loaded, for example say 5 frames for one sprite image, 5 frames for another, etc. Then when displayed, that one sprite could use the first 5 frames and animate, then you could switch to the other five frames and animate and so on. As long as you didn't need two different sprite images at the same time for that one sprite, that one sprite could can be used for different looking sprites.

Let' say in one session all the sprites need to look like a flying bird (ie. 5 frames) and then in a totally different session you need all the sprites to look like a walking dog (ie. 5 frames). As long as they are different sessions in a game, the same sprites could be used for both. Both the bird and dog frames could be loaded into the same sprites. Then when animating, you could flip through just the bird frames for the birds and then in a different sesion flip through the dog frames.

1000 sprites is a lot of sprites to have on the screen at one time.

Do you really need that many at one time ?

[Brice Manuel]

Please do not lecture me on how games are made

1000 is not really a lot of sprites to have on the screen at one time. You are forgetting a crucial part of a game, (especially turn-based) and that is the HUD, and GUI system.

I could live with 500 if I had to.

But, perhaps it is time to roll my own. There might be a need in the community for a good sprite engine that is actually written by a game programmer.

[Tom Hanlin]

Yeah... no. Actually, 1000 is more than a lot of sprites to have running at one time. You might want to review your design.

But more libraries are always very welcome. Go for it.

[Brice Manuel]

Yeah... no. Actually, 1000 is more than a lot of sprites to have running at one time.

This isn't the DOS days 1000 isn't much at all. Heck, a particle system would exceed 1000 at once, easily

[Chris Boss]

Brice, I apologize

I do appreciate your experience as a developer.
I am not a gamer myself, so I have no concept of how many sprites the average game developer may use.

The original purpose for my sprite engine (in EZGUI 4.0 Pro) was for primarily business uses, not games and a few hundred sprites would normally be plenty.

Now that I am doing some extensive benchmarking and finding ways to increase the speed, it may be possible to handle sprites in the thousands.


I just may increase the maximum limit on both products.

My concern was giving the user an excessive number of sprites when a software based engine is limited in speed, would be counter productive. Yes, I can run 1000 sprites, albeit slowly.

I did some more testing today and I found that my sprite engine had a bottleneck. Dirty Rectangles work great on a limited number of sprites, but when you start using 100's of sprites, Windows bogs down on BitBlt when using regions.

By allowing the user to turn on and off the dirty rectangle engine (when off you have to force a redraw of the entire client area) I have been able to get a 50% increase in speed.

For example, animating 1000 (one thousand) penquin sprites (100 x 100 pixel sprites, 12 frames) on my XP system I got:

4.1 FPS (dirty rectangles ON, anti-aliasing ON)
6.8 FPS (dirty rectangles OFF, anti-aliasing OFF)

On my Vista Home Premium PC I got for 1000 sprites:

5.7 FPS (dirty rectangles ON, anti-aliasing ON)
8.1 FPS (dirty rectangles OFF, anti-aliasing OFF)

Where I noticed the bottleneck is when I used smaller sprites. In theory, smaller sprites should be faster since there is less to draw. In reality, dirty rectangles slows Windows down (invalidating multiple rectangles).

To demonstrate see what happens when I use 2000 penguin sprites which are smaller , 25% of original (50 x 50 pixels):

2000 penguin sprites (50 x 50 pixels) on XP Home:

2.2 FPS - Dirty Rectangles and Anti-Alias
6.2 FPS - Anti-alias (no dirty rectangles) 300% speed improvement
11.2 FPS - No anti-alias, no dirty rectangles) 500% speed improvement

[Brice Manuel]

Brice, I apologize

Don't apologize, I am not mad, I was being facetious

I am not a gamer myself, so I have no concept of how many sprites the average game developer may use.

It really depends on the game, the style of the game and the genre of the game.

Yes, I can run 1000 sprites, albeit slowly.

For most of what I would use your sprite engine for, this would be perfect. I really prefer turn-based strategy games. There may be a huge number of sprites, but they are rarely moving, and only a few animations would be going on. You are not really bouncing the sprites around the screen.

The games where I do have sprites bouncing around are usually retro-styled and do not have a large number of sprites, so they are not as "intensive".

Dirty Rectangles work great on a limited number of sprites, but when you start using 100's of sprites, Windows bogs down on BitBlt when using regions.

Back when I used to use DirectDraw, I would make wide use of dirty rectangles, but I would run into what you describe. DirectDraw was normally double-buffered. It had triple-buffering, but few video cards properly supported it. I ended up writing my own triple-buffering routines and my own alpha-blending routines.

You would get to a point where say 1,000 moving alpha-blended sprites would bring it down to 30 FPS, but with triple-buffering, I could hit around 5,000 moving alpha-blended sprites and have an FPS of 17-23.

I would be curious to see with your sprite-engine what would happen if you changed the method of handling the transparent color for a sprite. I would be curious to see what would happen if instead of creating a mask and bitblt-ing the image, you used transparentblt on the image. With another language when I was messing with a nonDX sprite engine, I was able to blit 60,000 to 80,000 images per second on two different XP machines. Much, much faster than masking and bitblt-ing the images.

But as I mentioned via email, transparentblt would not work on '95 and it will work on '98, but it has a memory leak on '98 that I don't think MS ever fixed for '98.

[Brice Manuel]

Chris, i agre with Brice, a very good example of intensive sprite use is Touhou

That image (and video) is of a 3D game. 2D is actually being emulated via 3D methods.

The DX9 based "2D" engine I have been working on would be capable of that. It currently has 45 commands and weighs in at a whopping 26kb

[Patrice Terrier]

Again i would not compare apple and orange.

However if you need a FREE game library, why don't you try the excellent TBGL written in PowerBASIC by Petr Schreiber:
http://psch.thinbasic.com/

...

[Brice Manuel]

Again i would not compare apple and orange.

However if you need a FREE game library, why don't you try the excellent TBGL written in PowerBASIC by Petr Schreiber:
http://psch.thinbasic.com/

...

Just curious who your suggestion was aimed at?

[Vincent van der Leun]

I am currently using the "older" 1.2.xx version of SDL to write a 2D-based gaming engine in PBWin9 and am progressing quite nicely. I believe the stable 1.2 version uses, like EZSprite, normal GDI for recent versions of its Windows version (I'm quite sure older versions used the now-deprecated DirectDraw feature of DirectX). Of course I use the wrapper made by Jose and available on his site.

I tried to make my graphic classes somewhat generic, so I can optionally support both SDL1.2 and SDL 1.3 when SDL 1.3 is finished (which will make use of 3D-accelerator graphics for systems that support it!). Only time will tell if my classes were designed generic enough of course!

It would be interesting to see if I can add support for your EZSprite library, at least it would be an exercise to me to support for multiple libraries and I think I could use it for some code-testing beside my current project (so I have use for it when it does not work out in my current project). I would be willing to pay for the standard version at this time only though.

Some things that I would really need in a sprite system is the following:

• Write-access to raw pixel data, even after loading a sprite from a file
• Transparancy for sprites
• Basic resizing (stretch) routines would be more than welcome
• Same applies to features like horizontal mirroring of sprites, though the last three items of this list are not strictly necessary when we have access to the raw pixels.

I know I'm asking quite much, but thought you'd may be interested in my requirements.

Good luck with your products (and your car of course!)

[Chris Boss]

• Write-access to raw pixel data, even after loading a sprite from a file

I could add this if required. The sprites are stored in DIB's so I could make the DIB handle data pointer available if need be. Currently I don't give direct access to the DIB.

• Transparancy for sprites

You define a transparent color (RGB) and that color is transparent when the sprite is drawn.

• Basic resizing (stretch) routines would be more than welcome

Currently there is no resizing.

• Same applies to features like horizontal mirroring of sprites, though the last three items of this list are not strictly necessary when we have access to the raw pixels.

EZSprite can flip (mirror) the sprite either (or both) vertically or horizontally.

EZSprite was designed to display as fast as possible, so it does as little as possible dynamically. For example anti-aliasing is calculated when the sprite is created and not when drawn. The DIB stores the anti-alias data so the sprite simply draws it when displayed.