The Sinclair QL Forum

RWAP wrote: a) Why do you need to compress the screens? Is it to fit it on a floppy disk - or is the game going to run from HD disk or SD / CF card?

The game will run from HD/SD/CF card - there are no space issues there. And it will probably fit on a DD floppy or 2, in worst case scenario.
But I want the game to also run on vdrive QL and space is at a premium on microdrives. Artwork alone is 485k - so I need to compress it.
I can split the screens on 5 mdv_images, but this leaves little room for the program, fonts, texts etc., as not all users have vMap, and so are limited to using only up to 6 mdv images at a time.
Well, there are ways around this too, but require to change the mdv image at least once during game play

RWAP wrote: b) Can you decompress the screens in the background - ie show the text input and allow text input, and show the menu on the left immediately and then just load the graphics in the appropriate frame?

No, this is not possible, as most of the time I do not know which one will be the next screen. The user decides where to go next and most of the time he can choose between several locations with different screens.

tofro wrote:You can't get any faster than RLE - It is by far the fastest (and simplest) compression method. If compiled S*Basic is too slow, you'll need to revert to a faster language.

If your picture is really only black and white, you can easily squeeze them into half the space by only storing the green (that is, every other) bytes - the red ones are exact copies of them - and then copying to the red byte positions to give white. You'd need machine code for this, however. Maybe the DIY toolkit's "W" edition can help here, it has machine code functions to do that.

Tobias

I already tried to do that in compiled Basic, but the overall speed was the same as for RLE
I will look at DIY toolkit - thanks for the tip !

(and maybe before I'll start the next program I will be using C again )

If DIY "w" doesn't help, send me a PM. Provided I have a bit of time, I could write a simple SB extension that does what you need - I would assume you're not loading complete screen files.

Tobias

tofro wrote:If DIY "w" doesn't help, send me a PM. Provided I have a bit of time, I could write a simple SB extension that does what you need - I would assume you're not loading complete screen files.

Tobias

No, I am using 360x151 pixels for the images
Thank you !

Excellent artwork Andrew!

Andrew wrote:

RWAP wrote: b) Can you decompress the screens in the background - ie show the text input and allow text input, and show the menu on the left immediately and then just load the graphics in the appropriate frame?

No, this is not possible, as most of the time I do not know which one will be the next screen. The user decides where to go next and most of the time he can choose between several locations with different screens.

You misunderstand - I meant that you draw the screen by displaying hte menu on the left, and the text and input field, allowing the user to start typing, reading and exploring etc.

The screen relating to this particular location is then de-compressed and displayed on screen at the same time (use a background task to do this - even look at doing it in Turbo as a separate job, with FAST used as the compiler option. The main program (which can be compiled in q-liberator if you prefer) then passes the screen number to the turbo task (possibly by poking into a specific memory location).

The user will hardly notice that the full image is not displayed when they start typing....

I had some machine code to do RLE compression, I'll look for it. It should be easy to further optimize it for B&W images.

Daniele

Andrew wrote:P.I. Cole - noir detective game - in development
Graphics are ready. It was a pain in the back to create some (passable) artwork on PC that still looks good on he QL because the difference in pixel sizes.
Well it's ready now - some screens are ok, some might have been better
Now working on the texts and dialogues

Wow!!!

So It can works on real QL too, right?

Outsoft wrote:
Wow!!!

So It can works on real QL too, right?

This is the plan - to work on real QL +vDriveQL (or Trump Card or QUBIDE or floppy or QL-SD)
I am not sure about working on QL with only the 2 microdrives, as it would require a lot of cartridge swapping - I will test this when the program is fully working

tofro wrote:If DIY "w" doesn't help, send me a PM. Provided I have a bit of time, I could write a simple SB extension that does what you need - I would assume you're not loading complete screen files.

Tobias

I made some tests using DIY volume W - windows_code and it works like a charm !
The screens were compressed to 51% and the loading speed is ok for unexpanded QL
Thank you for the tip !