Console Dizzy is quite clearly tile based for both graphics and collision. If I recall, Dizzy himself is three tiles high and when crossing a tile boundary may walk left or right provided that both of the top two tiles are clear. If he ends up with a tile overlapping his bottom third then he's pushed up one pixel/frame (or, possibly not exactly that number, but you get the point), to give a sort of soft boundary. Then if you're moving up a hill or whatever, he moves smoothly rather than hopping up a tile at a time.
In the little PC Dizzy thing I wrote, that makes everything as simple as grab the up-to-twelve tiles that Dizzy is currently overlapping (he's two wide, so if not aligned exactly with the background may cover up to three tiles across and four tiles down), then make a decision purely on the coverage of those. If he has come to overlap somewhere with the top two tiles on his left or right, or any tiles above him then he gets an instantaneous push out of those blocks. If his feet are covered then he gets a soft push upwards. So there's no continuous state for collisions beyond his current position. And if he's rolling then he stops only if at the end of roll, with his feet on the ground. It's simple and super robust, while still being accurate to at least one real Dizzy. I guess that the same general stuff applies as you scale down the tilemap (all the way to 1 pixel, if you want), just the constants that go up. 256x192 1bpp would mean that an over/under mask doesn't fit onto the same page as a collision map and the framebuffer, so assuming it's better to keep over/under and collisions in the same format so that code is smaller and neater, I guess you want over/under placed immediately after the framebuffer and duplicated across both video pages (as you'll need it when drawing, and that makes paging easy), the collisions map placed somewhere else, with just one copy? Samflate will definitely get us off to a good start with graphics compression, as deflate is the main complicated part of it. The rest of it is just the linear predictor that dictates one of a small number of ways of predicting the next pixel (based on simple sums of the pixel to its left, the pixel above it and the pixel to its top left) and then stores the amount by which the prediction is wrong, the stream of those quantities tending to compress a lot better than raw pixel values. Quite probably Andrew's code will end up being 90% of the code for screen decompression. Or maybe 100%, depending on how well vanilla deflate does on the Fantasy World Dizzy map. Andrew's code comes with a pyz80 makefile, so that's the immediate candidate. I was planning to move my 3d stuff to Jam for the macros, but I guess Comet doesn't support those anyway? If we're saying Comet is the syntax and both Jam and pyz80 superset Comet then I guess it's academic which we use and we needn't even both use the same... On Thu, Jul 22, 2010 at 12:36 PM, the_wub ! <the...@gmail.com> wrote: > Yes, Dizzy seems to have near pixel perfect collision, at least for > defining the terrain. I thought the bitmap would be 256x192 bits; > 0=empty, 1=solid? that would be 6144bytes per screen. >
