With foreground, middleground and background you'd be defining graphics which the sprites don't interact with and which they move in front of (that's the background), graphics which the sprites do collide with (the middleground; everything the player actually walks on/against/etc) and graphics which the sprites don't interact with and which they move behind of (everything in the foreground). So it's just a way of describing what's in front of and what's behind the player and what the player actually walks on (which I guess also would be nominally behind for drawing purposes, though overlap should be relatively limited).
I've no idea how large a single screen will be on average... as I say, it looks likely we could get an entire existing game into memory from PNGs downloaded, but it's probably worth thinking of the PNG file size as an absolute best case. The PNG decompression algorithm doesn't look too taxing, which is why it's a good comparison — we're benefitting from lots of clever people having already addressed the problem and fully documented their solution. If on-screen objects can be in front of as well as behind the player then we can't embed collision information in the screen graphic, since e.g. if Dizzy walks behind a large tree then we have no way of knowing what he's walking amongst short of dedicating an entire bit to it and cutting the map palette to 8 colours. Though if we were to cut the map palette to 8 colours then I'd think the spare bit would be better used as a sort of lighting marker. Split the palette into a light half and a dark half and write the sprite routines to set e.g. the three lowest bits but preserve the top bit and we can define areas of light and shadow for the sprites. Just a thought, probably not worth following up. So, ummm, I'm not sure what you want to do about that. One solution that fits the hardware well is: (1) screen buffer, standard format (2) collision buffer, 1bit buffer, bit set for solid, bit clear for empty, half width resolution, so 128x192 for 3072 bytes total (3) in-front/behind buffer, same format as the collision buffer Which all together make exactly 30kb, pleasingly short of a page. The good fit is that using half-width buffers for (2) and (3) aligns those with with byte boundaries for pixel plotting. Both pyz80 and Jam are supersets of the Comet syntax, but I'm not sure what tools would be used to actually convert source back and forth (since I think it's stored tokenised on the Sam?). The source for my old Dizzy thing is at http://members.allegro.cc/ThomasHarte/files/dizzy/DizzySource.zip and relies on SDL, SDL_image and DUMB for music. It's also a few years old, so likely horribly formatted and barely commented. It's only recently I've started doing this for a living. There's a built OS X binary at http://members.allegro.cc/ThomasHarte/files/dizzy/DizzyOSX.zip. If you build and play then there's the Crash mini-Dizzy followed by some other stuff I was experimenting with. And it's all tilemap based, because I can't draw for toffee and was just messing about anyway. The Nes Dizzy probably isn't the one to go for with all its complicated scrolling and minigames, but I've always had a soft spot for Fantasy World Dizzy. Fancy giving that one a go? On Thu, Jul 22, 2010 at 10:33 AM, the_wub ! <[email protected]> wrote: > The Nes Dizzy I've seen is the first one, Dizzy the Adventurer. I'd > forgotten how good it was, even without an energy bar.. > > So what size can a single 24kb screen compress down to? Hand drawn > screens would be amazing. > I've never used 1 or 2 bit tile maps for collision before so it would > be great to learn this. I couldn't immediately see how it could be > generated from the screen image itself though. For the test I would > have sacrificed colour 0 for a duplicate black to out-line solid > objects with. Collision could be detected from just the screen image > itself but the collision tile map could be generated from a screen > like that too. > > I'm not sure why there needs to be a foreground and background if the > screens will be hand drawn? I was going to arrange the palette so > several colours could be variable too, would this be a problem? > >> 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 wouldn't have a problem with that.. > >> 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. > > I'm familiar with SDL so that would probably help a bit! > > I don't know what to say about the assembler option. I'm working on > the real hardware and with Sim Coupe and I really want to carry on > doing so at it is tremendous fun :) That said I can see the benefit > of working with modern tools so maybe some sort of compromise could be > reached? > > As to the screen format you propose, as I barely understand it and am > potentially about to learn some very useful stuff from it I think it > would be churlish to object! > It would be good to establish what is on the table though. I'm just > looking at how the Nes graphics translate to the Sams screen. ST or > Miggy gfx look funny with the horizontal stretching and the Nes has a > larger vertical resolution. Using the Spectrum screens as a starting > point might be a good way to go but I need to do a bit more > experimenting first. Also are we talking about porting a specific > game or creating an original one? If original then the remit for the > graphics changes dramatically. I would be more interested in remaking > a specific version and then moving the objects to create a variation > of the original. > This could be an inital goal though. It would be easy to go back > and make an original game later on using the same code and in the long > term I think that would make the project more approachable for me. > > Rob. >
