Jump to content
IGNORED

sp65 changed - a lot


karri

Recommended Posts

3 hours ago, 42bs said:

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.

 

I've managed to forge quite simple algorithm (actually an add-on on the trivial greedy one, I presume that exactly the same as in sprpck as the efficiency of packing was the same) that crunches the BG sprite to 5174 bytes. It's useless to share my code as it's highly specific to my infrastructure but could write some pseudo-code if someone will be interested.

 

It reduced the size of Mortal Kombat data from 468992 to 456704 bytes (there are many samples though). Not to much but always something for free.

 

Edited by laoo
Link to comment
Share on other sites

11 hours ago, karri said:

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

Hi, Karri,

 

You might need to provide a translation for people who are used to sprpck.exe. ;) What's the equivalent command line parameters for sp65 to produce binary sprite data and a separate palette file?

Link to comment
Share on other sites

2 hours ago, 42bs said:

would you wait a few days? I have two long travels the next days so I can work on this "challenge" and hope to find myself a solution ?

Sure! Thinking about making it a challenge was maybe even the main reasons to wait. I'm not sure whether it's the best solution or even if it's 100% correct. The MK seems to be looking fine with it.

I think that we need more test data (with various bpp) and a tool to decompress compressed sprite to see if the compression is correct.

 

Edited by laoo
Link to comment
Share on other sites

Thanks! I am very happy to have you guys on board with this!

 

The small tutorial for carl to create binary files with sp65.

 

sp65 -r test.pcx --slice 0,0,160,102 -p lynx-palette,testpal.bin -c lynx-sprite -w test.bin

 

You should thing about sp65 as different programs concatenated to each other.

 

Reading a file:

-r test.pcx --slice x,y,w,h

 

Extracting a palette:

-p lynx-palette,testpal.bin (binary) testpal.s (asm) testpal.c (C-code)

 

Creating a sprite:

-c lynx-sprite      // Lots of options ax= ay= mode=...

 

Writing a sprite:

-w test.bin // also test.s, test.c ident=test ...

 

 

Link to comment
Share on other sites

9 hours ago, laoo said:

Sure! Thinking about making it a challenge was maybe even the main reasons to wait. I'm not sure whether it's the best solution or even if it's 100% correct. The MK seems to be looking fine with it.

I think that we need more test data (with various bpp) and a tool to decompress compressed sprite to see if the compression is correct.

 

Nice! I can provide a tool for generating a pcx file from a sprite binary. It is part of the tools I use for re-generating sources from old binary carts. It is in python3.

Link to comment
Share on other sites

1 hour ago, karri said:

Lol. Perhaps we limit the depacking algorithms to the ones that is in Suzy...

Sure, I just wanted to know which is the maximum compression.

 

As another attempt, I converted the 8-bit-per-pixel raw image into a 4-bit-per-pixel one, which can be loaded directly into screen RAM.

Here LZMA reduces it to 2393 bytes and Turbopacker to 3140. **

 

If I make a literal-only (-u in sprpck) sprite it is 8365 bytes large, but lzma packed only 2481 and TurboPacker packed 3229.

 

Again, this is only to see which is the maximum compression one can achieve with general purpose packers.

 

** Would be interessting to see, if the CPU can unpack the tp-packed chunk quicker as Suzy can draw the larger sprite.

Link to comment
Share on other sites

On 2/23/2020 at 11:34 AM, karri said:

Nice! I can provide a tool for generating a pcx file from a sprite binary. It is part of the tools I use for re-generating sources from old binary carts. It is in python3.

As I promised here is a stand-alone Lynx sprite parser in Python3.

The usage is in the Makefile. (Building the sprite on the first line. Creating the image from the sprite on the 2nd line)

$(SP) -r original.pcx -p lynx-palette,testpal.bin -c lynx-sprite,mode=packed -w test.bin
$(PYTHON) bin2pcx.py

shapedtest.zip

 

Basically the file is called bin2pcx.py

 

It will read the sprite as a binary file as well as the palette as binary file.

The output is a pcx file.

 

After the run you can diff the pxc files

 

diff original.pcx test.pcx

 

The current sp25 can pack to these values:

-rw-r--r-- 1 karkak karkak  5240 Feb 24 11:38 test.bin
-rw-r--r-- 1 karkak karkak    32 Feb 24 11:38 testpal.bin
-rw-r--r-- 1 karkak karkak 17217 Feb 24 11:38 test.pcx

So anything better than 5240 bytes is of great interest. My algorithm is just a brute force attack with the assumption that you can optimize one run length at a time. This may be wrong...
 

  • Like 1
Link to comment
Share on other sites

Current findings for 4 bits:

* Any sequence longer then 2 identical pixels can be packed.

* 2 bytes sequences with intermediate single different bytes, are better stored as literal.

 

On paper I have a good algo, now I need to  program this.

  • Thanks 1
Link to comment
Share on other sites

6 minutes ago, 42bs said:

Current findings for 4 bits:

* Any sequence longer then 2 identical pixels can be packed.

* 2 bytes sequences with intermediate single different bytes, are better stored as literal.

 

On paper I have a good algo, now I need to  program this.

One thing I have been unsure about is the effect of a filler byte at the end of the line. If the last pixel of a line is in use you need a filler byte. Would it be better to sometimes use a literal chunk just to be sure that you never need the filler byte? I assume that the shortest sequence + filler byte is always better. As the next line starts on a byte boundary it does not matter...

Link to comment
Share on other sites

On 2/23/2020 at 1:40 PM, enthusi said:

For the bitmap gfx in Assembloids I pack the data with an individual algorithm straight into memory. Much higher packrate that simple RLE naturally.

of course but its for fullscreen gfx (I assume?) - different case. RLE is simple but zero-cost. 30-50+ sprites to render with better pack-rate - yeah!

Link to comment
Share on other sites

1 hour ago, enthusi said:

But optimizing it for a few percent while using a c-framework does not really make sense in the end.

Some people like coding in assembly, others like high level languages.

 

just like

 

Some people eat with sticks, others like a fork and knife.

 

For me writing assembly is like eating with sticks. Most of the mess is all over the place and I feel hungry.

Link to comment
Share on other sites

1 hour ago, enthusi said:

I haven't done intensive testing but RLE packed sprites are a bit slower as far as I know, but yes, agreed - it would be a waste NOT to use it.

I was wondering how it is really with the speed of RLE sprites. My intuitions is that they should be in fact faster, as there is less memory to read. But it definitely should me measured

 

1 hour ago, enthusi said:

But optimizing it for a few percent while using a c-framework does not really make sense in the end.

Oh, come one! In the first place we should be making money doing real stuff needed by real business instead of wasting our time on legacy hardware...

Of course everything here is for pure amusement so why not to optimize sprites a bit? :)

  • Haha 1
Link to comment
Share on other sites

OK Guys. Here's my next iteration. 5113 bytes.

 

BG.sprBG.pal

 

Here is also a tool that will generate PNG image from raw compressed sprite. Only 160x102 4bpp at this moment. Call it like "SprTool BG.spr BG.pal" and it will generate BG.png and BG.txt with some diagnostic informations (I hope that the exe won't be blocked by some antivirus scanners or something).

 

SprTool.7z

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...