QL Graphics

Anything QL Software or Programming Related.
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

QL Graphics

Post by pjw »

Hi,

I have some questions re "QL" graphics.
Ill start with a few simple ones. I know I ought know the answers to some of these, but I dont have a Q68 or a real QL anymore to confirm, and certain information and some results I got confuse me:

Is the size of standard mode 8 screen dump 32768 b - same as for mode 0/4?
When the Q68 manual states that it has a "Standard QL MODE 8 256x256 pixel (8 colours)" mode, would a screen dump also be 32k?
All the emulators return SCR_XLIM = 512, whether in WTV 8 or WMON 4. Is that correct, or a deliberate tease by SCR_XLIM or the emulators?
What do SCR_XLIM and SCR_LLEN say on Q68 "mode 0", ie 256 x 256 m 8?

TIA


Per
dont be happy. worry
- ?
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: QL Graphics

Post by tofro »

pjw wrote: Is the size of standard mode 8 screen dump 32768 b - same as for mode 0/4?
Yep. The original QL's screen memory is 32kBytes and all (both) modes use it fully.
pjw wrote: When the Q68 manual states that it has a "Standard QL MODE 8 256x256 pixel (8 colours)" mode, would a screen dump also be 32k?
Yes. The Q68 has in the two legacy video modes the exact same video memory organisation as the original QL. It's even at the same address.
pjw wrote: All the emulators return SCR_XLIM = 512, whether in WTV 8 or WMON 4. Is that correct, or a deliberate tease by SCR_XLIM or the emulators?
No they don't. Both QPC2 and uqlx can tease mode 4 screens to a higher non-standard resolution. SCR_XLIM/SCR_YLIM will return whatever you set it to in mode 4. If you set such a bigger screen to mode 8 you'll get the mode 4 pixel count (even if that is not true)
Q-Emulator, uqlx and QPC2 return 512 for a standard-resolution mode 8 screen just like the real thing. The original QL mode 8 layout "emulates" 512 pixels horizontal resolution in 256 real ones.
pjw wrote: What do SCR_XLIM and SCR_LLEN say on Q68 "mode 0", ie 256 x 256 m 8?
What the original QL returns. 512 and 128. In both mode 4 and mode 8


If your goal is to find the amount of memory a saved screen needs, that is SCR_XLIM * bits/pixel * SCR_YLIM/8 for all modes except MODE 8 on the original QL (where it's half the amount), and a constant 240k for Aurora 256-color mode, if I remember right (The Aurora uses non-contiguous memory for contiguous screen lines)

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QL Graphics

Post by martyn_hill »

Hi Per

Just to add to Tobias' explanation "The original QL mode 8 layout "emulates" 512 pixels horizontal resolution in 256 real ones. ":

Even in Mode 8, the OS addresses horizontal pixels as though there were 512 - any accesses to odd-numbered x-axis pixels in Mode 8 are rounded back (DIV 2) (or is it forwards???) to the nearest even numbered pixel, which as you know, is twice the width of the equivalent Mode 4 pixel.

Try either BORDER 1, <colour> or BORDER 2, <colour> in MODE 8 and you'll get a double-width pixel (in terms of MODE 4) down the sides of <colour> in both cases, but a single or double height pixel line across top/bottom respectively.

A long way of saying that SBASIC/QDOS/SMSQ all 'normalise' horizontal dimensions to units of MODE 4 pixels regardless of the MODE in use. Why didn't I just say that in the first place???


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: QL Graphics

Post by pjw »

Thanks for the confirmation, Tobias. Good to have someone both so knowledgeable and helpful to hand! :)

Now for a trickier question (or maybe not):
Is there any way (using intelligence rather than visual inspection) to tell whether a screen dump file contains a mode 4 or 8 image? (51%+ certainty would be helpful). I understand there is a sort of quasi-convention of using the extensions _scr0 (= _scr4), and _scr8, but it is not universally supported. Ive seen just _scr (meaning whatever) and _dmp (meaning whatever) as well as the misuse of _pic - With some people even going to the trouble of specifying _pic4 and _pic8 on real PIC files, which hardly need the qualifier in that that information is adequately contained within the file itself.


Per
dont be happy. worry
- ?
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QL Graphics

Post by martyn_hill »

Hi again Per

Not 100%, but given that almost zero.zero% of apps bother with HW FLASH, you could get a good indication by checking a few of the bits that hold the FLASH state toggle in MODE 8 versus GREEN in MODE 4. If you find ANY GREEN/FLASH bits set, there's a pretty good chance that the file holds a MODE 4 screen-dump.


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: QL Graphics

Post by pjw »

Thanks, Martyn!

I played around with the graphics side of the QL in the early days, but just found it too limited to do anything with. Obviously, that has all changed; what with the colour drivers (GD2), the "new" PE2, and now, the tipping point, for me at least: David Westbury's PHGTK. I hadnt realised it had "come of age" until I saw QTImage, by Giorgio Garabello and discovered that PHGTK was its magic sauce.

Of course, the "QL" will never be strong on image processing, due to processing power and storage constraints - and above all: the lack of graphics hardware. But that may change..


Per
dont be happy. worry
- ?
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: QL Graphics

Post by pjw »

martyn_hill wrote:Hi again Per

Not 100%, but given that almost zero.zero% of apps bother with HW FLASH, you could get a good indication by checking a few of the bits that hold the FLASH state toggle in MODE 8 versus GREEN in MODE 4. If you find ANY GREEN/FLASH bits set, there's a pretty good chance that the file holds a MODE 4 screen-dump.
Good one, Martyn! Ill check it out!


Per
dont be happy. worry
- ?
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: QL Graphics

Post by pjw »

pjw wrote:<> I hadnt realised it had "come of age" until I saw QTImage, by Giorgio Garabello and discovered that PHGTK was its magic sauce.
And, I forgot to mention, SQRView by Bob Spelten JR!
Of course, the "QL" will never be strong on image processing, due to processing power and storage constraints - and above all: the lack of graphics hardware. But that may change..
In the meantime, however, speed is quite adequate on emulators on a fast host (My 9 year old Mac Book Pro, for example). Even SMSQmulator's graphics speed has improved considerably in recent times, beating QPC2 on some tests Ive done ;)


Per
dont be happy. worry
- ?
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: QL Graphics

Post by tofro »

I actually think Martyn's way is the only way to successfully guess the mode. Other than the relatively un-used (thankfully) FLASH feature, there is no way to distinguish the screen storage. (And I think I have successfully removed all programs that excessively use FLASH from my systems anyhow because it is simply annoying)

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: QL Graphics

Post by pjw »

tofro wrote:<>If your goal is to find the amount of memory a saved screen needs<>
Thats not what this is about. For now, lets just say Im fooling around with graphics to find out things that may be useful for my own "projects" and others'.

For graphics file viewers, photo fixing, paint programs, etc, it is useful to have some knowledge of a given file to load or display. Since its Wild West in QL land, with few real standards, this is a bit of a mine field. We are somewhat lacking in a decent file format! Jpeg, PNG, etc, are complex and apparently require quite a bit of processing power, although with the event of PHGTK this has reduced considerably compared to earlier efforts - usually written in C, I presume. The PIC format, could be considered a - or the - native QL graphics file format. However, it suffers from lack of compression - Modern picture files are quite large!
The sprite format is a very nice and versatile image format that also sports compression. The best thing about it is that it is supported by the OS. However, it is not designed as a picture format, although it can be manipulated to serve, if required.
It seems to me that some combination of the PIC file format and the sprite format, combined with better compression methods (RLE is fine to begin with) - and supported to some degree by the OS, would nudge graphics processing into better shape and give it a boost in QL land. This could have a knock-on effect for games, sprite design, and other areas of interest over the next 34 years and beyond ;)


Per
dont be happy. worry
- ?
Post Reply