SpritesMind.Net

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

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

Interesting fact about UMK3 archives 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

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?

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?

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

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.

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

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?

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

almost. beware.

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.

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.

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

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.

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.

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.