malikto999 escribió:First of all, if the original screen resolution is 256×192 and ported to FM-7's 640×200, I think that it is good to create pattern data with the original size and double it horizontally when displaying it.
That will save memory.
I have already done this but sloooowly with basic, just to verify the idea works.
As our Dragon screens are black and white 8 pixels on every byte at 256x192, I have doubled every bit so that a byte
occupies two bytes on the FM-7 VRAM giving 512x192, the image shows really great!
But the game has over 12 screens and the main characters changes from one to another very fast on the Dragon (just moving/loading 6144 bytes)
To do the same on the FM-7 I should load 16k to the main CPU RAM and then transfer it to VRAM, don't know how fast could this be.
If I have the time I will make a test.
As I wrote before, I think that the main side is better where to put the pattern data.Transfering every time you draw a pattern
does not affect speed.
If you just want to put the pattern on the sub side, there is also a way to put the pattern data in one plane of the VRAM.
In this case, the number of usable colors becomes 4 colors. It will look like an old Apple II game screen.
Set the color palette so that the plane of the pattern data is not displayed on the screen.
In this method, if it is combined with the console buffer, an area of 20KB can be secured.
Well, most probably we 'need' to learn a lot about that computer. On Dragon, to move the character we have 3 images that are
shown onto screen say 1-2-3-2 being 2 a static one and 1,3 images that give movement 'feeling'
These images have been preprocessed so that the part of the pattern that is *not* the character has value 0 so that is not 'added' to the
background image where the character will be superimpossed. Besides that one, we have another pattern which is almost the negative
of this one, it has zeroed the character bits.
Then we get a byte from the screen, AND it with that last mask and then we OR the result with the first chunk, the result is the character
over the background without losing any detail. For each movement we do that 4 times as I have said it moves 1-2-3-2
These chunks are big: 4x56 bytes on the Dragon, so will be 8x56 on FM-7 this means 448 bytes per chunk = 896 bytes per step (1-2-3)
and the global will be 2,688 bytes for the three steps. And still we need a similar area (448) to save the contents of the screen to restore
it while the character is moving .... some 3,136 bytes for only one char moving along the screen
I know this is an extreme case because 'normal' games will have smaller characters moving on the screen, but this is an adventure game
where characters are quite big ...