Timmy wrote:When we first talked about sp1, there were talks about adding code on top of sp1 to do other things, like water reflections and stuff.
It's very likely I will end up doing a revisit from scratch rather than modifying anything but the to-do list is very long atm.
The simple alternative I can think of (if I don't want to mess with sp1) is to swap the sprite data before calling the sprite routines, but that would mean all sprites of that instance will be flipped all at once. So I'm wondering how this can be done.
If you're willing to have multiple sprite images in memory: one regular, one mirrored horizontally, one mirrored vertically, one mirrored vert & horiz, then you can choose among those individual images for each sprite by pointing the sprite's frame address at the base of one of those. You can do that by writing into the sprite structure directly:
Code: Select all
struct sp1_ss *s;
....
s->frame = man_hmirror;
The image will change at the next sprite move or if you can't wait for that, you can invalidate the sprite with "sp1_Invalidate(s);"
The same effect can be had in the sprite move functions by specifying a non-zero frame address.
You might be able to reduce memory requirements by generating those images from the unmodified one prior to each level, assuming you only need a portion of the sprites for a level.
But you're talking about modifying a single image to reverse it which would affect all sprites using that image so I suppose the extra memory required for multiple images is a problem.
But one thing I really would like to see is sprite flipping, like what they have on the NES, where you can specify a sprite to be drawn mirrored horizontally and/or vertically. This would save lots of sprite memory for something simple. (I do realise there would be a need for a left/right swapping table, but that's about 256 bytes.)
I'll give you a little background first before I make one possible suggestion.
The sprite image is stored in columns and the columns are usually one after the other in memory. So an image that is 2x2 chars in size is stored in memory as 3x3 without the last (blank column) to give the software shifter space to pixel shift the image. I assume here you want pixel precision horizontally and vertically (if you only want character positioning you can do away with the extra blank space).
Code: Select all
Image:
AC
BD
Sprite Image in Memory:
defb at least seven blank pixel rows ahead of the first column, possibly tail end of previous sprite image
;; FIRST COLUMN
imageA: defb eight pixel rows making up the character ;; offset 0
imageB: defb eight pixel rows making up the character ;; offset 8 or 16 if masks present
defb eight blank pixel rows ;; offset 16 or 32 if masks present
;; SECOND COLUMN
imageC: defb eight pixel rows making up the character ;; offset 24 or 48 if masks present
imageD: defb eight pixel rows making up the character ;; offset 32 or 64 if masks present
defb eight blank pixel rows ;; offset 40 or 80 if masks present
The sprite holding this 2x2 image is actually 3x3 in size and each character in that sprite is described by a struct_sp1_cs and that struct holds offsets that point into the image. There is a cs_struct that corresponds to the char imageA and its stored graphic offset is 0. There is a cs_struct that corresponds to imageB and its stored graphic offset is 8, etc. The function sp1_IterateSprChar will iterate over the cs_structs to allow you to make changes to these offsets.
A horizontal flip involves two things: you need to reverse the columns making up the sprite which can be done by changing the graphic offsets and secondly you need to mirror the graphic when it is drawn.
To do part 1, I think I would store offsets in a few arrays and simply copy them into the cs_structs using sp1_IterateSprChar when an image state is changed.
For our 3x3 ACBD image the normal orientation array of offsets might look like:
Code: Select all
// raw image
//
// A C -
// B D -
// - - -
unsigned int image_raw_3x3[] = { 0,0, 24,0, 0,24, 8,0, 32,8, 0,32, 16,0, 40,16, 0,40, }; // AC-,BD-,---
// image mirrored horizontally
//
// C A -
// D B -
// - - -
unsigned int image_hmirror_3x3[] = { 24,0, 0,24, 0,0, 32,0, 8,32, 0,8, 40,0, 16,40, 0,16 }; // CA-,DB-,---
These arrays have a pair of offsets for each character and occur in row-major order because sp1_IterateSprChar iterates the sprite characters in row-major order.
image_raw_3x3[] is storing the offsets for the unmodified image as shown above the definition. We store the offset pairs in row major order as shown in the comment after the definition ("AC-,BD-,---"). Each pair consists of the graphic offset and the graphic offset of the char to the left of the square.
The first row stored is the offsets for image "A C -". "A" has graphic offset 0 and there is no char to the left so its offset is also 0. "C" has graphic offset 24 and A is to the left with an offset of 0. The blank column has no associated graphic so its offset is set to 0 and C is to the left with an offset of 24. The same applies to the rest of the offsets.
For each character in the 3x3 sprite we are effectively specifying what offset to use for the character's graphic and for the character to the left of current square in row-major order.
To make the change call sp1_IterateSprChar:
Code: Select all
int *offset_array;
void change_offsets(unsigned int count, struct sp1_cs *c)
{
c->def = offset_array[0]; // change the char's graphic offset
c->l_def = offset_array[1]; // change the char's left graphic offset
offset_array += 2; // move to next entry for next call
}
...
main()
{
...
// horizontally mirror sprite
offset_array = image_hmirror_3x3;
sp1_IterateSprChar(s, change_offsets);
...
}
After executing that code, the 3x3 image should be drawn in a mirrored order. The array is good for any 3x3 sprite image (without masks) as the offsets will be the same.
That was step 1. Step 2 is you have to draw each character with mirrored pixels. For that you will have to write your own sprite draw functions.
The library's sprite draw functions can be located in sp1/zx/sprites/draw. To pick a simpler example, imagine your sprites are "OR" sprites. The leftmost column will be using draw function "SP1_DRAW_OR1_LB" (left border), the center column will use "SP1_DRAW_OR1" and the rightmost column will use "SP1_DRAW_OR1_RB" (right border). The difference between these is the LB version assumes there is no graphic to the left of the column and the RB version assume it is the rightmost blank column so doesn't draw anything except what shifts in from the left.
You can take a look at the SP1_DRAW_OR1 function to see a general shifted draw of an OR sprite character:
http://z88dk.cvs.sourceforge.net/viewvc ... iew=markup
The entrypoint is line 30 with register set-up noted prior.
The first thing it does is check if there is no horizontal rotation and if there isn't it uses the faster & simpler "SP1_DRAW_OR1NR" (no rotate) function.
Then it adds the sprite's frame pointer to the offsets in ix and hl to form the image address for the character.
Then it proceeds to draw the character. The drawing is done into an 8-byte buffer at a fixed location in memory (SP1V_PIXELBUFFER). The OR sprite logically ORs the image into that buffer after rotating it. The rotation rotates the image in from the left and ors with the image rotate right using the horizontal shift table.
You would have to write a new draw function that after constructing the sprite image, mirrors the byte and then ORs it into the buffer.
That's the last step to get mirrored bytes.
When you iterate the sprite to change the offsets you'd then also change the draw function to this mirrored version (c->draw = ...) which I skipped in the above example.
That's probably quite a bit to chew on
