Help with RnD data compression

All about creating levels and level sets, custom elements and custom artwork.

Moderators: Flumminator, Zomis

Post Reply
Tomi
Posts: 339
Joined: Wed Aug 03, 2005 3:37 pm
Location: Slovakia

Help with RnD data compression

Post by Tomi »

I need some sort of data compression. First, some definitions used in following post:
"beet" - a storage unit which, when not compressed, can be one of 4 various values (so one beet = two bits),
"bite" - a storage unit consisting of 400 (namely 20x20) beets.
I need an unpacking system that:
- can handle up to 10 bites
- unpacks selected bite in a square (20x20) - each beet on a separate square, expressed as, for example, letters A-D
- does it fast (preferred is max 5 seconds)
Compressed data stays the same during level play. It may be stored in CE changepages (or CE whatever) and/or in playfield, but know the limits (max 256 CEs, max 128x128 playfield).
This task is pretty hard (if not impossible), but I found out some rules that the compressed data normally follows:
- beet values 2 and 3 aren't very common and touch each other only rarely.
- beet value 0 is the most common value, forming at lest 50% of normal bite.
- beet value 1 forms various lines and "passages".
Ideas, anyone?
asiekierka
Posts: 143
Joined: Fri Aug 19, 2005 6:18 am
Location: Poland
Contact:

...

Post by asiekierka »

If you need more CEs, thrn send holger the unfinished level which need >256 CEs and Holger add more into next RND!

And do change every 1 frame in everyplace when you can, then it could be fast.

PS. You do the small decompression system with text input or some other but on RnDFA, use that to do compression :-)
GraphicsPack project: 90%
IconXT project: 100% (version final is ready)
Zomis
Posts: 1502
Joined: Mon Jun 21, 2004 1:27 pm
Location: Sweden
Contact:

Re: Help with RnD data compression

Post by Zomis »

This truly sounds like an interesting problem. However, I must be sure that I understand what you mean first...
Tomi wrote:"beet" - a storage unit which, when not compressed, can be one of 4 various values (so one beet = two bits),
"bite" - a storage unit consisting of 400 (namely 20x20) beets.
So a "beet" is a CE? and a "bite" as well? why consist of 400 beets? was it just a number picked at random or is there any technical reason behind it which I don't see?

So for example, the player should enter 400 beets with values 0-3 (or 'A'-'D'). And then the player presses some button which will 'compress' all these 400 beets into 1 CE ('bite'), which is later uncompressed to these 400 beets again?

Indeed it sounds hard. But I doubt that it would be impossible...

However... I'd definetly need some time to think about it... about a year or two...;)
Tomi
Posts: 339
Joined: Wed Aug 03, 2005 3:37 pm
Location: Slovakia

Post by Tomi »

Beet and bite are just storage units, not elements. However, every beet value has an element representation, for example, beet value 0 is associated with letter 'A'.
Some data is compressed in level somehow. When an event occures (e.g. player presses some button), worker CEs create some elements in main level area. Those elements aren't random, but are the elements associated with corresponding beets in selected bite.
400 is "just" 20x20. I've chosen 20x20 sized area because it's not too small (like 16x16) but also not too big (like 32x32).

I'll try to explain beets and bites more with following example. Now I'll assume a bite contains just 16 beets.
Let's say I have following bite:
0210101011102011
Let's say it's compressed into: N45F
Now, player presses a button, and worker CEs read the compressed form, and create the following letters in main area: (if the elements associated with beet values are just letters 0-3)
0210
1010
1110
2011
Zomis
Posts: 1502
Joined: Mon Jun 21, 2004 1:27 pm
Location: Sweden
Contact:

Post by Zomis »

Ok... I think I understand you... but...
If there's 4 different values on each beet, then there's 256 variations for a group of 4 beets, right? (4^4). How could a variation of 256 be stored in 1 bite that way? The only possibility I can think of is using CE values, is that what you have in mind? Maybe I still don't understand the beet and bite concept... what do you mean by "storage units" and not elements?
Tomi
Posts: 339
Joined: Wed Aug 03, 2005 3:37 pm
Location: Slovakia

Post by Tomi »

Well, I'll try to explain again...
Following example will also use bites that contain just 16 beets, in real world they'll be much bigger of course.
Beets and bites are values, similar to bits and bytes.
They can be compressed to strings of letters (or strings of something). Those strings are stored in level playfield. (There may also be some alternative forms of storage, like CE changepages. However, I'd like it to work in 3.1.2.)
When player requests decompression of some bite, worker CEs locate compressed values and create their visual representation in the "main area" of playfield.

Note that I don't need *compression*, just *decompression*. Bites data are "hard-coded" in the level.
Post Reply