sprpck updated

[42bs]

As follow up to the compression discussion, I reworked sprpck a bit and published it on github.

 

Multi quadrant is working and Karri's idea with the edge pen is also implemented.

 

https://github.com/42Bastian/sprpck

 

Only cygwin exe so far. Linux users may just run make to compile it.

 

Currently optimizing is only tested for 4 bits/pixel, but it can be disabled by -O0.

 

The BMP fix is not implemented yes, but 4bit/1plane PCX are supported now.

[42bs]

MinGW build added.

BMP24 fix from Nop90 added.

Example pictures (THX Karri!) added.

-------------------------------------------

First tests with lower bits/pixel resolutions show no errors and compression though not best works.

[LordKraken]

I compiled it for win32, just before the last update. Seemed to work but bmp 24 were not supported anymore (I guess that the bmp24 you just mentionned?).

Also i converted my bmp 24 to 4 bits and it seemed the palette output were incorrect (the B channel was always 0). Problem did not occur with bmp 8 bits.

 

Anyway it seems I might be able to save 100 extra bytes on  Odynexus so thanks for that

 

(do u accept contribution, ie I could do a PR for the win32 build).

[42bs]

2 minutes ago, LordKraken said:

I compiled it for win32, just before the last update. Seemed to work but bmp 24 were not supported anymore (I guess that the bmp24 you just mentionned?).

Also i converted my bmp 24 to 4 bits and it seemed the palette output were incorrect (the B channel was always 0). Problem did not occur with bmp 8 bits.

 

Anyway it seems I might be able to save 100 extra bytes on  Odynexus so thanks for that

 

(do u accept contribution, ie I could do a PR for the win32 build).

The BMP fix from Nop90 was just quick'n'dirty added. I did not yet test the results.

 

I never worked with PR. But why not.

[42bs]

7 minutes ago, LordKraken said:

I compiled it for win32, just before the last update. Seemed to work but bmp 24 were not supported anymore (I guess that the bmp24 you just mentionned?).

I just tried the bg24bit.bmp with the current source online and the result is ok. 5113 bytes (bmp not 100% identical to the pcx).

[LordKraken]

So I cleaned up my fixes and I have a local "win32" branch to push to your repo, but you need to invite external contributors to your project first. As it is a separated branch, it won't affect your current version, and you can safely review it before merging, well if it makes sense to support a regular win32 version

 

My github account is... well... LordKraken

[42bs]

11 minutes ago, LordKraken said:

So I cleaned up my fixes and I have a local "win32" branch to push to your repo, but you need to invite external contributors to your project first. As it is a separated branch, it won't affect your current version, and you can safely review it before merging, well if it makes sense to support a regular win32 version

 

My github account is... well... LordKraken

Done. What do you mean by "regular" win32? A VS project? Because the makefile uses Mingw which is also pure win32.

 

[LordKraken]

Yes sorry I have been very incorrect, I meant vs indeed as it is more "regular/standard" than GNU toolchain on Windows (well at least if you work within the games industry), so I prefer to avoid writing makefile and refrain of using console commands ^^

Edited March 10, 2020 by LordKraken

[42bs]

Another method for compression added. Not much benefit for 16 color sprites, but the 2 color sprite will be reduced from 2378 (or 2994 w/o optimization) down to 2101.

 

Beware, the new compression code is horrible. It is kind of brute force trying to find the best compression for a chunk of pixels. But it took quiete some tweaking to be better than the pattern based algo.

Both algo run on the data now.

 

[+karri]

I assume that I just try to grab the parts that do the magic from your code without going into the details. After all, the result is more valuable than the coding style.

[42bs]

40 minutes ago, karri said:

I assume that I just try to grab the parts that do the magic from your code without going into the details. After all, the result is more valuable than the coding style.

My coding style

Oh yeah, I need to polish the code, proper variable names, stdint instead of BYTE etc.

 

Essential is that the pixel buffer is always filled right to left no matter what drawing direction!

 

Edit: I mean the quadrants here. So even pixels are draw to the left, the pixel buffer is scanned to the right.

 

 

Edited March 24, 2020 by 42bs

[Songbird]

I downloaded the updated sprpck.exe file and ran it on the Super Skweek image identified on the other thread. The original graphic packed down to 5414 bytes in the original ROM. I ran the ROM on Handy and saved the boot screen as *.bmp format. Old sprpck.exe packed this to 7891 bytes (ouch!) 5874 bytes. New sprpck.exe packed this to 5441. So not quite as efficient as the original, but very close. Does this sound accurate based on current algorithms?

 

Edit: sorry, I think I packed it as literal on accident. Old sprpck.exe packed it to 5874 bytes.

Edited March 25, 2020 by Songbird

[42bs]

Ok, the 7891bytes seems weird as the original sprpck is the same as the new one with -O0 which gives 5874 bytes for Super Skweek.

I just checked V1.97.

And yes, the current algorithems aren't yet 100% perfect.

I have another two ideas. Le'ts see ?

 

[Songbird]

Sorry, that was a mistake on my part. I was able to pack it to 5874 just as you said.

 

It's still very cool to see so much improvement on the packing after all these years! Nice job.  

[Fadest]

Did someone noticed some strange conversion with new version of sprpck ?

I used it for many dozens of files recently, and I just found a pic that is not well converted :

 

It is a quite simple BMP, 1610x102px, 16 colors (see credits.bmp attached):

Everything is correct with old sprpck (v1.98).

 

But with the new one, I get this :

 

Seems like a portion of 1 line is reverted :

 - I moved the text block and nothing changed

 - I tried to add a red pixel between 's' & 'e' and it was displayed after the 'd'

 

(note that there is an additionnal background in screen copy, but it is another sprite)

 

Same behaviour with .spr or .obj output...

 

No time to investigate until mid-august , and I don't know if I can find something to explain this.

Until this, I will keep old sprpck output for this sprite.

 

Credits.bmp

Edited July 8, 2020 by Fadest

[42bs]

Did you try without optimization (-O0) ? I had similar with Karri's "test sprite", but thought I could fix it.

 

[Fadest]

No.

I will try.

 

Edited July 8, 2020 by Fadest

[Songbird]

Would the packing optimizations help (potentially) on sprites with lower color depth? I am trying to reproduce a boot screen for an old game which only had 4 colors in a packed sprite. The original sprite was 1151 bytes, but when I pack it with -s2 (for 4 colors) it came out to 1493 bytes.

 

Full parameter list:

sprpck.exe -v -c -p1 -t6 -s2 -i 146074 bootscreen.bmp

 

Note that the game uses the boot-up linked SCB trick, so first SCB clears the screen to black, then second SCB only has a 146x74 image centered on the screen.

 

[42bs]

Carl, did you use the old or the new sprpck?

 

Anyway, there are still some better packing optimizations in the Amiga tools. I tried a "logic" attempt, but maybe brute force is better.

 

PS: I'd be happy for any example where the new sprpck "fails". So if you like, please send me the BMP privately (I keep it confidential of course).

Edited September 14, 2020 by 42bs

[+karri]

Perhaps it would be a good idea to create a brute force code for finding the best-ever packing for a line. It the brute force is run to break every run-length in 3 piecies like 'literal','runlength','literal' the we should be able to catch every variation. The literals should always start with the first pixel available and aim for maximum length.

 

We could also insert the bg colour as one parameter to created shaped sprites.

[42bs]

18 hours ago, Songbird said:

Would the packing optimizations help (potentially) on sprites with lower color depth? I am trying to reproduce a boot screen for an old game which only had 4 colors in a packed sprite. The original sprite was 1151 bytes, but when I pack it with -s2 (for 4 colors) it came out to 1493 bytes.

 

Full parameter list:

sprpck.exe -v -c -p1 -t6 -s2 -i 146074 bootscreen.bmp

 

Note that the game uses the boot-up linked SCB trick, so first SCB clears the screen to black, then second SCB only has a 146x74 image centered on the screen.

 

I am shocked, how bad the "optimized" packer is for < 4 bits per pixel
 

[+karri]

I just got an idea of the brute force algorithm that is simple and flawless! - I hope...

 

The only iterator I need is a one that converts one pixel from a packed  structure to a literal. And you can at most steal pixels until the literal has 16 pixels.

 

By dynamically launching iterators on every literal packet when you encounter it you could traverse to the end of line without spending too much computing power.

[42bs]

Comparing the original sprite Carl provided I found out that Karri's edge-option gave a giant improvement: From 1493 down to 1166. Still larger than the original.

[+karri]

1 hour ago, 42bs said:

Comparing the original sprite Carl provided I found out that Karri's edge-option gave a giant improvement: From 1493 down to 1166. Still larger than the original.

yep. I am getting a bit interested in doing a brute force packer as no logic seems to work. Why, oh why are we so stupid?

[42bs]

New version uploaded: Fixed "-u" crash and beautified the compress color output.