jCalg1 not under x64, I understood correctly ?

[luis]

I read somewhere on the forum, to my surprise, the x64 version of PB does not use jCalg1 for the Packer library.

I know I can use another library, I know thorium wrote a 64 bit version of the unpacker, etc.

I would only know if it is still the case. In the manual there is no mention of this. On the 64 bit version the help file talks about the jCalg1 as the used one.

If it's still true the manual must be corrected, it could be very unpleasant for someone to rely on this info and then discover the data he has compressed under x86 cannot be read back with the x64 version of his program.

[ts-soft]

x64 use briefLZ

[Thorium]

Yes it's true, the reason is there is no 64 bit version of the JCalG1 lib existing.
And yes that should be stated in the documentation.

[Fred]

It should be adressed somewhen, hopefully for the next version.

[USCode]

It should be adressed somewhen, hopefully for the next version.

ZIP compression support?!? (fingers crossed)

[Thorium]

It should be adressed somewhen, hopefully for the next version.

ZIP compression support?!? (fingers crossed)

I think ZLib would be a perfect successor for JCalG1 for nativ compression. It's faster than JCalG1 both on compression and decompression, it have a bedder compression ratio and it's available on every platform.

[ts-soft]

I think ZLib would be a perfect successor for JCalG1 for nativ compression. It's faster than JCalG1 both on compression and decompression, it have a bedder compression ratio and it's available on every platform.

but zlib is bigger than JCalg1 or briefLZ!

[Fluid Byte]

We are just talking about some kilobytes, right?

[ts-soft]

We are just talking about some kilobytes, right?

99,2 KB ZLIB
12,1 KB JCALG1

[Thorium]

We are just talking about some kilobytes, right?

99,2 KB ZLIB
12,1 KB JCALG1

Well you still could use whatever lib you want, but i think ZLib is the best compromise.
The size of the lib will in most cases not make a big difference. The compression in PB seems to be for games primary. So 100KB for the lib are nothing if you save some MB data because of the bedder compression ratio.

And thinking about BriefLZ, isn't it outdated?
The successor of BriefLZ is aPLib. Is there any reason to use BriefLZ instead of aPLib?

I read that a compressor plugin system is planned. So hopefully we will see PB supporting different compressions. LZMA would be very cool for example.

[DoubleDutch]

Fred: I thought the plan was to have compression plugins - like the imageplugins - or am I wrong?

[Fred]

Yes, it's the plan.

[DoubleDutch]

That will be good.

[jamba]

does anyone know the status of this?

ready in version 4.5?

I would like to use the built-in packer for my next project, but I need x64 and x86 compatibility. Until this is verified I'll just use PureZIP, or something of the like.

[Fred]

No, it won't be in 4.50.