Hi all, I just wanted to give this list an update on the release status
of my SuperSpriteSurface framework:
I have almost finished implementing the collision detection [CD]
system. The CD system is very fast and robust: In addition to offering
functionality similar to the existing SpriteSurface control,
SuperSpriteSurface's system lets you dynamically assign multiple
collision shapes to your sprite's images. Collision shapes are not
limited to axis-aligned rectangles as they are in the current
SpriteSurface, but currently include circles, rectangles, convex
polygons & points that have the ability to be scaled and rotated along
with your sprites.
This CD system, when combined with the other features of the
SuperSpriteSurface framework: hardware accelerated drawing via OpenGL
(think: fast rotation, scaling of very large 24 bit images using 8 bit
alpha masks), threaded execution and a time based frame controller,
give REALbasic game developers a modern foundation on which to build
the Next Generation of 2d games.
The Demo
------------------------------------------
The links below point to a quick demo I put together for OS X &
Classic. Since this is a quick test, let me explain what it does:
Launch the demo:
Under the "Test" menu, choose "Collision Test". You will be prompted
enter the number of sprites you want to create and whether or not you
want to run the SuperSpriteSurface in a thread.
When the SuperSpriteSurface starts, n number of 64x64x32bit sprites are
created with either a collision rectangle or collision circle as their
currently active collision shape (although any number could be active
at once). These collision shapes will switch randomly as they scale,
rotate and move about the window. When a collision occurs, the
colliding sprites turn red (since the images are also translucent, you
can see the collision area.)
This test shows a worst case scenario situation: All sprites are
moving, rotating and scaling at the same time, are drawn in "smoothed"
mode, use transparency and are in an unrestricted collision set.
Give it a go and let me know what you think:
http://home.earthlink.net/~tinrocket/
SuperSpriteSurface_Collision_Prev.sit
http://home.earthlink.net/~tinrocket/
SuperSpriteSurface_Collision_Prev_OSX.sit
The CD System -- How it Works
------------------------------------------
I've also been making the collision system even easier to use. Here's a
quick rundown on how one would implement it using the framework:
The basic sprite class is called "SuperSprite". In order to animate or
illustrate a SuperSprite (object) in the SuperSpriteSurface (control),
one or a series of "SuperSpriteImage" instances are attached to a
parent SuperSprite object. The SuperSpriteImage class holds 1 picture
and n number of "collision shapes". Collision shapes (circle,
rectangle, convex polygon, etc.) are in turn attached to
SuperSpriteImage objects. Each collision bounds shape that is attached
to a SuperSpriteImage object is then assigned a "GroupName" by the
programmer, such as "Shield" or "Sword". This GroupName is later used
by the CD system to resolve collisions.
As we see, collision shapes are stored in the SuperSpriteImage objects
rather than the sprites themselves. Why? Would it not be easier to
define your collision shapes in your sprite just once? Well, No. This
is because as you change your sprite's Active Frame Image over time,
you may not want the collision shape to stay the same or even to remain
in the same place, especially if the collision shapes represents an
area of contact that is changing shape and position, such as a weapon
or shield.
At this point, an example how everything works together might be
illuminating: Let's say we have a SuperSprite object, our Sprite, that
represents a Knight. We also have a series of frames we've rendered
that we want to use to show the Knight running, jumping, etc.. We
create and store each of these frame images in our sprite as a series
of SuperSpriteImage objects, i.e., "jump_image", "run_image",
"stand_image".
In our example, let's decided that each of these SuperSpriteImage
instances will contain 2 collision shapes. For each SuperSpriteImage
object, these shapes are positioned over the appropriate part of each
image -- the Knight's shield & sword for instance-- and given
GroupNames: "Shield" (a circle), "Sword" (a convex polygon).
At, before (or even during) runtime, we will need to create an instance
of something called a "SuperSpriteCollisionChecker" object. This is the
actual object that will check for collision and dispatch collision
message. After it's created, we give this object a list of collision
GroupNames (as strings). For this example that would be "Shield" and
"Sword".
Finally, we append the SuperSpriteCollisionChecker instance to an array
property in the SuperSpriteSurface and tell the SuperSpriteSurface to
Run!
At runtime, the SuperSpriteSurface will resolve which collision shapes
need to be tested based on their GroupName. SuperSpriteCollisionChecker
is smart and will only use the collision shapes that are in a sprite's
Active Frame Image to perform the appropriate collision test.
If a collision occurs, each SuperSprite instance will receive a
collision event telling it which sprite it collided with it, which of
it's collision shapes was touched and which of the other sprite's
collision shapes was touched. Collision response -- what to do once a
collision is detected/determined, is now in the hands of you, the game
programmer.
What's Next
------------------------------------------
I am finishing up the implementation of some collision shape types:
Convex Polygon and Point, as well as implementing collision detection
for the SuperSprite subclass, "SuperSpriteTile" (which encompasses the
functionality of the current SpriteSurface's PaintTile events system).
I hope to release a public beta by the end of the Summer; I know that
some of you are very much looking forward to using this & I appreciate
your patience and encouragement. :)
Thank you,
John Balestrieri
http://www.tinrocket.com/content/superspritesurface/index.html
---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>
.
|