2 pixels wide sprites

[obschan]

Hi,

 

Has anyone already tried 2 pixels wide fully literal sprites ?

 

I tried with sprites based on this pattern :

char spritedata[] = {2, 0x11, 2, 0x11,2, 0x11,2, 0x11,2, 0x11,2, 0x11,2, 0x11,2, 0x11,2, 0x11,2, 0x11,2, 0x11, 0};

 

But when I am render it on real hardware I am missing the second column of pixels while it's correct on handy :

Sorry the image is a mess but we can see the behavior with the pink columns.

Am i doing anything wrong, or could someone identify a known bug there ?

 

Thanks

Edited October 28, 2012 by obschan

[+karri]

Handy has memory zeroed at startup. Does it work ok if you add a zero at the end of the literal sprite?

[obschan]

You mean ending the sprite by 2 or more zeros ?

I'll try tonight.

Edited October 29, 2012 by obschan

[obschan]

Handy has memory zeroed at startup. Does it work ok if you add a zero at the end of the literal sprite?

Tried at the end of the sprite, getting the same result :'(

[obschan]

The 2 pix wide sprite works without issue in an ordinary data packet though...

[LX.NET]

Hi Obschan,

 

What kind of literal data are you using: totally literal (SPRCLT1_literal: bit 7 set in $FC81 or SPRCTL1 of the SCB) or ordinary data packet with literal?

 

Edit: missed a refresh and you answered this already. Let me look into it some more.

 

 

Edited October 29, 2012 by LX.NET

[LX.NET]

It could be the hardware bug that is reported in the Epyx documentation:

 

"There is a bug in the hardware that requires that the last meaningful bit of the data packet at the end of a scan line does not occur in the last bit of a byte (bit 0). This means that the data packet creation process must check for this case, and if found, must pad this data packet with a byte of all 0s. Don't forget to adjust the offset to include this pad byte. Since this will only happen in 1/8 of the scan lines, it is not enough overhead to force me to try to fix the bug. Sorry."

 

In your case the last significant bit is in the last bit of your byte. I guess you could try:

 

3, 0x11, 0x00,

3, 0x11, 0x00,

...

0

 

and see if that works.

[obschan]

What kind of literal data are you using: totally literal (SPRCLT1_literal: bit 7 set in $FC81 or SPRCTL1 of the SCB) or ordinary data packet with literal?

Yes the totally literal data packet with the bit 7 on the scb ctl.

 

Like you suggested I tried with 4 pixels, this is working, however since I am not using any transparent color this is blitting the index 0 too, I can override it later with other sprites but the result will use quite more cycles than initially planned ... :/

[LX.NET]

Mmm, ok. Seems like you are stuck with the behavior and bug of totally literal sprites.

 

I am interested in your need for totally literal data. Any hints?

[obschan]

Mmm, ok. Seems like you are stuck with the behavior and bug of totally literal sprites.

That's awkward ... Should have already been reported or something ...

I would be glad if someone could confirm it on real hardware

 

I am interested in your need for totally literal data. Any hints?

Doing some speed tests, I have no clue on how the sprite engine works but I guess that on 2 pixels wide sprites literal must be the quickest.

With the normal data packet, you add the packed/unpacked bit, plus loose the alignment ...

And size ... normal data packet will be 1/3 bigger in that case.

Edited October 29, 2012 by obschan

[+karri]

I actually read the docs. The literal sprite will always paint all the pixels in the byte. This means that the sprite will have a tail.

 

The only sensible way is to use packed sprites. But packed sprites cannot show single pixels as runlenghts. So you need to use packed sprites with literal components for single bits and if the scanline ends with a "1" you have to add an extra zero byte.

 

A bit complicated...

--

Karri

[LX.NET]

But packed sprites cannot show single pixels as runlenghts.

Can you elaborate a bit, Karri?

[obschan]

I am not sure I understand either.

My pixel are 4 bits based, I use 1 byte to paint my 2 pixels, that just fits perfectly therotically.

I tried lines finishing with a 1 or 0, I am seeing the same behavior.

Edited October 30, 2012 by obschan

[+karri]

From the EPYX manual (I actually got one when I signed up as a developer at Atari 20 years ago, lol).

 

Well, I finally found the bug that required a pad byte of 0 at the end of each scan line of data. But, It is actually 2 bugs. I have fixed one of them, but the other requires an extensive change. Too bad, I am out of time. Therefore:

There is a bug in the hardware that requires that the last meaningful bit of the data packet at the end of a scan line does not occur in the last bit of a byte (bit 0). This means that the data packet creation process must check for this case, and if found, must pad this data packet with a byte of all 0s. Don't forget to adjust the offset to include this pad byte. Since this will only happen in 1/8 of the scan lines, it is not enough overhead to force me to try to fix the bug. Sorry.

A data Packet header of '00000' is used as an additional detector of the end of the line of sprite data. This is normally used as the tiller in the last byte of a line of data, but it can be located anywhere in the data line, not just the last byte. Note that this would ordinarily decode to a packed packet of 1 pixel. Please use a literal packet of 1 pixel when the imagery calls for such an event. In addition, this special header is used when a scan line with no pixels is desired. You must use an offset of 2 with a data byte of all 0, since an offset of 1 will cause a change of painting direction.

oops, may have a bug, more later on the truth of '00000'

In a totally literal sprite, there is no pixel count. Source data is converted to pixels until it runs out of bytes in that line of sprite data. The odd bits that may be left over at the end of the last byte will be painted. The special data packet of '00000' is not recognized in a totally literal sprite.

[obschan]

Yes I keep reading it, but each time I get even more confused ...

 

In that paragraph what is called "scan line" ? I guess not the screen's, the sprite's pixel line ?

If yes, ok I understand, but then why this sould only occurs 1/8 of the scan lines ?

In my case it's for every sprite's lines.

Edited October 31, 2012 by obschan

[obschan]

OK I think I got it, everything is clear now

The "1/8 of the scan lines" references certainly the probability of the sprite data to finish on the last bit ...

Don't know why, I was thinking of 1/8 of the pixel's scan lines ...

So it's really this bug I am facing and I am stuck with it ...

Thanks and sorry for the mess

 

PS: would be nice to add this bug to handy.

Edited October 31, 2012 by obschan

[laoo]

Hi. I'm trying to understand the nuances of sprite data format, and don't feel like starting a new thread, so I thought I'll catch on here for time being, as the issue have been mentioned here.

So could someone explain what it means a data Packet header of '00000'?

Is it 5 '0' bits? 5 bytes? 5 nibbles? And how does it works as an additional detector of the end of the line of sprite data?

Follow-up question: the offset to next sprite line is signed or unsigned?

 

EDIT: After reading what I've wrote I came up to a conclusion that 5-bit version might have sense given that we can't draw 1-pixel wide packed sprite.

 

EDIT2: Next sentence that is not clear for me: This [a data Packet header of '00000'?] is normally used as the tiller in the last byte of a line of data, but it can be located anywhere in the data line, not just the last byte.

Does it mean that we can draw jagged sprites when the line can be ended anywhere using this EOL detector?

What does it relate to the sentence the hardware [...] requires that the last meaningful bit of the data packet at the end of a scan line does not occur in the last bit of a byte (bit 0)? So there must be one '0' bit or 5 '00000' bits at the end of the line?

 

And finally: where is the later on the truth of '00000'?

Edited June 10, 2019 by laoo

[+karri]

The data format is a stream of bits. Unfortunately there are several cases when you must enter a pad byte of zero (end of line, end of sprite).

 

There is also 3 different formats available.

 

Literal has no packing.

 

Packed has run-length compression.

 

Shaped may stop decoding a scan line before reaching the edge of a bounding box. This is a nice way to create non-square sprites that can display index 0 also.

 

The creation of sprites has been a bit difficult for me by just reading the docs. Here is my understanding of how to encode the sprite.

 

If you read the comments in the code below you get an idea of the bugs in the Lynx and how to create working sprites.

 

In old games it is very common to start drawing from a different quadrant than 0. Then you may encode only 2 quadrants instead of 4.

lynxsprite.txt