Jump to content
IGNORED

sp65 changed - a lot


karri

Recommended Posts

20 minutes ago, 42bs said:

sprpck has the -c option to compress the color table, which I found also helpful.

So if the part of your sprite (or portion of a bigger one) uses only 8 color it will use only 3 bit.

Not sure if that's what you mean with the pen option.

That is exactly what I aim for with the "penpal" option.

 

I was thinking about automatic compression of the palette. But it could be difficult to understand how the mapping was done. Perhaps I should introduce something like -c and then it would output the resulting mapping "penpal".

 

Now I try to get together a tutorial with one graphics sheet and a small C-project that creates a small game using these sp65 features.

Link to comment
Share on other sites

The starting point is a sheet of graphics where ALL elements have 16 colours.

graphics.png.c82a3797136ceb11864b90589bfd5644.png

 

The goal is to use SPRITE_BACKGROUND mode to the characters and not use any transparent colours. This means that I will be using the mode=shaped,edge=15 to allow the character to stop drawing the sprite when it encounters the edge.

 

 

Link to comment
Share on other sites

3 hours ago, karri said:

I just pushed the new version.

 

The ay=mid, ax=max options are now available.

 

There is also a new option "pen" available.

 

The idea is that you can have a single graphics image that could be 4 bit deep (for 16 colours). When you slice and area you can map the colours into a 2-bit sprite by defining the option

 

-c lynx-sprite,pen=089a

 

This would greate the new sprite as a 4-colour sprite and map the colours as the "pen" says. The effect is the same in your code later. If you draw your 4-colour sprite with the penpal = {0x08, 0x9a} you will get the correct colours on screen.

 

The "pen" can also be to enforce a certaing depth for the sprite.

 

So if you have a 2-colour bitmap, but you want a 16-colour sprite.

 

-c lynx-sprite,pen=0123456789abcdef

 

This would save the sprite as a 4-bit sprite despite that the original bitmap is something else.

Awesome! Thanks Karri

Link to comment
Share on other sites

19 minutes ago, 42bs said:

But the player sprite needs transparent colors if it contains "holes". For example if it is walking.

Maybe I do not get the "edge" approach completely.

True. But I would solve this by a shadow that fills the area between the legs. If you look at the sword I had to add blueish shadow to cover the hole between the face and the sword. This is mainly for showing off all the new sp65 features.

Link to comment
Share on other sites

23 minutes ago, 42bs said:

BTW: Do you have an example image where the new packing algo gives a benefit?

Several "old time" releases seem to use it. The title sprite consists of two sprites. A single pixel full screen background drawn with ALGO3 linked with a shaped sprite that leaves some parts undrawn. Unfortunately I compare my improvements vs the old sp65. Not sprpck.

Link to comment
Share on other sites

51 minutes ago, 42bs said:

The "best packing" algo is good! The BG sprite with sprpck is 180 bytes larger. Good job.

 

Which BG sprite? I'd love to test packing component in our framework (in which LQ and MK where made and which we are preparing do release) too.

Edited by laoo
Link to comment
Share on other sites

36 minutes ago, laoo said:

Which BG sprite? I'd love to test packing component in our framework (in which LQ and MK where made and which we are preparing do release) too.

    $(SP) -r graphics.pcx --slice 26,114,160,102 -c lynx-sprite,mode=packed -w bg.c,ident=bg,bytesperline=8

Link to comment
Share on other sites

32 minutes ago, 42bs said:

    $(SP) -r graphics.pcx --slice 26,114,160,102 -c lynx-sprite,mode=packed -w bg.c,ident=bg,bytesperline=8

The data in bg.c is 5240 bytes. My algorithm yields 5421 which is 181 bytes more. And i'm wondering now how it is possible as I was until now pretty convinced that only reasonable algorithm to pack Suzy textures is a greedy one, so it can't be done better...

 

  • Like 1
Link to comment
Share on other sites

1 minute ago, laoo said:

The data in bg.c is 5240 bytes. My algorithm yields 5421 which is 181 bytes more. And i'm wondering now how it is possible as I was until now pretty convinced that only reasonable algorithm to pack Suzy textures is a greedy one, so it can't be done better...

 

The problem is that if you always look for the next set of pixels you easily end up saving less in the future.

 

So I put all the pixels in a 32 pixel buffer and take care of the longest run first.

  • Like 1
Link to comment
Share on other sites

4 minutes ago, laoo said:

The data in bg.c is 5240 bytes. My algorithm yields 5421 which is 181 bytes more. And i'm wondering now how it is possible as I was until now pretty convinced that only reasonable algorithm to pack Suzy textures is a greedy one, so it can't be done better...

 

? Like I thought about sprpck. Actually, I never thought it could be "optimized". But Karri proved me wrong ?

I am investigating this.

Edited by 42bs
  • Like 1
Link to comment
Share on other sites

3 minutes ago, karri said:

The problem is that if you always look for the next set of pixels you easily end up saving less in the future.

 

So I put all the pixels in a 32 pixel buffer and take care of the longest run first.

Astonishing. I have to digest this because I'm stuck with a "proof" that it's impossible.

 

2 minutes ago, 42bs said:

I am investigation this.

Likewise :)

  • Like 1
Link to comment
Share on other sites

Honestly, I do not see where the benefit comes from:

Counter+Flag = 5 bits.

P => RLE encoded

L => literal

Bits per pixel = 4

 

P1 => 9 P2=>9 P3=>9

L1 => 9 L2=>13 L3=17 L4 = 21

 

So a sequence:

AABB     is P2 P2 = 18 bits or literal L4 = 21 bits

AABCC is  P2 L1 P2 = 27 or L5 = 25

 

Ahhhhh, 2bits saved.

 

Mind wrecking.

  • Haha 1
Link to comment
Share on other sites

Karri did a really nice job on this. What prompted the investigation: I was extracting boot screens from old 1990s game ROMs, and when I ran sprpck.exe (also from the 1990s ;) ) on the screens, they usually ended up several hundred bytes longer than the original packed sprite. So Karri got curious as to why sprpck / sp65 were not as efficient as what Atari developers used back in the day.

  • Thanks 2
Link to comment
Share on other sites

2 hours ago, Songbird said:

Karri did a really nice job on this. What prompted the investigation: I was extracting boot screens from old 1990s game ROMs, and when I ran sprpck.exe (also from the 1990s ;) ) on the screens, they usually ended up several hundred bytes longer than the original packed sprite. So Karri got curious as to why sprpck / sp65 were not as efficient as what Atari developers used back in the day.

Oh, yes. sprpck's algo is so naiv (it is from 1992!). It does not take care for certain patterns:

With 4-bit sprites, there is so far only this one: AAbAA (repeating) where literal gives an advantage over packed. But with 3-bit there are some more and I did not check yet 2 and 1 bit sprites.

 

sprpck does check if 2 or more pixels repeat then uses RLE else literal.

 

Interessting: No one ever noticed that it is so bad. Thanks Carl and Karri for pointing this out. (I really mean it!)

  • Thanks 1
Link to comment
Share on other sites

The other thing that really makes a difference is to stop generating data that is not needed. Typically transparent pixels towards the edges. In sp65 I plan to tackle this with a keyword "edge" and a type "shaped".

 

You can also use "shaped" sprites with index 0 as transparent. Just define edge=0. Then you generate a smaller sprite that still has holes.

Link to comment
Share on other sites

I have also been thinking about the comment by @bs4 about the dynamic compression of colours. Perhaps I add an option "pen=opt" that would create a minimum sprite and also output the resulting penpal to a separate file "name"_pen.[c,s,raw]

 

I just implemented it. The penpal is just printed on the screen. I did not feel the extra complexity in dealing with files is worth the effort.

Link to comment
Share on other sites

14 minutes ago, LordKraken said:

Bra jobbat Karri :)

 

Just wondering before digging into the tool, could I safely switch to sp65 considering I'm still using the old toolset (newcc65 and such)?

Tack Alex,

 

The output of sp65 is just bytes. It is compatible with any environment.

You can output it in raw-format at binary and read it in your environment.

I did use sprpck like this in the newcc65

 

# Rule for making a *.o file out of a *.bmp file
%.o : %.bmp
    $(SPRPCK) -t6 -p2 $<
    $(ECHO) .global _$* > $*.s
    $(ECHO) .segment \"$(RODATA_SEGMENT)\" >> $*.s
    $(ECHO) _$*: .incbin \"$*.spr\" >> $*.s
    $(AS) -t lynx -o $@ $(AFLAGS) $*.s
    $(RM) $*.s
    $(RM) $*.pal
    $(RM) $*.spr

Link to comment
Share on other sites

2 hours ago, Songbird said:

Bastian, any chance you would want to update sprpck.exe with the better packing algo? I prefer running native Windows apps to Cygwin. ;)

sprpck needs some cleaning but I want to put it on my github. I want to include the BMP patch and - of course - the optimizing of the compression bugs me.

 

  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...