Jump to content

Recommended Posts

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.

  • Like 1
  • Thanks 3

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

grafik.thumb.png.5286a58970b9e5e030164f6501698e11.png

Share this post


Link to post
Share on other sites

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 :D

  • Thanks 1

Share this post


Link to post
Share on other sites
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 :D

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

 

Share this post


Link to post
Share on other sites
Posted (edited)

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 by LordKraken

Share this post


Link to post
Share on other sites

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.

 

  • Thanks 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by 42bs
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

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 by Songbird

Share this post


Link to post
Share on other sites

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 🙂

 

Share this post


Link to post
Share on other sites

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

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

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 :

snapshot01.thumb.png.86e559ecd187c60105e50c40edb2a06c.png

 

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 by Fadest

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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 by 42bs

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 :(
 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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.

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