?!? I still fail to see the point, aah might be b'cuz I'm the next town idiot.

I made a Background for The Revenge of The Last Dragon (gfx9000) that is about 512x384 pixels big.
After fishing out some empty air tiles and some puzzling it fitted into two 256x256 screens, wich
I saved and loaded for testing, all uncompressed but on pc (no diskimage) so no significant load times.
But it could olso be done in smaller files, but then you got a bunch of files and during development
you want things to be easy and my own made drawing stuff does support only those 256x256 format
(or 256x2048x64color, 256x256 can be saved as 16color).

Quote:

yeah, but WHY would you? MSX can't display the picture in total again, if it's game data USE TILES. not 1 big background. get it?! it's waste of space/time/effort/whatever/i'mjustbabling/coffeanyone?/

because in each level I use graphix which are stored in page 1.
These graphix are copy-pasted to page 2 and page 3 (my game page)
So all the storage is in page 1, which is 32kb big...
so IF I use page 1 for storing grapx data then I'd like to use the entire 256x256 of that page in stead of 256x212.
It's just a bigger storageplace,
(page 1 is for storage of graphix, and will never be visible)

Quote:

Drawing 256x256 screens are handy when it comes to drawing big things or 256 16x16 tiles... i love the workspace. But when it comes to storing and compressing it would be smart to compress a picture in 16 kb blocks, unless you use some other compressors that de-compress directly into VRAM. You know those 16 kb blocks of data can still be saved in one file or whatever you want.

like when i want to store those big ugly endbosses????
So, tiles in VRAM.
endbosses and big pictures compressed in RAM???

Quote:

like when i want to store those big ugly endbosses???? So, tiles in VRAM. endbosses and big pictures compressed in RAM???

I think it is best to keep those tiles and endbosses both in VRAM.
You could keep stuf compressed in RAM to avoid some disk operations
(like a big loading... picture).
Or the entire game if you have enough memmory.

Quote:

like when i want to store those big ugly endbosses???? So, tiles in VRAM. endbosses and big pictures compressed in RAM???

I don't know what big ugly endbosses your planning, but keep in mind that the maximum end-boss size you could copy in a single int is something in the order of 72x72 pixels. That's assuming you do the thing as one big HMMM copy... (so no TIMP) Keep that in mind before you start drawing them banjos!

so I have to decrease the image sizes to 50% then !!!, but.....
DAMN not the Banjo.....
And when on an msx (with dd-graph for instance) you change the image size to 50%, the
pictures start looking ugly.
e.g. : minimizing the size of mr. Jacko will mess up his beautifull face !!

Don't you use the scroll regs for the boss movement (with a nice black background)?
But even if you copy the bosses it does not realy matter if it is at a lower framerate
than your ship movement. With pageswap you can keep player movement on 60Hz
and boss movement on 15HZ, or any number depending on how much time you need.
(above case asumes nonscrolling bosslevels otherwise thing get tricky if not imposible)

yes i do use the scroll regs for the boss.

Using a RLE compression method you can easily do direct file to VRAM or RAM to VRAM decompression. Of course, the compression ratio would be worse than BitBuster. But if your graphics use big masses of the same colour, it is an option to consider.

Just in case you want to test it, download http://www.robsy.net/asmsx11c.zip - in the package you'll find a tiny tool, RLEPACK.EXE, and also two different depacking algorithms with source code (RAM to RAM and RAM to VRAM). Easy to use and fast, but not very efficient. Every cloud has a silver line.