Bitmap animation

Basic and Machine Language

Moderator: Moderators

rhurst
Omega Star Commander
Posts: 1371
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Tech & Innovation

Post by rhurst »

If using smaller, fixed-size "sprites" (i.e., 8x8, 16x16, etc.), bounding box collision detection is perfectly acceptable. That is, simple subtraction of the object's X/Y from the target's X/Y, take the result's absolute value and if it is less than to the Height/Width, then return TRUE that the objects are "colliding". Having an object touch that is 7-pixels away suggests it is merely peeking into the character cell to see if a "non-empty" character code is occupying the same cell as the sprite -- that can suck in most cases. That method can be helpful to avoid color clash and/or trigger an event that suggests "when you are in proximity of", i.e., an Omega Fury fighter craft near a Thargoid hull blaster mine.

A bounding box algorithm allows for more object overlap to occur before triggering a "collision" or "capture" event, i.e., in Quikman, 4 or more pixels of overlap (X or Y) need to occur before Quikman is considered "grabbed" by a ghost.

If using a larger sprite (like Jupiter Lander), you probably want individual pixel collision detection for any part of the irregular-shaped ship that touches anything on the background for which it is rendering. That is efficiently computed using XOR logic... as the object's rasters are XOR'ed onto the background, simply read the value back... if the value is not equal to what was written, a collision has taken place. If the object and/or background is using multi-color, XOR will _probably_ not work as straightforward as single color. Then you will need to use a separate object copy as the mask value to determine if any bits collided -- much more expensive in both speed and size.

If you'd like some collaboration on your project, I am interested in expanding the software sprite stack to include working examples in BASIC and C (I am tinkering with paddles [PONG] and a trackball controller [Missile Command] in ca65 C compiler calling VIC-SSS4).

For real speed, VIC's BASIC 2.0 will likely require extended SYS calls to allow sprites to move independently of its game loop, with a special TRAP command that gets called if sprite's collide -- that's ambitious to write, but like C128 BASIC 7.0, not impossible to do.
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
Post Reply