256x256 SCR file sample

[Dec]

Check out the Display appendix.

Thanks.

Now I am looking for samples for additional screen modes.

[pjw]

Check out the Display appendix.

Thanks.

Now I am looking for samples for additional screen modes.

Here are samples of this image in mode 16, 32, and 33

Colour Wheel 200x200

ColorWheel200.jpg (14.68 KiB) Viewed 1748 times

There are toolkits on Knoware.no to convert screen data between the various GD2 colour formats

[Derek_Stewart]

Hi Per,

looks great.

with all this talk about Mode 64, has this screen mode ever been actually displayed of is is it just figment of somones memory...

[dilwyn]

Hi Per,

looks great.

with all this talk about Mode 64, has this screen mode ever been actually displayed of is is it just figment of somones memory...

AFAIK, no. It was specified in the original GD2 docs. Although I think you can use such sprites and they will be altered automatically for the current display mode. Uncompressed mode 64 graphics files would be pretty massive if not compressed.

[tofro]

Well, you can use mode64 sprites in a mode 32 or mode 33 program - they will be run-time converted to the actual screen mode as you say, Dilwyn. So, not of much use with the hardware that we have at hand. Maybe a QL 2050 will support Mode 64 natively, though

But there wasn't ever any screen driver that would support mode 64 natively.

[pjw]

Hi Per,

looks great.

with all this talk about Mode 64, has this screen mode ever been actually displayed of is is it just figment of somones memory...

Mode 64 PICs and sprites are alive and kicking, its just that there are no mode
64 displays in the QL world to do them justice. I therefore also didnt do a
routine to convert graphics data to mode 64, only from mode 64 to 16 and 3X, so
as to, at least, enable images in that format to be displayed.

Q: So whats the point of mode 64, you might ask? Why does SMSQ/E sport COLOUR_24
(ie mode 64) when no such colour can be displayed?

A: It is much more convenient to specify a colour as $00FF00 (Green) or $FF0092
(Shocking pink) than $07E0 and $F812, respectively. RGB gives at least some idea
of what the colour will be. Thus:

Code: Select all

COLOUR_24
PAPER; $FF0000
INK; $FFFFFF
CLS: PRINT "Hello World!"

has the same effect as

Code: Select all

COLOUR_QL
PAPER 2
INK 7
CLS: PRINT "Hello World!"

ie the standard SuperBASIC #1 screen colours.

Also RGB colours may be simpler to use in calculations (at least for us simple
grunts), eg for lightening and darkening, etc.

Mind you, using the COLOUR_24 command does not alter the actual colour depth of
the screen. The screen always operates in COLOUR_NATIVE whatever that happens to
be, mode 16, 32 or 33. Thus, if your screen mode happens to be 32 (QPC2,
SMSQmulator) then

Code: Select all

COLOUR_NATIVE
PAPER; $F800
INK; $FFFF
CLS: PRINT "Hello World!"

would do the same trick.

(But beware of trying to POKE the latter colour values into screen memory! Then
you come up against "endian" issues!)

[Derek_Stewart]

Hi Per,

Thank you for the clarification, I did know about Colour_24, I just thought it did not support Mode 64 due to the lack of hardware support.

The obvious route would be to update an emulator running a modern graphics card, I am not sure if a native QL Graphics Card could be made to support this type of High Resolution.

[mk79]

Mode 32 and 33 cannot be converted between each other without some slight loss, so if you care about that thing you can specify mode 64 and then have the conversion done as well as possible. But I don't think in practice anybody would notice and thus it's mostly a waste of memory. Except if you maybe have a very fine colour gradient, in that case it might make an actual difference.

Making a real mode 64 display doesn't make any sense, except if your goal is wasting more memory and making everything even slower.

[Dec]

Here are samples of this image in mode 16, 32, and 33

Trying to understand files encoding but without success. For example CW200-16.pic. There are 10 bytes of header and color data with 4 bits per sample. Theoretically there are should be 200x200/2 = 20000 bytes of color data but in fact there are 40400 bytes. Don`t understand.

[pjw]

Here are samples of this image in mode 16, 32, and 33

Trying to understand files encoding but without success. For example CW200-16.pic. There are 10 bytes of header and color data with 4 bits per sample. Theoretically there are should be 200x200/2 = 20000 bytes of color data but in fact there are 40400 bytes. Don`t understand.

The 3X modes are 16 bit, so the sizes should be 200x200x2 = 80,000+10. Mode 16 is 8 bit, so should be 40,000+10. However, for some reason, unknown to me, both the Qptr and the EasyPointer save routines, which Ive used to save the image, add extra (empty) words or longwords to each line.

The word at location 6 in the header gives the line length in bytes. As you will see the line lengths are 404 and 202, respectively, which explains the file sizes.

(Edit: Corrected the file sizes.)