+- Discussion Forum for all things Microbee (https://microbeetechnology.com.au/forum)
+-- Forum: Microbee Forum (https://microbeetechnology.com.au/forum/forum-1.html)
+--- Forum: Microbee Software and Documentation (https://microbeetechnology.com.au/forum/forum-7.html)
+--- Thread: Sprites (/thread-547.html)
Sprites - Under4Mhz - 10-08-2022
Any hints on how to make sprites?
So far, I've taken a copy of existing tiles and drawn my sprite on top if it. For the moment, I invert the entire tile to make a pointer since this was simplest and the game didn't really need distinct sprites.
To move the sprite around on a pixel level, I'd need to copy the existing tile data to new tiles, and shift the pixels around on those tiles.
For single direction sprites (vertical and horizontal, like Pacman), I'd need three tiles for a 16x16 sprite, assuming the sprites always align to an 8 pixels position. For omni directional sprites I'd need 6 tiles for a 16x16 sprite.
RE: Sprites - someone - 10-08-2022
Someone built a TMS9118 VDP expansion module for the microbee the early 1980's to play with sprites & colour graphics. It was relatively expensive but fun to do.
Sprites - These were invented by Karl Guttag with the Texas Instruments TMS9918 VDP.
Here's a video of the man himself!
RE: Sprites - MikeCornflake - 10-08-2022
I know nothing about sprite programming, so can't help directly. But, because the world is a small place, today I stumbled across a Z80 development kit that has both sprite support and Microbee support (I'm thinking this just means it knows about the different graphic modes).
https://www.z88dk.org/forum/index.php
But I'm also intrigued: Sounds like you're doing all your sprite handling yourself? Pointer to image and all that. Or am I misreading, and there's some hardware support for sprites in the Bee?
RE: Sprites - someone - 10-08-2022
Various methods of software bit bashing exist for the microbee to handle animated objects; unfortunately they consume a fair bit of CPU processing thus relatively slow particularly if collision logic is required.
The simplest method is just to use objects at the character grid level. It has a coarse granularity but is relatively simple & is fastest. (e.g. Chess)
It's when a finer granularities are required that things become more complex.
The next simplest is to use LORES graphic characters - this improves the granularity 2x horizontally and 3x vertically. (e.g. ported TRS80 games)
A trick is change the LORES pixel blocks into common mini 4x4 grid chars. e.g. rounded balls or rings.
The technique mentioned by Under4MHz is what is done for some existing microbee software for GUI style mouse pointers.
Some PCG chars are reserved for use as the cursor object (aka "sprite") and its composition is made up from an object matte - a bitmap mask that defines the cursor shape's opacity and the cursor's pixel bitmap definition. What's done is that the chars at the cursor position are copied into the cursor's reserved PCG chars, then the matte is used to create a hole to place the cursor bitmap and then the cursors pixel bitmap definition is ORed in the hole made by the matte. The original characters where the cursor is to be placed is copied into a buffer so it can be restored into place after the cursor has moved away.
To handle pixel resolution movement, the number of PCGs reserved for the cursor object (grid) is extended by one char width (X + 1) and one character height (Y + 1) to handle cursor placements that don't fit wholly into the standard grid with the matte and bitmaps having to be shifted appropriately into the extra region.
Things get even more complex when there's more than one sprite where appropriate sprite priority control & collision handling are required.
(e.g. Mytek games such as Asteroids).
For Alpha plus and later machines PCGs are often laid out so that the screen becomes a fully addressable bitmapped canvas. This allows the setting and resetting of pixels to be done purely with PCG RAM writes. This is good for some things and not so good for others.