Actually, late night spurt — with Huffman trees it's 5,528 bytes and 6,653 bytes respectively. No predictor yet. The former technically beats the PNG size, but I'd imagine that just means the predictor is barely going to help and I'm gaining a small win by not including any of the normal file padding or headers. Or even the palette.
On Tue, Jul 27, 2010 at 11:47 PM, Thomas Harte <tomh.retros...@gmail.com> wrote: > Further to this: I've been playing around with it today using a couple > of the more complicated screens from that Amiga map which didn't > feature the watermark (since it's an alpha transparency, causing the > number of colours to skyrocket), resized to 256 pixels across (which > makes 141 pixels high). For a sensible lower bound on what I should > expect, I saved them as PNGs and ran them through OptiPNG, PNGCrush, > and AdvPNG, keeping the smallest version. > > The first (Dylan and a tree) is 5,553 bytes as a PNG. The second > (featuring the Armorog) 6,108 bytes. > > In my quick dash at compression code, I implemented just a trivial > little LZ77, using an exhaustive search to pattern match and treating > each scan line as a completely separate thing to compress (and, as a > result, rounded up to the next full byte). Five bits for a literal, 17 > for a back reference, the native addressable thing being a nibble. > > From that, I got 6,080 bytes for the first screen and 7,170 for the > second. And this is without yet implementing a Huffman tree (probably > best done per screen) or any sort of predictor. > > So, it looks like on a 16 colour display the LZ77 may actually be the > most of it. In which case it's going to be hard to support the > conclusion that PNG is massively better than the various common > techniques when the Sam was a going concern. A Huffman tree is an easy > win and something I'll experiment with tomorrow hopefully and a > predictor is a useful addition even when dealing with hard edged low > colour graphics because it introduces the second dimension as a going > concern whereas LZ77 has no concept of that. > > Would it be possible to get a single screen hand prepared to be really > beautiful rather than ripped from a tilemap? > > On Tue, Jul 27, 2010 at 10:46 AM, Stefan Drissen > <stefan.dris...@gmail.com> wrote: >> Fair enough. You could of course create PNG tiles so that you do not need to >> Flash! anything. You could then even also use a 256-colour PNG image as map >> editor, the colour determining the tile... ;-) >> >> Flashback would be very cool - on the PC I don't remember it having >> scrolling. You would however also need to create an animated PNG / MPEG >> player for the animated sequences. >> >> Lots of fun things to do... :-) >> >> -----Original Message----- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >> Behalf Of the_wub ! >> Sent: Monday, July 26, 2010 19:21 >> To: sam-users@nvg.ntnu.no >> Subject: Re: Dizzy (was: Porting spectrum games...) >> >> If png's can be used then I think we should do it even if using an >> image of tiles is a bit ironic! It would allow changes to be made to >> the image in the gimp rather than flash! if nothing else! ;) If a >> success, I don't dare to dream about scumm but another possible port >> would be Flashback, I can't remember how much if any scrolling is in >> there but something would be possible if pngs could be used as source >> gfx... >> I don't know enough to comment on the feasibility of it all but I do >> have a question, why use the PC bitmaps and not the ST? The Atari is >> already 16 colours and it would be easy enough to fancy them up a bit, >> make them a bit less tiley.. I'm saying this without having a good >> look at how the PC gfx would work in 16 colours though... >> >> Hey Warren! I'd guess that whichever direction the project goes >> there'll be tons to do. The more the merrier I say :) >> >> >