Ralf wrote: ↑Tue Feb 13, 2018 11:01 am
Nice to see you progressing.
32x192 pixel tiles? Rather not seen in real games as it would be ineffective. Please notice that you are storing a lot of the same data again and again - sky, pavement, windows.
Check how much memory you need for your tiles and how much you would need if you did it the same screen with 32x32 tiles.
But just for fun it's absolutely all right
Yes I really need to learn more memory efficient techniques, it seems to be a straight trade off in many cases between speed and memory efficiency.
I was thinking to use a bank of microdrives to store the slices (well calling them from the microdrive memory buffer) I would have to test it but I think it would work.. (I was getting desperate
) But doing it that way makes anything but a lords of midnight style wait while I process the game loop possible.
One thing I would like to do is learn masking, to be able to do it really well. I think then that will greatly improve what I can do with the screens and reduce the memory required but at the cost of a little processing speed. Still its a nice trade-off to have I think, and it reduces the repetition with the slices.
Doing this really made me appreciate why I need to learn new skills. The modern colour libraries for the spectrum would be the next logical step as monochrome is something probably best left in the past
Joefish wrote: ↑Tue Feb 13, 2018 11:07 am
It'll be fast, but they'l be a lot of repetition (and big blank bits) within each slice, so it won't be very memory-efficient.
I would suggest a set of 32x8 pixel blocks, then make your slices as a stack of just 24 bytes that point to those blocks. That way each screen is made of 8 slices, and each slice is made of 24 blocks.
And here's a trick for storing those 32x8 blocks. Limit yourself to 64 of them. Then store them as a horizontal row, 256x8 pixels, storing the top pixel row of all the blocks first, then the next pixel row, etc. And start them off in memory at an address divisible by 256. Now you can pick any 32x4 block out of the row with a number 0..252 (i.e. 0..63 x 4). And step down through the pixel rows by adding 256 (i.e. add 1 to the high byte of the address).
Now you pick your slice, look up the 24 blocks that make it up, where each is a byte. That byte is the low-byte address of the start of your 32x8 block, so just combine it with the high byte of the first address. Now copy four bytes from there to the screen. Reset the low byte to the block index and add one to the high byte to get to the next pixel row and copy another four bytes, etc.
Also, if you design your slices to be a bit taller than the screen, by using 16-bit addresses to point to them, you can tweak the address by a byte or two, and the slices will appear higher or lower on the screen than their neighbours, for e.g. different road widths.
Yea the memory inefficiency was me being lazy in building the screen, I should have learned to do masking better and/or clever tile selection.
I should really be learning to do both. Those are some interesting tricks I will need some time to have a play with them and see how it turns out thanks for the tips.
My thinking was because there was no scrolling, I could use compression and just store the tiles slices on something like the microdrive. Then just copy in the tiles as needed to the buffer... But that would still take a lot of space.
I will experiment with all these suggestions, it seems that your 32x8 tile method would produce some nice effects in addition to everything else.
Like I said before with Ralf I need to learn masking properly to really progress now so I will spend time with the books/tutorials and apply them to both your advice and hopefully make something better.
Cheers!