Well, I generally try to avoid directly comparing my systems to other people's offerings, but YOU LEAVE ME NO
ALTERNATIVE! :-)
Of course this is just asking for the creator of Zsprite to refute some of my claims and
point out flaws in my own system, but c'est la ve... whatever that means. :-)
There's lots of reasons to choose my system over Zsprite. For example, Zsprite has lots of documentation and
demos, but my system is much easier to use.
Here are some other reasons to choose my system over Zsprite:
Creating sprites:
-----------------
With Zsprite, you have to call a special function to load your images, which it calls "resources". You then have to
create a set of "layers". Each "layer" can only have one type of sprite in it. Once you've done that, you can add
sprites to the appropriate layers. Then if you want to change the order of stuff around you've got all these functions
for swapping layers and moving them to the front or back.
Does that sound simple to you?
My system is much simpler. With my system you just load images like you normally would. Then you create sprites, and
set the order they should draw in. Easy peasy.
Collisions:
-----------
With Zsprite, you literally have 15 different functions for determining collisions. Why so many? I have no idea.
With my system you have two collision functions: Pixel perfect sprite vs sprite, and pixel perfect sprite vs rect.
I coded an entire game for Lego using just these two collision functions and they served me quite well.
ZSprite does have the ability to call a function when a collision is detected automatically, and that's a useful feature.
So it gets a point there, but I wouldn't be surprised if I implement a similar feature in my own system in the not too
distant future. :-)
Updating:
---------
With Zsprite, you have to zsSystenBegin and zsSystemEnd at the beginning and end of your main loop AND call the update
function in the middle.
With my system you only have to call the functon to update the animation, and draw the sprites.
Also, with my system you specify the time which has passed. With ZSprite, I don't see a time passed parameter which you
pass to the update function, so I have to assume it is using millisecs to keep track of time itself. While this might
make things simpler initially, it doesn't make them much simpler, and you will probably find that you need to be able to
slow down or pause the animation of the sprites at some point. What if you alt-tab out of your app? Time, or in this
case, millisecs(), waits for no one! With my system you can detect those conditions and skip adding time to the game
timer when the frame time was over a second. With ZSprite, you're out of luck.
Effects:
--------
ZSprite has lots of effects. It has some my system doesn't. Like making a sprite blink, or shake.
But my system also has lots of effects. Like the ability to move sprites along a path, or make them move in a sine wave
pattern. Or make them move from one place to another with acceleration and deceleration.
And my system allows you to make ANY effect play one-shot, looped, or ping pong, in both forward and reverse.
ZSprite on the other hand only allows one-shot loop and ping pong with frame animation, and does not support playing
animations in reverse. Most if not all of the other effects it has support only one-shot animation.
Wouldn't you trade the ability to shake a sprite for the ability to play animations in reverse, and the ability to
continuously animate almost any sprite property?
My function names also make more sense. Compare "zsEffectRotateTo" to "Animate.Rotation" for example.
Single surface rendering:
-------------------------
Sounds nice on paper, but is unlikely to speed up most sprite based games, and requires you to deal with nasty things
like resources and layers and "preparing open gl contexts".
Fonts:
------
No font support in my system yet, but there will be, and you'll probably be able to animate the individual letters in
neat ways.
"Geometry Objects":
-------------------
A fancy term for 2D polygons. Are polygons all that useful in a 2D game? Perhaps in a few limited scenarios, but
otherwise, not really.
Now let's talk about what my system does that ZSprite doesn't do:
-----------------------------------------------------------------
Create paths for moving sprites along. Move sprite on X axis, it moves along path. Move sprite on Y axis, it moves
perpendicular to path.
Parenting. Extremely useful. Create a menu background, then put buttons on it. The buttons are children of the menu.
They are in menu space. When the menu moves, the buttons move with it. When the menu rotates, the buttons rotate with
it. When the menu is hidden, the buttons hide with it. And you can select certain attributes the children won't pick
up on. For example, you can make it so the children DON'T rotate with the parent when it rotates, but they move when it
moves, or rotates, or scales, because their position is still relative to parent space.
TFormPoint, TFormVector, TFormNormal. Really useful math functions that allow you to easily do things like determine if
a sprite is in a 45 degree arc in "front" of another sprite which is rotated, and then have that sprite apply thrust in
the correct direction because you can just pass a vector in the sprite's space that points forwards to the TFormVector
function and transform it into global space for your physics code.
Shadows. Cast a drop shadow from any sprite. No extra images required. One command, three parameters, bada bing, bada
boom, shadow!
Renderstate storage and restoration on a stack. Sprite system won't change what color you set. It saves all those
render parameters before it goes to work, and restores them after. And you can use those functions too.
Anyway I'll just wrap this up with this:
----------------------------------------
I wrote the original version of this system in Blitzplus, and used it to make Lego Builder Bots. When I ported it to
Blitmax, I made it 10x better. So I know I've got a rock solid design, and that if you use it you will be pleasantly
surprised at how often you need a particular feature, and find the system already supports it.
ALTERNATIVE! :-)
Of course this is just asking for the creator of Zsprite to refute some of my claims and
point out flaws in my own system, but c'est la ve... whatever that means. :-)
There's lots of reasons to choose my system over Zsprite. For example, Zsprite has lots of documentation and
demos, but my system is much easier to use.
Here are some other reasons to choose my system over Zsprite:
Creating sprites:
-----------------
With Zsprite, you have to call a special function to load your images, which it calls "resources". You then have to
create a set of "layers". Each "layer" can only have one type of sprite in it. Once you've done that, you can add
sprites to the appropriate layers. Then if you want to change the order of stuff around you've got all these functions
for swapping layers and moving them to the front or back.
Does that sound simple to you?
My system is much simpler. With my system you just load images like you normally would. Then you create sprites, and
set the order they should draw in. Easy peasy.
Collisions:
-----------
With Zsprite, you literally have 15 different functions for determining collisions. Why so many? I have no idea.
With my system you have two collision functions: Pixel perfect sprite vs sprite, and pixel perfect sprite vs rect.
I coded an entire game for Lego using just these two collision functions and they served me quite well.
ZSprite does have the ability to call a function when a collision is detected automatically, and that's a useful feature.
So it gets a point there, but I wouldn't be surprised if I implement a similar feature in my own system in the not too
distant future. :-)
Updating:
---------
With Zsprite, you have to zsSystenBegin and zsSystemEnd at the beginning and end of your main loop AND call the update
function in the middle.
With my system you only have to call the functon to update the animation, and draw the sprites.
Also, with my system you specify the time which has passed. With ZSprite, I don't see a time passed parameter which you
pass to the update function, so I have to assume it is using millisecs to keep track of time itself. While this might
make things simpler initially, it doesn't make them much simpler, and you will probably find that you need to be able to
slow down or pause the animation of the sprites at some point. What if you alt-tab out of your app? Time, or in this
case, millisecs(), waits for no one! With my system you can detect those conditions and skip adding time to the game
timer when the frame time was over a second. With ZSprite, you're out of luck.
Effects:
--------
ZSprite has lots of effects. It has some my system doesn't. Like making a sprite blink, or shake.
But my system also has lots of effects. Like the ability to move sprites along a path, or make them move in a sine wave
pattern. Or make them move from one place to another with acceleration and deceleration.
And my system allows you to make ANY effect play one-shot, looped, or ping pong, in both forward and reverse.
ZSprite on the other hand only allows one-shot loop and ping pong with frame animation, and does not support playing
animations in reverse. Most if not all of the other effects it has support only one-shot animation.
Wouldn't you trade the ability to shake a sprite for the ability to play animations in reverse, and the ability to
continuously animate almost any sprite property?
My function names also make more sense. Compare "zsEffectRotateTo" to "Animate.Rotation" for example.
Single surface rendering:
-------------------------
Sounds nice on paper, but is unlikely to speed up most sprite based games, and requires you to deal with nasty things
like resources and layers and "preparing open gl contexts".
Fonts:
------
No font support in my system yet, but there will be, and you'll probably be able to animate the individual letters in
neat ways.
"Geometry Objects":
-------------------
A fancy term for 2D polygons. Are polygons all that useful in a 2D game? Perhaps in a few limited scenarios, but
otherwise, not really.
Now let's talk about what my system does that ZSprite doesn't do:
-----------------------------------------------------------------
Create paths for moving sprites along. Move sprite on X axis, it moves along path. Move sprite on Y axis, it moves
perpendicular to path.
Parenting. Extremely useful. Create a menu background, then put buttons on it. The buttons are children of the menu.
They are in menu space. When the menu moves, the buttons move with it. When the menu rotates, the buttons rotate with
it. When the menu is hidden, the buttons hide with it. And you can select certain attributes the children won't pick
up on. For example, you can make it so the children DON'T rotate with the parent when it rotates, but they move when it
moves, or rotates, or scales, because their position is still relative to parent space.
TFormPoint, TFormVector, TFormNormal. Really useful math functions that allow you to easily do things like determine if
a sprite is in a 45 degree arc in "front" of another sprite which is rotated, and then have that sprite apply thrust in
the correct direction because you can just pass a vector in the sprite's space that points forwards to the TFormVector
function and transform it into global space for your physics code.
Shadows. Cast a drop shadow from any sprite. No extra images required. One command, three parameters, bada bing, bada
boom, shadow!
Renderstate storage and restoration on a stack. Sprite system won't change what color you set. It saves all those
render parameters before it goes to work, and restores them after. And you can use those functions too.
Anyway I'll just wrap this up with this:
----------------------------------------
I wrote the original version of this system in Blitzplus, and used it to make Lego Builder Bots. When I ported it to
Blitmax, I made it 10x better. So I know I've got a rock solid design, and that if you use it you will be pleasantly
surprised at how often you need a particular feature, and find the system already supports it.