Sprite Pack Development Log

SPRITE PACK
DEVELOPMENT LOG

I should really have done this from the beginning...

Major Release v3.0
May 1, 2006 Discussion and Tutorial.

Version 3.0
Feb 22, 2006: Within 2 weeks
Version 3.0 is being integrated into z88dk. The Spectrum port will be first, followed by Timex ports. Once a few games are written with the new library I will be looking at a couple of z80 ports to other machines.

The sprite pack library has been broken into its logically independent pieces as it has been added to z88dk, making the platform independent parts available to all ports and the platform dependent parts available as optional compiles using the relevant makefile.

For the sprite engine in particular there are a number of changes that will make it faster, hopefully in the range of 20-30% faster but I won't know for sure until it is complete. Here's an informal list of changes:

- The display surface can be any rectangular size measured in character coordinates. Each character of the rectangular surface can be mapped to any character cell on screen. This is a side-effect of efforts to speed up the engine without changing the fundamental display algorithm, but makes for some interesting potential.

- The chars making up a sprite have associated with them a sprite draw function, with a richer choice besides the usual mask, or, xor and load. Sprite definitions can be 1 byte or 2 byte (the latter containing mask and graphic pairs as in v2.2) but chars can also be drawn with graphics rotated in from the left only or using graphics in the char and ignoring those rotated in from the left. The former variation is good for sprite chars on the right edge of the sprite and the latter for sprite chars on the left edge of the sprite. This eliminates the requirement to have that extra blank column definition on the right of rotated sprites and at the same time speeds up sprite draw significantly.

- Sprite colours are now masked. This means sprites can be ink only (not affecting background paper) or paper only (not affecting background ink), for example. A ColourSprite function has also been added that will quickly copy attr masks+attrs into a sprite from an array. Hopefully this will help with the colour clash issue, giving an easy way to change sprite colours depending on pixel position.

- In v2.2 code for drawing all sorts of sprite char types was always included in the final compiled binary. This will change in v3.0, meaning compiled binaries will be much smaller. Unfortunately this improvement is more than offset by a much larger memory requirement for "struct sp1_CS" and "struct sp1_SS" (at about 22 bytes each) and a much larger display list structure (at 6912 bytes for 32x24 display versus 3072 bytes in v2.2). I decided the gains in speed were worth the larger net memory hit. Because of this I am considering a second version using 16x16 pixel tiles as opposed to the usual 8x8 pixel tiles. This would reduce memory usage for these structures to 25% size.

- The draw order of chars needing update is changing. In v2.2, draw order was top to bottom, left to right. Now chars will be drawn in sprite order -- sprites needing update will be completely drawn before moving to the next sprite. Background chars will be drawn last. To enable this to happen, the order that sprites are moved and background drawn does matter: what is drawn first is updated first. Your code should move sprites first then draw background tiles to allow this new update sequence to occur.

- For all new library files, more control is being given to the programmer to set the memory map. No static variables will be compiled as part of the binary any longer -- you will need to include a global definitions file into your main.c to place the data structures required by the libraries at any point in memory of your choosing, subject to some constraints.

The API is very similar to v2.2 with some functions changing parameters but the fundamental way things work isn't changing much. The tutorial will still be useful. Hopefully the net result will be something quicker but retaining the ease-of-use property of the library.

Bug Fixes
September 27, 2003 sp_PutTiles() and sp_GetTiles() were fixed. Three new commands were added: sp_JoyTimexEither() to read both TS2068 joysticks and OR the result, sp_inp() to read an i/o port and sp_outp() to write to an i/o port.

Major Release V2.2
September 8, 2003 V2.2 has several core subroutines rewritten to support windows in a future version. A side effect is that background tiles now separate colour and graphics information, which is what should have been done from square one. Some of the Huffman routines were debugged and several new background tile commands were added. The most interesting one is probably "sp_PrintString()" which prints a string within a bounded rectangle optionally using embedded commands that allow loops, changing coordinates, changing colours, etc. As usual, bugs may exist and the most likely functions to contain them are the new ones. There is now a tutorial that covers most of the functions in V2.2.

Major Release v3.0 May 1, 2006	Discussion and Tutorial.
Version 3.0 Feb 22, 2006: Within 2 weeks	Version 3.0 is being integrated into z88dk. The Spectrum port will be first, followed by Timex ports. Once a few games are written with the new library I will be looking at a couple of z80 ports to other machines. The sprite pack library has been broken into its logically independent pieces as it has been added to z88dk, making the platform independent parts available to all ports and the platform dependent parts available as optional compiles using the relevant makefile. For the sprite engine in particular there are a number of changes that will make it faster, hopefully in the range of 20-30% faster but I won't know for sure until it is complete. Here's an informal list of changes: - The display surface can be any rectangular size measured in character coordinates. Each character of the rectangular surface can be mapped to any character cell on screen. This is a side-effect of efforts to speed up the engine without changing the fundamental display algorithm, but makes for some interesting potential. - The chars making up a sprite have associated with them a sprite draw function, with a richer choice besides the usual mask, or, xor and load. Sprite definitions can be 1 byte or 2 byte (the latter containing mask and graphic pairs as in v2.2) but chars can also be drawn with graphics rotated in from the left only or using graphics in the char and ignoring those rotated in from the left. The former variation is good for sprite chars on the right edge of the sprite and the latter for sprite chars on the left edge of the sprite. This eliminates the requirement to have that extra blank column definition on the right of rotated sprites and at the same time speeds up sprite draw significantly. - Sprite colours are now masked. This means sprites can be ink only (not affecting background paper) or paper only (not affecting background ink), for example. A ColourSprite function has also been added that will quickly copy attr masks+attrs into a sprite from an array. Hopefully this will help with the colour clash issue, giving an easy way to change sprite colours depending on pixel position. - In v2.2 code for drawing all sorts of sprite char types was always included in the final compiled binary. This will change in v3.0, meaning compiled binaries will be much smaller. Unfortunately this improvement is more than offset by a much larger memory requirement for "struct sp1_CS" and "struct sp1_SS" (at about 22 bytes each) and a much larger display list structure (at 6912 bytes for 32x24 display versus 3072 bytes in v2.2). I decided the gains in speed were worth the larger net memory hit. Because of this I am considering a second version using 16x16 pixel tiles as opposed to the usual 8x8 pixel tiles. This would reduce memory usage for these structures to 25% size. - The draw order of chars needing update is changing. In v2.2, draw order was top to bottom, left to right. Now chars will be drawn in sprite order -- sprites needing update will be completely drawn before moving to the next sprite. Background chars will be drawn last. To enable this to happen, the order that sprites are moved and background drawn does matter: what is drawn first is updated first. Your code should move sprites first then draw background tiles to allow this new update sequence to occur. - For all new library files, more control is being given to the programmer to set the memory map. No static variables will be compiled as part of the binary any longer -- you will need to include a global definitions file into your main.c to place the data structures required by the libraries at any point in memory of your choosing, subject to some constraints. The API is very similar to v2.2 with some functions changing parameters but the fundamental way things work isn't changing much. The tutorial will still be useful. Hopefully the net result will be something quicker but retaining the ease-of-use property of the library.
Bug Fixes September 27, 2003	sp_PutTiles() and sp_GetTiles() were fixed. Three new commands were added: sp_JoyTimexEither() to read both TS2068 joysticks and OR the result, sp_inp() to read an i/o port and sp_outp() to write to an i/o port.
Major Release V2.2 September 8, 2003	V2.2 has several core subroutines rewritten to support windows in a future version. A side effect is that background tiles now separate colour and graphics information, which is what should have been done from square one. Some of the Huffman routines were debugged and several new background tile commands were added. The most interesting one is probably "sp_PrintString()" which prints a string within a bounded rectangle optionally using embedded commands that allow loops, changing coordinates, changing colours, etc. As usual, bugs may exist and the most likely functions to contain them are the new ones. There is now a tutorial that covers most of the functions in V2.2.