Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#1 2011-01-30 01:15:00

stag019
Idea Killer
Registered: 2011-01-05
Post 2/630

Yet another pointless RBGY sprite compression thread

Well, just like everyone else here save a max of five people, I can't understand how the compression works.

I know how different the compression mehtods of this vs. Generation II are, but I was at least able to understand how that compression works and write a decompressor.

I've tried doing something similar for this generation, but I'm just still having difficulty understanding it. The other resource besides Tauwasser's documentation was a C program, but I'm not that great at C myself .I was able to edit the program , but I couldn't understand the entirety of what was going on during the decompression part (source here).

Using the program, I was able to output various stages in the decompression that seem to correspond to stages in the documentation, but trying to do it manually, it still doesn't make any sense to me.

Probably the easiest way to explain this to me in a way I'd understand is to simply show me an example. I have Bulbasaur printed out here if looking at that helps. You probably don't even have to go through the entire thing, just maybe 2-3 iterations of each step before I get the idea.

Umm... yeah

Last edited by stag019 (2011-01-30 18:37:41)


You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.

Offline

#2 2011-01-30 11:44:18

Tauwasser
Member
Registered: 2010-10-16
Post 93/447

Re: Yet another pointless RBGY sprite compression thread

It would have been nice if you had labeled the parts accordingly.

1 is the compressed data including the header,
2 is decompressed data in gb format,
3 is the compressed data including the header as bits,
4 is RAM 1 (A188) after conversion
5 is RAM 2 (A133) after conversion

Now, what don't you understand?
When you manually go through the data, you will get the following:

55  BB               13         C4          5D          74          EA           54         ... 77
55  1   0 1110    1100 01 00 11110   00100 01 01 11 01 01 11 01 00 1110    1010 01010100    ... 01 11              0 111 ...
YX RAM ID RLE 0F + 0C  DATA  RLE 1F + 04   DATA                    RLE 0F + 0A  DATA               Interpretation ID RLE ...
        00 groups          00 groups                                 00 groups                     11 = 3

This will produce data for RAM 2 (A133). Go until finally RAM 2 is full. Then it will decide what interpretation of data to use, and fill RAM 1 (A188). If that is full, it will interpret the data and the game will scale the data (since it's a Pokémon picture, therefore the YX values matter, else they wouldn't) and write it to VRAM.
One might also like to call it "composition type" instead of interpretation type. I basically called it that because it is being interpreted multiple times through some tables.

cYa,

Tauwasser

Last edited by Tauwasser (2011-01-31 00:42:32)

Offline

#3 2011-01-31 00:03:35

stag019
Idea Killer
Registered: 2011-01-05
Post 3/630

Re: Yet another pointless RBGY sprite compression thread

Tauwasser wrote:

It would have been nice if you had labeled the parts accordingly.

1 is the compressed data including the header,
2 is decompressed data in gb format,
3 is the compressed data including the header as bits,
4 is RAM 1 (A188) after conversion
5 is RAM 2 (A133) after conversion

It would have been easier to do that if I remembered what all the parts were.

Anyways, if you go to the page now, 6 is my script's attempt at what RAM2 should be (before interpretation and whatnot). For some reason, it seems like if I follow these rules, it doesn't fill exactly 0x188 bytes. Is my logic wrong somewhere? Or my script? Right below the 6 box is debugging information (not as well formatted as yours because it's difficult to format like that with a script). Is anything showing up wrong?


You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.

Offline

#4 2011-01-31 00:51:41

Tauwasser
Member
Registered: 2010-10-16
Post 94/447

Re: Yet another pointless RBGY sprite compression thread

Hi,


Also, I have to admit that my info above was faulty. I got fooled by the way the game counts how many bits are left in the bit buffer (it's bits left + 1, not just bits left). I corrected the example above. Just FYI, I always have a debugger running, executing this menial task so I can easily compare stuff. It's better than counting your own text file by far.

Your algorithm breaks on this line:

RLE Packet: 111110 010101 (3F + 15)

The buffer should be filled after this packet. Now, let's count that out. The width is 0x05. The height is 0x05. Therefore, there are 5 rows times 5 columns per row of 8 bytes each times 4 bit groups per byte => 05 * 05 * 08 * 04 = 0x320.

Now, I counted the bit groups (in your print-out) up until the RLE packet above had passed and got exactly 0x320 bit groups. Therefore, RAM2 is full and the in-between interpretation (or "composition type" whatever) mini-header starts.

cYa,

Tauwasser

Last edited by Tauwasser (2011-01-31 00:58:25)

Offline

#5 2011-01-31 01:58:03

stag019
Idea Killer
Registered: 2011-01-05
Post 4/630

Re: Yet another pointless RBGY sprite compression thread

Tauwasser wrote:

Just FYI, I always have a debugger running, executing this menial task so I can easily compare stuff. It's better than counting your own text file by far.

Well that's a good thing then, that way I'm sure your comparisons will be accurate. If I had a little more knowledge of Z80, and knew how debuggers really worked, I could do that too. Unfortunately, I don't think I have the patience or time to learn it. At least not at this point in my life.

Anyways, I think I got it to load each RAM correctly now. 6 is still RAM2, 7 is RAM1. Now from here, I'm supposed to use one of the three methods (according to my script, method 3). Is all of this right so far?

But how do these methods work now? Go through a few times for one (or both) of the RAMs so I can see how it's done.


You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.

Offline

#6 2011-01-31 17:38:48

Tauwasser
Member
Registered: 2010-10-16
Post 96/447

Re: Yet another pointless RBGY sprite compression thread

Actually, I'm not sure what it does semantically as well. Basically, if you implement just the table look-ups along with the look-behind switching, you will be good. If you find out what sense it actually serves, be my guest to explain it.

Basically the thing that they did is to split the bit planes into planes that contained large strings of zeros since this is a zero suppression run length encoding. However, how they got to those formulas, I'm not sure. One seems to be straightforward the separate bit place-values, one seems to be an inverted bitplane (the XOR part anyways). However, the look-behind table switching...

cYa,

Tauwasser

Offline

#7 2011-02-01 19:29:52

stag019
Idea Killer
Registered: 2011-01-05
Post 5/630

Re: Yet another pointless RBGY sprite compression thread

Okay, but I still don't get how to use any of the table look-ups...
My script says to use method 3.
That says to take 2.RAM (which in this case is RAM1) and use the first method as if there was no mirroring.
So like, after the first set of 0s, there's this:
1011 0100 0000 0100
Which turns into something like...
(5)1 (2)0 0(0) 2(0)
Which then, if I'm using table one, turns into:
C6 16
Or if I'm using table two, it turns into:
39 E9

...I get the feeling this isn't right.


You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.

Offline

#8 2011-02-01 21:46:56

Sawakita
Administrator
Registered: 2010-10-16
Post 85/364

Re: Yet another pointless RBGY sprite compression thread

I have a question (ah, this compression has always been my nemesys, and, I fear, will always be). When it's done with compression it could happen that bits aren't perfect module of 8, so it could happen that the last byte of compressed data requires some sort of padding.

So my question is: is this last byte padded from low to high or from hig to low?
For example if 4 (set) bits remain, will the padded byte be "00001111" or "11110000"?

Offline

#9 2011-02-02 00:18:33

Tauwasser
Member
Registered: 2010-10-16
Post 99/447

Re: Yet another pointless RBGY sprite compression thread

Sawakita wrote:

So my question is: is this last byte padded from low to high or from hig to low?

It reads from hi to lo, so padding would naturally be on the lower end.

stag019 wrote:

there's this:
1011 0100 0000 0100
Which turns into something like...
(5)1 (2)0 0(0) 2(0)
Which then, if I'm using table one, turns into:
C6 16
Or if I'm using table two, it turns into:
39 E9

...I get the feeling this isn't right.

Actually, it would seem that you're still not composing the data right. At least I couldn't find this in the buffer that the game has resulting from mere interpreting the data (without adding the LUT call).

Anyway, it seems I was missing some step of the actual decompression. It actually composes the final picture (after all the steps mentioned) by interleaving the lines of RAM 2 and RAM 1 before putting that into vram.
I've uploaded the full buffers to my site: here.

The files correspond to the steps of interpretation 3:

  • ram1.hex and ram2.hex result from merely writing the stream data to buffers.

  • ram1_unmirrored_1.hex is method 1 on ram1 (unmirrored).

  • ram2_unmirrored_1.hex, method 1 on ram2 (unmirroreD)

  • ram2_xor_ram1_unmirrored_1.hex the second-to-last step of XORing and storing to ram1 in method1 (unmirrored)

  • ram2_ram1_interleave.hex, final result of interleaving the two things.

I thought the compression was done after the call to the "main" decomp routine, seems I was wrong.

cYa,

Tauwasser

Offline

#10 2011-03-09 11:49:50

Sawakita
Administrator
Registered: 2010-10-16
Post 91/364

Re: Yet another pointless RBGY sprite compression thread

In your document at Magicstone, when you explain Interpretation method 1, you say that the lowest bit of each nybble (the 'Y', in the notation "XXXY XXXY") tells which table value's nybble has to be taken: if bit is set take high nybble (i.e. bold values in your document), if bit is reset take low nybble.
Is it possible that you got them reversed? I mean, bold values are used when bit is reset, while non-bold values are used when bit is set?

Here is the code:

;a = metacode to be evaluated [0000XXXY]
;XXX = index value
;Y = nybble flag value

ROM0:276D CB 3F            slr a
ROM0:276F 0E 00            ld c,00                  ;if Y==0 -> c=0
ROM0:2771 30 02            jr nc,2775                  ;
ROM0:2773 0E 01            ld c,01                  ;else c=1

ROM0:2775 6F               ld l,a                  ;l=00000XXX
ROM0:2776 FA AA D0         ld a,(d0aa)                  ;flag for mirroring
ROM0:2779 A7               and a
ROM0:277A 28 04            jr z,2780
ROM0:277C CB 5B            bit 3,e
ROM0:277E 18 02            jr 2782

ROM0:2780 CB 43            bit 0,e                  ;if ==0 -> use Table1
                        ;else use Table2
ROM0:2782 5D               ld e,l                  ;e=00000XXX
ROM0:2783 20 09            jr nz,278e
ROM0:2785 FA B1 D0         ld a,(d0b1)                  ;[$d0b1-$d0b2]=ptr to Table1
ROM0:2788 6F               ld l,a
ROM0:2789 FA B2 D0         ld a,(d0b2)
ROM0:278C 18 07            jr 2795

ROM0:278E FA B3 D0         ld a,(d0b3)                  ;[$d0b3-$d0b4]=ptr to Table2
ROM0:2791 6F               ld l,a
ROM0:2792 FA B4 D0         ld a,(d0b4)

ROM0:2795 67               ld h,a
ROM0:2796 7B               ld a,e
ROM0:2797 85               add l
ROM0:2798 6F               ld l,a
ROM0:2799 30 01            jr nc,279c
ROM0:279B 24               inc h

ROM0:279C 7E               ld a,(hl)                  ;get Index value

Here it is the code that takes high or low nybble of the look-up table's value according to the 'Y' value:

ROM0:279D CB 41            bit 0,c                  ;if Y==0
ROM0:279F 20 02            jr nz,27a3
ROM0:27A1 CB 37            swap a                  ;get high nybble
                                              ;else get low nybble
ROM0:27A3 E6 0F            and a,0f
ROM0:27A5 5F               ld e,a
ROM0:27A6 C9               ret

Offline

#11 2011-03-09 17:51:33

Tauwasser
Member
Registered: 2010-10-16
Post 119/447

Re: Yet another pointless RBGY sprite compression thread

I remember correcting these for some reason to the state they are now. Are you sure the tables are at D0B1 in that order? I remember going "duh" somewhere in there and changing it.

cYa,

Tauwasser

Offline

#12 2011-03-09 22:01:44

Sawakita
Administrator
Registered: 2010-10-16
Post 92/364

Re: Yet another pointless RBGY sprite compression thread

ROM0:26DE FA AA D0         ld a,(d0aa)   ;checks mirroring
ROM0:26E1 A7               and a
ROM0:26E2 28 08            jr z,26ec
ROM0:26E4 21 B7 27         ld hl,27b7    ;Table1 mirrored
ROM0:26E7 11 BF 27         ld de,27bf    ;Table2 mirrored
ROM0:26EA 18 06            jr 26f2

ROM0:26EC 21 A7 27         ld hl,27a7    ;Table1 unmirrored
ROM0:26EF 11 AF 27         ld de,27af    ;Table2 unmirrored

ROM0:26F2 7D               ld a,l
ROM0:26F3 EA B1 D0         ld (d0b1),a    ;save Table1
ROM0:26F6 7C               ld a,h
ROM0:26F7 EA B2 D0         ld (d0b2),a
ROM0:26FA 7B               ld a,e
ROM0:26FB EA B3 D0         ld (d0b3),a    ;save Table2
ROM0:26FE 7A               ld a,d
ROM0:26FF EA B4 D0         ld (d0b4),a

27a7 and 27b7 (= hl) point respectively to Table1 unmirrored and Table1 mirrored.
27af and 27bf (= de) point respectively to Table2 unmirrored and Table2 mirrored.

ROM0:27A7    db $01,$32,$76,$45,$FE,$CD,$89,$BA
ROM0:27AF    db $FE,$CD,$89,$BA,$01,$32,$76,$45
ROM0:27B7    db $08,$C4,$E6,$2A,$F7,$3B,$19,$D5
ROM0:27BF    db $F7,$3B,$19,$D5,$08,$C4,$E6,$2A

Also, I noticed that you put the correct information about meta-code interpretation ("Die Werte, die gelesen werden, wenn Y im Code zurückgesetzt, also "0" ist, sind fett markiert.") in the german version of the document. Chances are that you simply forgot to update the english version as well (not a big problem).

I still don't understand what are the advantages in using these meta-codes, since they're just a "1 for 1" ratio substitution...

Offline

#13 2011-03-10 06:31:05

Tauwasser
Member
Registered: 2010-10-16
Post 120/447

Re: Yet another pointless RBGY sprite compression thread

It seems I switched them twice. English was correct, German wrong and I just switched both of them...

The advantage seems to be in easy mirroring and smaller compression size.

cYa,

Tauwasser

Offline

#14 2011-08-14 07:49:48

stag019
Idea Killer
Registered: 2011-01-05
Post 6/630

Re: Yet another pointless RBGY sprite compression thread

Random bump, but I got some random motivation to work on this again (I quit last time after I lost the files).

Tauwasser wrote:

Actually, it would seem that you're still not composing the data right. At least I couldn't find this in the buffer that the game has resulting from mere interpreting the data (without adding the LUT call).

The reason it wasn't composing right was because I never read the section labelled "The bit groups".

So according to this, the bits are filled like this (for example Bulbasaur being 0x55)
For 40 bytes (5 * 8 = 40), which is bytes 0x00 through 0x27, I fill the first (left, upper, whatever) two bits of each byte? Then, I do that again for the next two, the next two, and the last two. Then move onto bytes 0x28 - 0x4F, doing the same thing, etc. until I completely fill 0xC8 bytes total?

Such a thing is rather difficult to program, but if what I'm saying is correct, then I'll try to figure it out.

Edit: Nevermind, I managed to implement that correctly. I also got the interpretation table working. The last problem (which should be the easiest) is the XORing. The article says "2.RAM XOR 1.RAM is written to 2.RAM". That should be represented by "ram2_xor_ram1_unmirrored_1.hex", right? Well when I XORed 2.RAM and 1.RAM, I didn't get that at all. Like at address 0x89, 0xE7 XOR 0xC3 is 0x24, not 0x5C. Are you doing something else to it?

Last edited by stag019 (2011-08-15 02:08:46)


You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.

Offline

#15 2011-08-15 12:07:06

Sawakita
Administrator
Registered: 2010-10-16
Post 183/364

Re: Yet another pointless RBGY sprite compression thread

stag019 wrote:

Edit: Nevermind, I managed to implement that correctly. I also got the interpretation table working. The last problem (which should be the easiest) is the XORing. The article says "2.RAM XOR 1.RAM is written to 2.RAM". That should be represented by "ram2_xor_ram1_unmirrored_1.hex", right? Well when I XORed 2.RAM and 1.RAM, I didn't get that at all. Like at address 0x89, 0xE7 XOR 0xC3 is 0x24, not 0x5C. Are you doing something else to it?

It's just a guess but maybe 1.RAM (first RAM used) and 2.RAM (second RAM used) are switched, compared to RAM1 ($A188) and RAM2($A310)?


Also, an unrelated question. Before compressing the image you have to convert your planes into meta-codes, but since the process is the opposite than the decompression one, you can't change your original nybbles to the ones stored in the tables ($27a7,...,27bf), but instead you have to find the correspondent value in the table, and THEN convert your nybble to the corresponing index value. Is this right?

For example, if my nybble is 0xE and I'm using table1 unmirrored [01 32 76 45 FE CD 89 BA], is the resulting "anti"-meta-code 0x9 (ID of nybble 0xE) or 0xB (metacode located at position 0xE)?

Last edited by Sawakita (2011-08-15 12:08:45)

Offline

#16 2011-08-15 12:12:44

stag019
Idea Killer
Registered: 2011-01-05
Post 7/630

Re: Yet another pointless RBGY sprite compression thread

Sawakita wrote:
stag019 wrote:

Edit: Nevermind, I managed to implement that correctly. I also got the interpretation table working. The last problem (which should be the easiest) is the XORing. The article says "2.RAM XOR 1.RAM is written to 2.RAM". That should be represented by "ram2_xor_ram1_unmirrored_1.hex", right? Well when I XORed 2.RAM and 1.RAM, I didn't get that at all. Like at address 0x89, 0xE7 XOR 0xC3 is 0x24, not 0x5C. Are you doing something else to it?

It's just a guess but maybe 1.RAM (first RAM used) and 2.RAM (second RAM used) are switched, compared to RAM1 ($A188) and RAM2($A310)

Actually, it appeared that whatever his dump was of was completely wrong on that point, because by doing it the right way, and then composing it, I managed to get it to work! Problem now is, it only works for a little more than 70% of the unique images in the three roms (Japanese Red/Green, English Red/Blue, and Yellow).

Here is an example of my attempt to decode every single one. Note: The page may take 15 or even more seconds to render.

You can also try the yellow or green versions.


You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.

Offline

#17 2011-08-15 16:50:34

Tauwasser
Member
Registered: 2010-10-16
Post 160/447

Re: Yet another pointless RBGY sprite compression thread

I dumped directly from RAM, meaning I did nothing to it. I also made sure that I didn't switch things around. I have to come back to this thread later on, because I'm painfully busy right now.

cYa,

Tauwasser

Offline

#18 2011-08-16 03:29:16

stag019
Idea Killer
Registered: 2011-01-05
Post 8/630

Re: Yet another pointless RBGY sprite compression thread

Sure, take you time. When you do manage to find some free time though, could you try looking at and/or dumping some of the ones that I can't get to work? It seems every back picture works correctly, but some of the front ones, like Venusaur, Pidgey, Nidoking, Parasect, Mankey, etc. (those examples are all red version, but some from every version don't work) won't work correctly, and it looks like it might be for different reasons.

I'm so close though, I can almost taste it! :)


You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.

Offline

#19 2011-08-22 22:45:36

Tauwasser
Member
Registered: 2010-10-16
Post 174/447

Re: Yet another pointless RBGY sprite compression thread

Ok, I programmed it straight down tonight just going by my documentation and it worked right away (after some fidgeting with Java (signed) byte versus int, I admit. I chose Java because I'm a masochist :D)

However, I found out that I could reproduce your problem and that the docu is not very precise for interpretation method 1, cf RHWiki.

Which table is used is determined by the last written 4-bit group. If the group is odd for unmirrored data or greater than 8 for mirrored data, table 2 is used instead of table 1. For the first read value this is 0x00.

More precisely, this should read:

Which table is used is determined by the last written 4-bit group. If the group is odd for unmirrored data or greater than 8 for mirrored data, table 2 is used instead of table 1. For the first read value in each column this is 0x00.

I have a Java reference implementation if you're curious. I also noticed that the final image composition is not really explained anywhere on the wiki, so I might amend this in the future. Please check if this solves all your issues, I only tested a few.

I might also add some semantics to the article, because my understanding of what the compression does actually solidified by programming it once :D

cYa,

Tauwasser

Last edited by Tauwasser (2011-08-22 22:47:56)

Offline

#20 2011-08-23 12:18:33

stag019
Idea Killer
Registered: 2011-01-05
Post 9/630

Re: Yet another pointless RBGY sprite compression thread

Five things:

1. That quote needs one other addition:

Which table is used is determined by the last written 4-bit group. If the group is odd for unmirrored data or greater than or equal to 8 for mirrored data, table 2 is used instead of table 1. For the first read value in each column this is 0x00.

2. I do still have a problem, but I'm unsure if it's your document not being clear enough, or my implementation of it itself. Here is the link to it again. Wigglytuff, Psyduck, Gyarados, etc. don't work. And the problem seems to be with only the very bottom-right two pixels. I just don't get it. :(

3. There is no three.

4.

Tauwasser wrote:

I have a Java reference implementation if you're curious.

Considering how few people still understand this, I say, the more reference material, the better.

5.

Tauwasser wrote:

I might also add some semantics to the article, because my understanding of what the compression does actually solidified by programming it once :D

That's awesome. I'm glad you got the chance to better yourself.


You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.

Offline

#21 2011-09-01 11:30:42

stag019
Idea Killer
Registered: 2011-01-05
Post 10/630

Re: Yet another pointless RBGY sprite compression thread

stag019 wrote:

2. I do still have a problem, but I'm unsure if it's your document not being clear enough, or my implementation of it itself. Here is the link to it again. Wigglytuff, Psyduck, Gyarados, etc. don't work. And the problem seems to be with only the very bottom-right two pixels. I just don't get it. :(

I've figured it out. The last bit-group wasn't being written even though it was read (due to an early return statement).

So now I'm trying to write the reverse. Here's my questions so far: You did say that the best way to do it would be to try every interpretation, and see which one compresses the smallest, right? Also, how do I decide which RAM from RAM1 and RAM2 should be 1.RAM and 2.RAM? Does it even matter?

My other question is about MissingNo. I want to try to get my decompressor to also correctly decompress him. However, from what I understand, there's likely data overlapping other data in order for this to work (which is also why the Hall of Fame get's messed up). Is there any way you could go through his decompression routine and show me how he works? And yes, I understand the reason he's "backwards L shaped" is because his size is 8 by 8 tiles, but he's still laid out in a 7 by 7 grid, so therefore, there's padding involved and whatnot.


You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.

Offline

#22 2011-09-01 19:23:04

Tauwasser
Member
Registered: 2010-10-16
Post 193/447

Re: Yet another pointless RBGY sprite compression thread

stag019 wrote:

My other question is about MissingNo. I want to try to get my decompressor to also correctly decompress him. However, from what I understand, there's likely data overlapping other data in order for this to work (which is also why the Hall of Fame get's messed up). Is there any way you could go through his decompression routine and show me how he works? And yes, I understand the reason he's "backwards L shaped" is because his size is 8 by 8 tiles, but he's still laid out in a 7 by 7 grid, so therefore, there's padding involved and whatnot.

You basically need to find the data that is being compressed, then build in extra buffer checks. Pretty much all the stuff you stated is some mumbo-jumbo from Pokémon sites that don't have any clue, so they just put stupid stuff on their pages. The reason you're seeing what you're seeing is simply because a buffer overflow happens. The decompression area is A188-A498, which is in SRAM. This means that a buffer overflow will overwrite other save data stored in the current bank. Why this is done in the first place and not the faster WRAM is used is a mystery to everybody.

stag019 wrote:

So now I'm trying to write the reverse. Here's my questions so far: You did say that the best way to do it would be to try every interpretation, and see which one compresses the smallest, right? Also, how do I decide which RAM from RAM1 and RAM2 should be 1.RAM and 2.RAM? Does it even matter?

You would need to test that out. However, generally you will want to maximize white pixels in each column. So basically, this goes something like splitting the color planes appropriately, looking for the maximum savings per compression method. You could probably use a good heuristic that will determine if the color planes are worthwhile to try or not. The good thing about this compression method is, that it converges to an optimum. So after you have tried every method, you will definitely have the optimally compressed data, unlike GSC, which requires a multi-pass algorithm for optimal data compression.

cYa,

Tauwasser

Offline

Board footer

Powered by FluxBB