Graphics Compression Formats

r57shell · Post by **r57shell** » Tue Jun 25, 2013 11:34 am

Ti_ wrote:Every file can give better results on different settings. And it's not always max, but in ~50 bytes range.

Nevermind. Packfire demo does not changed from that moment, after your experiments with lzma packer from 7z.

Ti_ wrote:LZMH
possibly to write unpack code?

Possible, but there is no sources, so...

r57shell · Post by **r57shell** » Fri Jun 28, 2013 7:59 pm

Some news about aPLib
viewtopic.php?p=20395#20395
Trying to get maximum advantage

Interesting fact about UMK3 archives

Code: Select all

006360 size 009800 extracted 8 frames lasts
00016F size 000C40 extracted 1 frames lasts
0001A3 size 002520 extracted 0 frames lasts
00003F size 000040 extracted 0 frames lasts

8 frames = max from my tests.
Good ratio, very fast speed, and very large code with unrolled loops.

Ti_, in your tests change "KB" into "B" because 8542 KB = 8 MB

MintyTheCat · Post by **MintyTheCat** » Wed Sep 18, 2013 7:48 pm

Stef wrote:SGDK does not have any decompression methods. I wanted to add them some time ago but i think it should be done carefully. The methods has to be fast so we can do real time decompression (in a frame timelaps) and the compression scheme should be well adapted for tiles.
Maybe that topic could be interesting to determine the best compression scheme (at least the best one in term of speed /compression / memory use ratio) so i could include in it SGDK. I would prefer to avoid multiple compression scheme if possible to keep things simple =)

I'm sorry but you seem not to appreciate that a number of compression methods should be supported as the application and benefits of each vary. As such, you should aim to support the fast but lower compression ratio methods and the slow but higher compression methods. Why would this be a hassle to include?

djcouchycouch · Post by **djcouchycouch** » Wed Sep 18, 2013 8:15 pm

MintyTheCat wrote: Why would this be a hassle to include?

Other than the time and effort needed to evaluate and test compression methods for different types of data and then implementing and integrating them in the SGDK, you mean?

Stef · Post by **Stef** » Wed Sep 18, 2013 9:50 pm

Of course supporting more compression methods require more time to test and implement them. Ideally i would like to have a fast and good compression ratio at same time... i tested sixpack/appack and it appears to be perform quite nicely on both edge. Of course anyone can implement any compression method in SGDK and i will gladly add it to the main trunk. The next version will add support for the sixpack compression to start with

r57shell · Post by **r57shell** » Mon Jan 13, 2014 7:18 am

Konami packer used in Contra: Hard Corps
http://elektropage.ru/r57shell/lzkn1.zip

Edit: compression ratio is maximum possible for this depacker. So it is better than in Lab313's one.

Stef · Post by **Stef** » Tue Jan 14, 2014 7:36 pm

Thanks ! I will try to add support for it in SGDK =)

djcouchycouch · Post by **djcouchycouch** » Tue Jan 14, 2014 7:39 pm

Stef wrote:Thanks ! I will try to add support for it in SGDK =)

That packer code comes directly from the rom? Do you think it's a good idea to add it when it's a company's intellectual property, even if it's old?

r57shell · Post by **r57shell** » Tue Jan 14, 2014 7:52 pm

djcouchycouch wrote:That packer code comes directly from the rom?

almost. beware.

Stef · Post by **Stef** » Tue Jan 14, 2014 11:14 pm

djcouchycouch wrote:
Stef wrote:Thanks ! I will try to add support for it in SGDK =)
That packer code comes directly from the rom? Do you think it's a good idea to add it when it's a company's intellectual property, even if it's old?

I know that could be a problem but honestly i think they don't care and if they does, i can quickly remove it. I compared it against aplib, generally aplib compress better (not always though) but the konami unpacking code is faster.

djcouchycouch · Post by **djcouchycouch** » Wed Jan 15, 2014 12:24 am

Stef wrote:
djcouchycouch wrote:
Stef wrote:Thanks ! I will try to add support for it in SGDK =)
That packer code comes directly from the rom? Do you think it's a good idea to add it when it's a company's intellectual property, even if it's old?
I know that could be a problem but honestly i think they don't care and if they does, i can quickly remove it. I compared it against aplib, generally aplib compress better (not always though) but the konami unpacking code is faster.

Personally, I'm not crazy about including it. I'd prefer keeping SGDK free from gray area stuff like that. Especially if someone creates a commercial product out of it.

Stef · Post by **Stef** » Wed Jan 15, 2014 10:12 am

I understand your point, it would be a shame to have problems because of that

Maybe better to put that aside still it is interesting to see how it performs compared to others compression format

Now i am thinking of it, i have to be sure that aplib packer is totally free as i'm using it in SGDK and i really want to keep it

kubilus1 · Post by **kubilus1** » Wed Jan 15, 2014 8:00 pm

Especially if someone creates a commercial product out of it.

I don't think using SGDK for a commercial product would be a good idea anyways, since it is GPL licensed.

djcouchycouch · Post by **djcouchycouch** » Wed Jan 15, 2014 10:15 pm

kubilus1 wrote:
Especially if someone creates a commercial product out of it.
I don't think using SGDK for a commercial product would be a good idea anyways, since it is GPL licensed.

From what I can find, GPL doesn't prohibit releasing a commercial product. The source does have to be available, though, and I can definitely see why a developer wouldn't like that.

Chilly Willy · Post by **Chilly Willy** » Wed Jan 15, 2014 10:42 pm

djcouchycouch wrote:
kubilus1 wrote:
Especially if someone creates a commercial product out of it.
I don't think using SGDK for a commercial product would be a good idea anyways, since it is GPL licensed.

From what I can find, GPL doesn't prohibit releasing a commercial product. The source does have to be available, though, and I can definitely see why a developer wouldn't like that.

Some do, and some don't. I don't mind open source at all. Nearly everything I do is open. It's the company beancounters and lawyers that generally insist on devs not doing open source. They feel that every single last thing must be "monetized" to the greatest extent possible, and that secrecy is the best security... even though it's rarely secure at all.

I look at Carmack as a great example of open source. He's released every version of his code since Wolf3D the xmas following the release of the next engine. He keeps the beancounters mostly happy, while still making fans of his older stuff ecstatic. There's no way one dev/company can make a game for every platform, so releasing old games as open source allows others to convert the games. It keeps interest in the older games, and hence the company, active long after the game has lagged in demand. Fans can make bug-fixes, add features, and port to new systems while the companies goes on to the next game.