-
Notifications
You must be signed in to change notification settings - Fork 0
SpriteMover
Sprite mover is an implementation of software sprites. The sprites support the following features.
- RGBA images of "any" size. (Images with a alpha or transparency channel)
- Animated sprites.
- Auto-movement.
- Collision detection.
- Effects.
All sprites are canvases in your browser. So in practice everything you can do with a canvas, you can do with a sprite.
Note: Please take regard of performance yourself. The more fancy effects, the more sprites on screen, and the larger the sprites, the harder the browser has to work to keep up. Test the limits, before publishing a game that only works on your browser and hardware.
There are 3 parts to the sprite mover library:
A sprite is just an object in JS. The sprite contains all properties needed for rendering, moving and collision detection.
In it's simplest form, it's an image, with an onscreen x and y position. However it also contains:
- dx/dy attributes. This makes it easier to move many sprites "automatically"
- Linkage. A sprites position can be linked to another sprites position.
- Boundary. A boundary box can be set to a sprite.
- Collision boxes. This makes it possible to see when two sprites "collide"
- Animations (a sequence of images)
- Display effects. Rotate, transparency and composite operator. Note: Some of these disable the possibility of collision detection.
This contains all the properties for rendering and moving.
- A canvas containing the image. (in RGBA format)
- The offset. Normally the offset is so, that when you draw a sprite on coords (x,y), the center of the sprite will be on coord(x,y). With the offset, you can change that behaviour.
- Collision boxes. To detect if sprites are collided.
This is the code that needs to be executed explicitly to move the sprite, detect collisions, and render sprites. Also it the class that contains the collection or set of sprites.
The mover has methods to manage the following actions:
- Managing the collection. Adding, removing and counting and "getting" sprites.
- Moving the sprites according to their delta x/y and boundary values.
- Detecting collision between sprites. An array will be returned with the sprites that collide. To determine what to do, you can examine the sprites "type" attribute. (example, a sprite player and a sprite bullet collide)
- Animating. Cycling the sprites that have animations instead of simple images.
- Rendering. Render the sprites onto a canvas.
For moving the sprite has x,y and dx and dy attributes.
Also it is having a boundary flag. When the sprite exists the boundary box, you can decide if the sprite bounces back, comes back on "the other side", or disapears.
Sprites are rendered based on the SpriteImage or SpriteAnim they point to. Collision detection also.
SpriteImage object contain a single RGBA image. For convenience, you can load any RGB image, and use a "background" color, to create a mask. The result will be a sprite that will only draw pixels that "are not" the background color. However you can have more "shades of transparency" in the loaded image. to have semi transparent pixels.
SpriteImage also uses collision boxes, to detect collisions between two sprites.
This is a speed optimization. However sprite images are hardly square. Bullets are round, cars are rectangular (ish), and dragons have, well, dragon shapes. So to make the collision accurate and speed optimal GAME1, enables the image to be divided up into boxes. So the accuracy becomes more. The top accuracy is one box per pixel, but this of course is very slow. So you can set the granularity of collision box, to something less granular. For example 4 pixels. Collision detection is a little complex, but GAME1, has 2 simple parameters to work with. CollisionBoxGranularity. This is just a single number. And enable-per-sprite collision detection. (smoke does not need to be detected in most cases, neither do 'particles')
SpriteAnim is more or less an array of SpriteImage. It uses each SpriteImage as a single frame of animation. The constructur of SpriteAnim allows for a gridw and gridh parameter. This basically "cuts" a single image into square parts. Each square part will be a SpriteImage or frame. Each frame has it's own collision boxes. So correct collision detection is maintained when using a SpriteAnim.
There is nothing that says you can have only one sprite mover object. You can use for example several SpriteMover objects, each containing a different set of sprites.
You can use this for:
- Optimization. Put all non colliding sprites in a different SpriteMover object. This way collision detection does not need to skip (for example) several 100 particle sprites for each frame.
- Depth. You can render for example first the SpriteMover that contains the "shadows", and then the one that contains the "players, enemies and bullets", and lastly you can render the clouds.
- Play fields. You could render one set of sprites on one play field, and another sets of sprites on a different "play field" canvas.