Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #1212

Playing With Packbytes in C

Show all headers | View raw

I realize that to many PackBytes encoding is yesterday's news.

But when I set-out to write my own PackBytes encoder from the ground-up in 
Ansi C so I had something portable to use, I found myself in a constant 
state of revison for a couple of weeks (part time coding) to get something I 
liked well enough to put my name on it.

Part of my problem came with the general inflexibility of the format when it 
cam to encoding fully saturated palettes in an APF file. And yes I am aware 
of Brutal Deluxe's work with LZ4.

http://www.brutaldeluxe.fr/products/crossdevtools/lz4/

But my goals are to learn this stuff from the ground-up. As a result, I have 
a working and scalable PackBytes encoder for ctreating APF files that I will 
be writing-up, and the source will be made available under Creative Commons.

I do have one question. Has anyone seen a need for including Mask 0x80 - 
repeats of 4 bytes in PackBytes? To my way of thinking, this seems to have 
no place.

The following, while quite inefficient in a highly optimized palette, have 
their place...

Mask 0x00 - 1-64 repeats of different bytes (singletons)
Mask 0x40 - 1-64 repeats of the same byte
Mask 0xc0 - 4-256 repeats of the the same byte in Quads

When mask 0x40 and mask 0xc0 fail to encode optimimally due to a badly 
segmented line, the line can be encoded as a run of singletons using Mask 
0x00, adding 3 bytes of expansion for a typical SHR line of 320.

This is, after all, not a hihly optimal method when generally compared to 
Pictor or Z-Soft PCX encoding except on long runs which enable quads to be 
used.

Pictor with its ability to encode within Masked scoped blocks is perhaps the 
most efficient, and PCX with its unmasked single bytes (except for 0xc0) is 
good generally.

It would be easy to combine all three formats into an encoding scheme that 
offered somewhat better encoding, but using one'e time and effort to produce 
yet another encoding scheme would seem to be better spent on implementing 
LZ4 compression in oner's own utilities.

But this was done as part of a larger project with Imagemagick to produce 
files larger than the SHR screen, in something that should be compatible 
with the old programs.

It is only on the seemingly inefficient encoding of repeats of 4 different 
pixels that I scratched my noggin and wondered why this might be of any use 
at all.

It is therefore not included at all. It seems like utter nonsense to me. Can 
anyone shed any light as to why it is there? I have some pretty detailed 
reasons as to why it is a joke.

Thanks for any insight.

Bill
 

Back to comp.sys.apple2.programmer | Previous | Next | Find similar | Unroll thread

Thread

Playing With Packbytes in C "Bill Buckels" <bbuckels@mts.net> - 2014-04-09 20:46 -0500

csiph-web