It is where video data is stored. All graphics and character animations (sprite data). The RAM is too precious to use it for video data. Have to compose the on-screen drawn sprites case.
there is a way to not always copy those 16 colorbytes, "msx2 spritefix".
compare one byte, when it is as expected, save the copy of 16 bytes.
one byte acts like an index, like the P index byte to patterns.
"C mirror array", 32 entries, one entry per sprite.
comparing the index one can save copying the 16 bytes.
each SAT got its own mirror array.
when you got two sats for doublebuffer or flicker, then there are two mirror arrays.
to the rest of the game engine the objects got Y,X,P,C like msx1 without colorquirk.
a special case is when you "render to a colorpattern". when patterns are not static. like when ghostngoblins zombie grows out of the floor.
I wonder why you are short of RAM, you got more than 256 colorpatterns? then need 16bit C indexes.
I already store the current animation-frame pair drawn on each position. If the same then no copy. One byte is not enough because the color data changes for each frame and the 1st byte could be the same, but not the others.
I tested to store the whole animation sprites indexes, but the overhead to CPU for checking is even slower than only checking the frame number and if different copy the whole thing. This is because usually different frames changes most (usually all) the sprites which is composed, so if the frame changes, is usually a waste to check the sprites one-by-one as is very probable they changed. For average the results were is better to check only the animation frame and if changes then copy everything.
And yes, we overpass the size. The number of sprites is indeterminated at start, it depends of what you load for the area.
DarkSchneider: hit9918 means to only store an index into a (up to 256 x 16-byte) table of colour patterns, and only upload the specific colour patterns when the index changes.
Yes but is the same, an index and comparison. Using the animation/frame is better in this case as they are also grouped in batches of consecutive patterns to reduce the number of operations.
Also is very rare that 2 different sprites to share the same color data. At the end simply customize how do you store the indexing to your case.
I mention the mirrors because they work with all SAT topics without problems.
the mirrors can handle sprites that shift their position in the SAT. that's what it got over other mechanisms.
like when a reverse flicker gets into the 33rd sprite. things shift in SAT. with other mechanisms, every new topic is a colorcopy topic. while the mirrors just do it.
Btw, on the (off-)topic of 16-bit I/O addressing, the CPC seems to use it, leading to strange-looking code like this.
Yes, the problem was that, it only works for single IN/OUT instructions, because the INIR/OTIR type also writes the high half of the address bus in any execution.
Probably this could be solved if the system would allow to lock the high-half of the address bus for I/O ports.
In theory the INIR / OTIR value is not completely useless, it allows for auto-increment like I/O to many registers. Think of initialising all VDP registers in one go with the register indicated by the MSB, or issueing VDP commands. Or IDE interface I/O through a 256-byte buffer where the buffer position is indicated by the MSB. Or random VRAM access within 256-byte blocks. But, it’s a bit of a stretch, and requires special-purpose hardware design of the I/O device.
Don't you have an account yet? Become an MSX-friend and register an account!