>>> Remember that Aurora screens are different - the bytes per line
>>> increment may not be the same as the number of bytes used to store
one
>>> line of pixels in mode 4.
>Does this mean that the width of a display line as returned by
DISPLAY_WIDTH
>could be, for example, 200 bytes, but in the resolution/mode being
used
>currently, only the first 100 bytes of each display line is being
used ?
>If this is so, then SS3 will snatch all 200 bytes for each display
line -
>this shouldn't be a problem, because the first 100 bytes are being
used but
>the second 100 isn't. Ok, there will be a waste of 100 bytes per
screen line
>on the resulting file, but ......

No, only the top left of the screen on an Aurora is used. You should
only save the actual number of bytes used for the screen resolution
used, i.e. for mode 0 and mode 8, this is pixel_width DIV 4.

Aurora uses the entire 128K of video memory in most modes (apart from
QL compatible I think), but using only the top left corner. In most
4/8 colour modes lines as decided by DISPLAY_WIDTH are 1024 pixels DIV
4 wide, i.e. 256 bytes. However, only the first pixel width DIV 4
bytes are used.

Hope this makes sense. If you save all 256 bytes you are not only
adding 'waste' to your file, you are increasing its size and making it
harder for it to be reloaded.

PIC file format: documented in Easyptr manual somewhere, as well as as
QPTR and also in SDUMP window save documentation in Miracle manuals I
think. Something like this: like a screen but with 10 bytes preamble
to identify file and specify sizes:

word    $4AFB or $4AFC (can't remember which from memory)
word    pixel width
word    pixel height
word    line increment in bytes of this file as saved
byte    mode number
byte    unused (used in QDesign to specify compression format I think)
        followed by graphics data, stored same format as screens

Don't know if this has been updated for the new hicolour modes
though - possible that Minerva extended mode numbers may may specify
mode number as a word rather than byte, but not sure on this.

--
Dilwyn Jones
[EMAIL PROTECTED]
http://www.soft.net.uk/dj/index.html

Reply via email to