InvisiP0ng

[Brek Martin]

.

 

 

 

 

Edited May 14 by Brek Martin

[Nop90]

Why the different behaviour from an emulator and the real Lynx? Is it wanted or some side effect?

[Brek Martin]

.

Edited May 14 by Brek Martin

[Nop90]

Nice experiment.

 

Looking at the decompiled source of this demo, if you already didn't it, I suggest you to experiment also with chained sprites (so you have to call suzy draw only once) and with reusing sprite data, but changing the penpal array, to have a copy of the same sprite displayed with different colors. 

[Brek Martin]

.

 

Edited May 14 by Brek Martin

[Nop90]

Linking sprites is easy.

the code of the OP example should be something like:

 

unsigned char bat1[] = { ...};
unsigned char bat2[] = { ...};
unsigned char ball[] = { ...};

SCB_REHV_PAL sp_a = 
{
    BPP_4 | TYPE_NORMAL,
    REHV,
    0x01,u
    0,
    bat1,
    3, 40,
    0x100, 0x100,
    {0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF}
};

SCB_REHV_PAL sp_b = 
{
    BPP_4 | TYPE_NORMAL,
    REHV,
    0x01,
    0,
    bat2,
    157, 40,
    0x100, 0x100,
    {0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF}
};

SCB_REHV_PAL sp_c = 
{
    BPP_4 | TYPE_NORMAL,
    REHV,
    0x01,
    0,
    ball,
    79, 40,
    0x100, 0x100,
    {0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF}
};

void main(void)
{
    [init code]
    while (1)
    {
        tgi_clear();
        tgi_sprite(&sp_a);
        tgi_sprite(&sp_b);
        tgi_sprite(&sp_c);
        tgi_updatedisplay();
        while (tgi_busy()) ;
        [ handle input and move sprites]
    }

}

with linked sprites it would be:

 

unsigned char bat1[] = { ...};
unsigned char bat2[] = { ...};
unsigned char ball[] = { ...};


SCB_REHV_PAL sp_c = 
{
    BPP_4 | TYPE_NORMAL,
    REHV,
    0x01,
    0, // // sp_c has a VOID pointer and ends the chain
    ball,
    3, 40,
    0x100, 0x100,
    {0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF}
};
SCB_REHV_PAL sp_b = 
{
    BPP_4 | TYPE_NORMAL,
    REHV,
    0x01,
    sp_c, // sp_b points to sp_c as next sprite
    bat2,
    157, 40,
    0x100, 0x100,
    {0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF}
};

SCB_REHV_PAL sp_a = 
{
    BPP_4 | TYPE_NORMAL,
    REHV,
    0x01,
    sp_b, // sp_a points to sp_b as next sprite
    bat1,
    79, 40,
    0x100, 0x100,
    {0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF}
};


void main(void)
{
    [init code]
    while (1)
    {
        tgi_clear();
        tgi_sprite(&sp_a); // since sprites are chained you call suzy only once passing the first sprite of the chain
        tgi_updatedisplay();
        while (tgi_busy()) ;
        [ handle input and move sprites]
    }

}

also, if bat1 and bat2 are the same sprite but using different colors from the same palette you can use only bat1 and reassign the colors to draw with the penpal array of the sprite structure.

 

E.g. if bat1 uses a blue center line, that is the second color of the palette, and bat2 used a red color for the center line of the palette, that is the third color of the palette, you can do this:

 

SCB_REHV_PAL sp_b = 
{
    BPP_4 | TYPE_NORMAL,
    REHV,
    0x01,
    sp_c, 
    bat1, // using the same sprite of sp_a
    157, 40,
    0x100, 0x100,
    {0x02, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF} // the first value of the array changed from 0x01 to 0x02, this means that for the second color of the sprite palette I'm using the third color of the screen palette
};

 

 

[Brek Martin]

.

 

 

 

 

 

 

Edited May 14 by Brek Martin

[Nop90]

16 minutes ago, Brek Martin said:

No dimension of the display exceeds 255, so it's easier for an 8 bit CPU to track everything on a screen as unsigned bytes.

This is not correct, SUZY chip can handle a virtual window bigger than the physical screen, and at this window can be applied X and a Y offsets (changing the offset the screen image can slide without changing the single sprites coordinates).

 

This means that you need signed values for the sprite position, and they must be signed integers because signed chars are too small.

 

24 minutes ago, Brek Martin said:

I wonder now if memory permitting, it would be better to make copies of the same sprite just so that it can be chained,

if a number of the same "baddies" are on the screen.

It's up to you to prefer memory saving or performance boost. Chained sprites are much faster.

[Brek Martin]

Thanks Nop90. It's all noted.

 

 

Edited May 14 by Brek Martin

[Brek Martin]

It occurs to me that the game needs sprite data which was not provided.

Here's a colourful ball with Suzy bug taken into consideration:

unsigned char spdat[71] = { // typical
    0x7,0x0,0x0,0x11,0x0,0x0,0,
    0x7,0x0,0x11,0x88,0x11,0x0,0,
    0x7,0x1,0x88,0x99,0x88,0x10,0,
    0x7,0x1,0x89,0x77,0x98,0x10,0,
    0x7,0x18,0x97,0xcc,0x79,0x81,0,
    0x7,0x18,0x97,0xcc,0x79,0x81,0,
    0x7,0x1,0x89,0x77,0x98,0x10,0,
    0x7,0x1,0x88,0x99,0x88,0x10,0,
    0x7,0x0,0x11,0x88,0x11,0x0,0,
    0x7,0x0,0x0,0x11,0x0,0x0,0x0,0
};

 

and it occurs to me this has been the way so long as a literal sprite has been done in homebrew.

I have searched the forum, and every literal sprite I find is a rectangular block image.

The same can be said for repositories that contain code with literal sprites.

However, sprite examples posted here would typically be from people who don't know what they are doing, and are looking for help.

Still, nobody has corrected them.

 

Although I couldn't get sprpck to work, it would need a 15th input argument of the sprite type

ie. Normal, Boundary, etc. To know what to do with the zero pen. But for a normal sprite:

 

unsigned char spdat[65] = { // optimal
    0x5,0x0,0x0,0x11,0x0,
    0x6,0x0,0x11,0x88,0x11,0,
    0x7,0x1,0x88,0x99,0x88,0x10,0,
    0x7,0x1,0x89,0x77,0x98,0x10,0,
    0x7,0x18,0x97,0xcc,0x79,0x81,0,
    0x7,0x18,0x97,0xcc,0x79,0x81,0,
    0x7,0x1,0x89,0x77,0x98,0x10,0,
    0x7,0x1,0x88,0x99,0x88,0x10,0,
    0x6,0x0,0x11,0x88,0x11,0,
    0x5,0x0,0x0,0x11,0x0,0
};

 

That's thinking outside the block image. So obvious once noted!

an artefact functioning of RLE hardware.

Apologies if such a simple thing has been discovered before. I did my best to find out.

but people including me could go back and retroactively hex edit sprite data in built binaries to improve performance if this is new.
 

This ball is my art. Once I let it out into the world I do lose control of it. That much is true,

but it forever remains mine. I could alter, or delete the zeitgeist at any time, and indeed that could be a part of the art.

Art could be a robotic arm with a hammer that smashes itself.

 

Fury source code was intended to be deleted from the get go. It's a 17 day learning experiment,

and building on top of platform or language learning exercises can be flawed practice. Take a look at Windows.

Not the binary, it was always available. It was also sent to Igor for inclusion in a repository. That's all your mistake.

The "Warez", the Amiga hand holding disk, and the begging for donation in pause screen is supposed to induce the 90's zeitgeist.

If you enable the greatest cheat by pressing pause in the intro screen, and also press pause straight after game start,

the program will display the computed checksum for the donation message in the pause screen.

If anyone did donate, a custom message can be included, and the new checksum added to the hex file as well.

If the message data is changed without the checksum, the pause screen can't be exit.

This proves the prior intention to delete Fury's source. It needs no performance boost though.

If you think it's slowing down on real hardware, keep your eye on the background stars.