Hmmm, gmail shows that my previous email was sent twice. Apologies to all if that happened, I'll check it isn't happening repeatedly and if it is then I'll try to figure out why. I am perfectly happy saying things just once...
I think there are three for the Nes, but the other two are just ports of Treasure Island Dizzy and Prince of Yolkfolk and I'm not sure if they were released here. I've looked into PNG more, and it is actually realistic to use exactly that algorithm on a Sam (albeit that there's no need to be identical in byte streams) — it's just a linear predictor and LZ77 + Huffman on the end. With that in mind, I've downloaded some of the classic Dizzy maps from those places that tile screenshots to produce game maps (in their Amiga versions) and they're all sub 400kb. Most would even fit into 256kb. So, I'm not sure what sort of art burden it creates, but I definitely think it's feasible to do a Dizzy game on the Sam that doesn't use a tile map, but rather has each and every screen hand drawn, which could look fantastic. Adding 1 or 2bit tile maps for collisions shouldn't be a memory killer. Probably automatically generating a collision map from the source art is easiest? If the designer can save out three layers — a background, middleground and foreground then an external tool can auto build a collision map for the middleground then composite the three to store as the actual screen (so it's one graphic + one collision map in game). Though if we have a foreground then I guess we need a pixel mask somewhere for sprites, which costs yet more bytes. That all being said, it's a disc-based machine so multiloads aren't a problem, are they? I vote aim high and break the world into chunks if we overshoot. I wrote a little Dizzy engine for the PC once, but have never built it for Windows (it's SDL) and was based on the PC sprites and metrics on a scrolling tile map. So it's not directly useful. Probably best to agree an assembler (I'm fine with pyz80 or Jam) and what information you need for screen management, then I can dash off and have a go at some of this screen compression stuff, hopefully to be slotted onto your test screen? How about two pages for the current screen, each filled with the same data by the screen decompressor, which is (in order): 24576 bytes; normal screen image 6144 bytes; mask image — bit set = that pixel is in front of the character sprites, bit clear = that pixel is behind, same bit layout as a Mode 2 screen 768 bytes; collision tile map. 32x24 entries, each a byte in length, linear left-to-right, top-to-bottom as per Mode 1 attributes. Just use 0 = empty, 1 = solid for now? Then there are 1280 spare bytes which my code explicitly won't touch, so anything you would use for cleaning up can go in there. On Tue, Jul 20, 2010 at 8:19 PM, the_wub ! <the...@gmail.com> wrote: > The only console version I know is the Nes one and I haven't explored > it much.. I'm more familiar with the ST versions but the two are not > too far apart graphically. I wouldn't like to have to design as many > levels as you could possibly fit in though! ;) > > I'd like to have a go at re-creating the Nes sprites and movement > routines on a test screen. If I got something like that working would > it go some way towards helping if combined with more graphics and your > map ideas? >
