Objects

Generally speaking, 'objects' are things that are in the game world, but aren't cars or players. Specifically, in the current design, there are the following objects:

All objects are based around the same code, in objects.c, but each object type has its own unique properties that require code support.

Bullets

Bullets fly through the air in a straight line and do damage to the first object they hit. The game currently recognises several types of bullet:

Currently, bullets can only fly in a straight line, and not up or down slopes. However in the future they will be expanded to have a certain degree of ground-hugging ability, to allow the player (and other peds) to shoot at people up/down slopes.

Bullet ownership

Each bullet has an 'owner' field, which provides a pointer to the ped/car that fired the bullet. This is so that bullets do not impact with their owner, and so that the ped that the bullet hits will know who shot him. Callbacks in the ped and car deletion code are used to 'disown' any bullets that the ped/car fired, to ensure that rogue pointers are not left behind after the ped/car is deleted. To avoid pointless calls to the slow disown functions (as the whole object list is scanned each time), each ped/car has a count of how many bullets it owns (as maintained by the bullet code), so it knows whether a call is needed upon deletion.

Animations

Animations are non-collidable objects that sit still and animate. The animation can be repeating or once-only (after which the object will remove itself). The game will create some animation objects automatically, such as explosions or bullet impact animations.

Cones

Cones are collidable objects that can be pushed around by vehicles, and also run over by them. The primary purpose of a cone is to act as a traffic cone. Running over a cone in a vehicle will cause the vehicle to slow down, and the cone to be dragged along with the vehicle some distance. The cone also animates when moving.

Bollards

Bollards are collidable objects that don't move under any circumstances. They can play animations if required.

Meats

Meats are like bollards, in that they are collidable and immobile, but they can take damage. The use the animation frames (if any) to indicate how damaged they are; their intended purpose is to be used as destructible parts of scenery, such as machinery.

Dummies

Dummies are invisible, non-collidable, immobile objects. Their only purpose is to act as waypoints for AI.

Pickups

Pickups are bonuses for the player to collect - weapons, armour, health, extra lives, etc. They are immobile, and automatically give the appropriate item to the player once collected - thus the full range of pickups available is hard-coded at compile time. Pickup collection is currently performed in peds.c, and all pickups have a default 90 second respawn timer (Although this can be overriden by installing a TOUCH event handler on the player/pickup, and deleting the pickup after collection)

Skidmarks

Skidmarks (and any other long sprites) will be implemented as a new object type. These objects will contain, either directly or indirectly, a list of verticies, forming the path the skidmark takes. They will be rendered one segment at a time, by using a modified rotscale plotter - one that allows the specification of the number of sprite rows to plot (since the low-level rotscale plotter allows for coordinate wrapping). A suitable sprite size, e.g. 4x32, will be used, and by adjusting the number of plotted sprite rows it will be possible to expand or shrink it to any size.

Seperate code will manage the creation of skidmarks - most likely, each wheel in each car will have a skidmark struct ptr, that tracks the current state of the skidmark that is/isn't in production. The skidmark creation code will automatically create skidmark map objects, add segments as the direction of the car changes (or as it moves a certain distance away from the last mark), and start a new skidmark map object if the current object gets too large (i.e. bigger than 4 blocks in any direction) or if the surface type changes. The skidmark code may also be in charge of removing old skidmarks (either that or the objects will have built-in expiry timers that are tracked by the object code). To simplify the coding, these skid state structs will not be saved in savegames (thus allowing them to use hard pointers to skid map objects).

Skidmark objects may be detectable by mission scripts, and may be deletable, but are unlikely to be createable.

Object sprites

Object sprites should be 256 colour, palettised sprites. If the sprite is to be masked, then palette index 0 should not be used, as this is used for the mask colour when loaded by DeathDawn. Object sprites support fullbright palette entries, in a similar manner to tiles; however whereas tiles use the '^' character at the start of the sprite name to indicate fullbright support, fullbright support is enabled by default for all object sprites. This means that the first black palette entry will mark the end of the fullbright block (not counting entry 0 if the sprite has a mask). In particular, care must be taken if creating sprites with the standard 256 colour palette, as adding a mask will result in the entire sprite being rendered fullbright.

TODO:
MUST-CODE: QUICK: Support for custom pickups via specification of anim name (and specify trigger func there-and-then to keep code concise?) Useful for things like briefcase pickups, etc.
MUST-CODE: MED: Skidmark system, as above.
???
Profit!