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:

Re: QL Graphics

Post by pjw »

BSJR wrote:
pjw wrote:Sprites can relatively easily be converted, however, the padding to an even long word at the end of each line is a bit of a nuisance, and is one of the reasons why I feel the sprite format is not the ideal, de facto standards for general image files. Padding makes sense for sprites, which need to be displayed rapidly, but for picture files, the padding would have to be removed on loading - at least if it is to conform with the current wman etc (am I right?) and added again on saving to the spr format.
As the WSARS & PREST commands allow you to set width and height of the section to show, this will automatically cut off any padding even if set to the x-size from the header. There is no need to remove or add it on Load or Save.
Only if the original is a _PIC, may padding need to be added for _SPR conversion.
Thanks, Bob. I didnt have anything readily to hand to test it myself.
But, to you earlier post: What is the problem displaying large sprite-type files? In most cases its just a question of altering the header - unless conversion is required..


Per
dont be happy. worry
- ?
User avatar
BSJR
Trump Card
Posts: 182
Joined: Sun Oct 18, 2015 12:53 pm
Location: Amsterdam
Contact:

Re: QL Graphics

Post by BSJR »

pjw wrote:
BSJR wrote:
pjw wrote:Sprites can relatively easily be converted, however, the padding to an even long word at the end of each line is a bit of a nuisance, and is one of the reasons why I feel the sprite format is not the ideal, de facto standards for general image files. Padding makes sense for sprites, which need to be displayed rapidly, but for picture files, the padding would have to be removed on loading - at least if it is to conform with the current wman etc (am I right?) and added again on saving to the spr format.
As the WSARS & PREST commands allow you to set width and height of the section to show, this will automatically cut off any padding even if set to the x-size from the header. There is no need to remove or add it on Load or Save.
Only if the original is a _PIC, may padding need to be added for _SPR conversion.
Thanks, Bob. I didnt have anything readily to hand to test it myself.
But, to you earlier post: What is the problem displaying large sprite-type files? In most cases its just a question of altering the header - unless conversion is required..
It's possible to POKE a smaller y-size in the sprite header so WSPRT/SPRW shows the top section but this doesn't work for the x-size and there is also no starting offset possible.
To allow scrolling and panning SQRview will do its own RLE & mode conversion and treats the result as a PIC.

Bob


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 »

BSJR wrote:<>It's possible to POKE a smaller y-size in the sprite header so WSPRT/SPRW shows the top section but this doesn't work for the x-size and there is also no starting offset possible.
To allow scrolling and panning SQRview will do its own RLE & mode conversion and treats the result as a PIC.
Just to try it out, I made the following test:

Code: Select all

100 REMark Large sprite viewer (POC)
110 :
120 psa = 0: REMark psa or pic
130 fnm$ = 'win3_tst_KnuthU_spr'
140 :
150 ch = FOP_IN(fnm$): ERT ch
160 BGET#ch; sm%, cm%, dv%, ct%
170 GET#ch; xs%, ys%, xo%, yo%
180 LGET#ch; cp, cm, no
190 fl = FLEN(#ch)
200 CLOSE#ch
210 :
220 REMark Only native, no RLE
230 IF sm% <> 2 OR cm% <> DISP_TYPE OR ct% && 64: ERT -19
240 REMark No mask, additional obj, or option block:
250 IF cm OR no OR ct% && 4: ERT -19
260 :
270 spr = ALCHP(fl)
280 LBYTES fnm$, spr
290 :
300 SELect ON DISP_TYPE
310  = 16: bpp = 1
320  = 32, 33: bpp = 2
330  = 64: bpp = 4
340  = REMAINDER : ERT -19
350 END SELect
360 :
370 ll% = (xs% + xs% MOD 4) * bpp
380 :
390 pic = spr + 14
400 POKE_W pic, $4AFC, xs%, ys%, ll%
410 POKE pic + 8, cm%, 0
420 :
430 IF psa THEN
440  psa = spr + 10
450  POKE_L psa, 0
460  SBYTES_O 'ram1_tst_psa', psa, fl - 10
470 ELSE
480  SBYTES_O 'ram1_tst_pic', pic, fl - 14
490 END IF
500 RECHP spr
510 :
A number of the no-nos this code objects to can easily be worked around, eg with PHGTK.
I save the code rather than view it here, but you get the idea.
And you were right: WSARS etc should cope with padded sprites.
Obviously, this was a quick knock-up, so there may be bugs, but the general idea seems ok.


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 »

Some anomalies emerged between reality and my understanding of it.
Inebriation does not come into it, at least not prior to me
undertaking following tests. I hope someone here can tell me whats
g'won.

This is the test I ran:

Code: Select all

100 FOR x% = 48 TO  58 STEP 2
110 ch = FOPEN("con")
120 WINDOW#ch; x%, 50, 400, 20
130 OUTL#ch
140 :
150 fnm$ = 'ram1_dmp' & x% & '_pic'
160 adr = WSAIN(#ch)
170 PAPER#ch; 1: INK#ch; 7
180 CLS#ch
190 PRINT#ch; 'Size'! x%
200 WSASV#ch; adr
210 S_WSA adr, fnm$
220 RECHP adr
230 CLOSE#ch
240 END FOR x%
250 QUIT
260 :
For those not familiar with EasyPointer, what this test does is:
Open some windows of varying x-sizes (x = 48 to 58 in steps of 2)
Take a snapshot of each window and
Save it as a _pic file

On deconstructing the resulting pics I get the following: (where
X/Y are the dimensions, M is the mode (test done for both mode 32
and mode 16), LL is the line length (as PEEKed from the pic header)
Exp, is the line length I expected(!), Flen is the actual file size,
ExFl is the expected file size, given the unexpected line length.)

Code: Select all

X  Y  M  LL  Exp  Flen  ExFl
-- -- -- --- ---  ----  ----
48 50 32 100  96  5020  5010
50 50 32 104 100  5212  5210
52 50 32 108 104  5420  5410
54 50 32 112 108  5612  5610
56 50 32 116 112  5820  5810
58 50 32 120 116  6012  6010

48 50 16  52  48  2620  2610
50 50 16  56  52  2812  2810
52 50 16  56  52  2812  2810
54 50 16  60  56  3020  3010
56 50 16  60  56  3020  3010
58 50 16  64  60  3212  3210
1) Mode 32: Why is the line length 4 bytes longer than expected
(by me. I obviously didnt get the memo!)?

2) Mode 16: I also didnt get the memo about line lengths needing
to be divisible by 4(?)

3) When I reconstruct the pics using my expectations they are
skewed. Ok, fair enough. However, using the unexpected line length
to reconstruct the pics, the file sizes are between 2 and 10 bytes
smaller than S_WSA makes out, yet the images turn out perfectly
well without those extra bytes. Could this be a glitch in S_WSA?


Per
dont be happy. worry
- ?
Post Reply