I think it's already been covered, but the Spec256 approach is to run an emulation where each bit of memory is handled as a byte instead. That way, a 1-bit pixel in the emulated screen memory is actually an 8-bit colour index.(REMEMBER you'd need colour #1 to be 'black', as colour #0 is 'transparent' or a zero bit).rg_software wrote: ↑Sat Jul 13, 2019 7:37 am I am not really familiar the details of with Spec256 approach. I mean, I know that it emulates a sort of "shadow graphics processor", but I neither know the details nor can estimate how hard is to to something similar.
When emulating the Z80, you use the zero/non-zero status of a bit as 0/1. But when building the screen display, for each bit of pixel data you ignore the attribute, consider the 'bit' to be its full 8-bit representation, and look up its colour in a 256-entry palette.
Now my suggestion, to improve things, is you have a palette that is partly fixed, and partly dependent on the current attribute.
The fixed part of the palette is the first 224 colours.
Then there's a palette of another 256 colours. Each holds 16 variations on each of the 16 spectrum colours (including BRIGHT / DARK BLACK).
So the palette for a character cell consists of 224 base colours + 16 variations on the INK colour + 16 variations on the PAPER colour from the current attribute.
This allows sprites to be partially recoloured depending on their current attribute, as much or as little as desired. So for Manic Miner, your penguins could still have an attribute-dependent body-colour. But for something like 3 Weeks in Paradise, with its horrendous colour clash, you'd just use the fixed colour palette.
Most sprites are stored in a simple linear fashion, or a slight variant of it. Variations include alternating bytes of sprite / mask, or alternating rows, or alternating frames of sprite / mask; reversal of byte order, reversal of row order, reversal of every second row; sometimes pre-shifted with animation. But this is what the smart routine is for - to recognise the repeating shapes in memory and identify the start and end of individual sprites; which ones are similar enough to be considered animations, etc. And all done from a memory snapshot, so it can take as long as it wants, and accept hints and prompts from a user to guide it.rg_software wrote: ↑Sat Jul 13, 2019 7:37 am Furthermore, I am not entirely sure that the sprites are stored in the memory in the same format for all games. We know exactly that when a certain picture is displayed on the screen, it has a predefined pixel structure. When it sits in memory, it can be literally anything stored in the way the authors wanted. For some games with large sprites (like Popeye) I guess there are maybe no complete sprites at all, just separate sprite pieces later combined into a character on the fly. So in order to recolor such sprites one would need to guess these pieces and process them separately.
If sprites are stored as UDGs, with a second table to organise the UDGs into a large object, then you're pretty much stuffed. But a huge number of games could be tackled with only a few simple variations from linear storage.
You wouldn't even have to identify attribute data, as with my suggested approach sprites could be partly re-coloured by their original attributes, or with no respect to their attributes at all, as the designer wishes.
Thanks!
