next »

[DrDerekDoctors]

Hey, don't forget about endianness, you jerks.

Bloody Mac users.

[DrDerekDoctors]

Yuss, assuming you go with a 7-bit counter and 1-bit data configuration, then as long as your runs of colour are longer than 8 pixels on average, you'll save data over a regular 1-bit bitstream. However if it's gonna' have really long areas of solidity, you might want to go a longer 15-bit counter and 1-bit data configuration. Or if you want to be really clever about it, go with an n-bit counter and 1-bit data setup and bitstream that. Although that's possibly overkill.

Obviously the moment you decide that you'd like to have some concept of grades of damage to the landscape, most of the advantage of RLE will go pissing out the window.

[Chris Whitman]

If you're using an 8 bit RLE scheme, it would only be inefficient if your average run was shorter than eight. Even if you were taking chunks out of the landscape, you're still preserving average run length because you're reducing black and adding white. Lots of big runs of white are still going to mean very efficient encoding. Remember that, even if it's locally inefficient at one or two points, it could still be globally efficient.

The worst case would be one bit on, one bit off, one bit on, one bit off, etc. Somehow I don't think that is likely.

[PoV]

Screw the 1 bit data part.  .  Just alternate colors A and B (0 and 1), and use that bit for longer runs.  Zero is your magic run length that puts nothing down (255 0 138 for 393 pixels of color A).  And if you really want to be special, make 255 a magic number that notes the 2 bytes following are a 16 bit run.  This is nice because it's the same size as having to throw down a 0 for a longer run, but you gain 16 bit resolution as needed.

And if you will have higher detail short runs, you could use nibbles.  4 bit 0-15 for color A, and 4 bit 0-15 for color B, all packed in to a byte.

[Alec]

You don't see many games being developed for the Atari 2600 anymore...

[Lancer-X]

Nowadays, unless you're truly storing an insane amount of very specific data, I wouldn't be too concerned about agonising over your own home-cooked compression methods. Just shove the whole thing through DEFLATE and be done with it. Most byte-wise redundancy will be eliminated by the LZ77-style dictionary compression, and the bit-wise redundancy by the Huffman compression that follows it.

[Chris Whitman]

It's not really a huge deal; I just figured that with all that fairly homogeneous data, you could save a little space with relatively little effort using RLE. Alternately, you could just use an image format like PNG which already uses DEFLATE.

I just figured, you know, it's a good learning experience for a beginner to try coding possible solutions yourself and all that.

[Lancer-X]

Yes, it is true that you save some data (sometimes vast amounts of data!) using RLE, depending on what the data is like and exactly how you RLE it. (for example, if you have a tile-based game with multiple bytes of data per tile, it may be more efficient to store them planar and compress each plane). However, the point is that you essentially have to spend extra time thinking of something that is a trivial concern. The extra overhead involved in inflating the data is almost unnoticable nowadays (even consoles like the GBA have built-in lz77 and huffman compression code in the BIOS), you don't have to think about the data you're compressing that much to get modest savings and in the end you save a lot of time not worrying about fancy storage methods, and can spend the time actually getting the game made =p

[PoV]

You don't see many games being developed for the Atari 2600 anymore...

Well excuse me princess. 

[Alec]

Huh?

[PoV]

http://www.youtube.com/watch?v=FPxY8lpYAUM

[Alec]

Huh?

[PoV]

I assumed you were mocking the need or interest in bit packing/RLE compression.  Else I'm completely lost on the Atari comment.

[Alec]

I'm completely lost on the Atari comment.

Well excuse me princess.   

[PoV]

Gah... defeated again.