Re: [Ql-Users] Graphic objects and padding

[Dave Park via Ql-Users]

It's almost like we need some kind of public "infobase" or "programmer's
wiki" to make these nuggets easily searchable and reference-able.

Where might we find something like that?

PS: I offer free web hosting to anyone willing to run it.

On Mon, Apr 16, 2018 at 9:47 AM, pjwitte via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> On 14/04/2018 20:01, Marcel Kilgus via Ql-Users wrote:
>
>> pjwitte via Ql-Users wrote:
>>
>>> If those who "wrote the book" on these matters arent able/willing to
>>> pipe up, then we'll have to waste some time R-ingTFBs and doing the
>>> tests ourselves. I'll be back.
>>>
>> "The books" were written so long ago, even the people who wrote them
>> must usually spend some serious time to answer questions like yours.
>>
>> Regarding your question in the forum, the internal save area format
>> always has a "spare" long-word after each line, fuck knows why. So
>> that is why every line is 4 bytes longer, because it just writes out
>> the internal format. But it doesn't matter really, the "increment"
>> field in the file header is what's important, for all it's worth it
>> can be one 65kb per line and should still work, the field must just
>> match the data. If you construct a file yourself, use whatever line
>> increment pleases you.
>>
>> The fog is slowly clearing :) Thanks for your input. I
> assumed anyone "in the know" would just know the answer and
> not have to waste precious hours figuring out what was
> already known, as I did - and presumably many before me.
> Trying to derive the rules  from the various implementors
> proved frought, as it seems that, for pragmatic reasons (or
> perhaps to compensate for other's non-compliance) they
> mostly have their own rules for outputs and acceptable
> inputs. Anyway, once Im certain, Ill write it up, so no one
> needs to ask or answer this again.
>
> Per
> ___
> QL-Users Mailing List




-- 
Dave Park
d...@sinclairql.com
___
QL-Users Mailing List

Re: [Ql-Users] Graphic objects and padding

[pjwitte via Ql-Users]

On 14/04/2018 20:01, Marcel Kilgus via Ql-Users wrote:

pjwitte via Ql-Users wrote:

If those who "wrote the book" on these matters arent able/willing to
pipe up, then we'll have to waste some time R-ingTFBs and doing the
tests ourselves. I'll be back.

"The books" were written so long ago, even the people who wrote them
must usually spend some serious time to answer questions like yours.

Regarding your question in the forum, the internal save area format
always has a "spare" long-word after each line, fuck knows why. So
that is why every line is 4 bytes longer, because it just writes out
the internal format. But it doesn't matter really, the "increment"
field in the file header is what's important, for all it's worth it
can be one 65kb per line and should still work, the field must just
match the data. If you construct a file yourself, use whatever line
increment pleases you.


The fog is slowly clearing :) Thanks for your input. I
assumed anyone "in the know" would just know the answer and
not have to waste precious hours figuring out what was
already known, as I did - and presumably many before me.
Trying to derive the rules  from the various implementors
proved frought, as it seems that, for pragmatic reasons (or
perhaps to compensate for other's non-compliance) they
mostly have their own rules for outputs and acceptable
inputs. Anyway, once Im certain, Ill write it up, so no one
needs to ask or answer this again.

Per
___
QL-Users Mailing List

Re: [Ql-Users] Graphic objects and padding

[Marcel Kilgus via Ql-Users]

pjwitte via Ql-Users wrote:
> If those who "wrote the book" on these matters arent able/willing to
> pipe up, then we'll have to waste some time R-ingTFBs and doing the 
> tests ourselves. I'll be back.

"The books" were written so long ago, even the people who wrote them
must usually spend some serious time to answer questions like yours.

Regarding your question in the forum, the internal save area format
always has a "spare" long-word after each line, fuck knows why. So
that is why every line is 4 bytes longer, because it just writes out
the internal format. But it doesn't matter really, the "increment"
field in the file header is what's important, for all it's worth it
can be one 65kb per line and should still work, the field must just
match the data. If you construct a file yourself, use whatever line
increment pleases you.

Marcel

___
QL-Users Mailing List

Re: [Ql-Users] Graphic objects and padding

[Bob Spelten via Ql-Users]

Op Sat, 14 Apr 2018 11:23:04 +0200 schreef pjwitte via Ql-Users  
:




(...)
Thanks for your replies, most of which agree with my understanding but,  
unfortunately, not with my recent experience. (Eg see my post on the  
Forum for one example:  
http://www.qlforum.co.uk/viewtopic.php?f=3=2272=40#p22823)


And that is the crux of the matter: Without a definitive description its  
each to his own interpretation. This is bad for those of us trying to  
produce fun or useful stuff. And the number of offerings out there that  
dont really work, or work inconsistently, dont exactly evoke the sense  
that "The QL" is a serious or relieable machine. It certainly putsme off  
at times (my own failings in this regard notwithstanding ;)


If those who "wrote the book" on these matters arent able/willing to  
pipe up, then we'll have to waste some time R-ingTFBs and doing the  
tests ourselves. I'll be back.



I must admit having missed your Forum entry.
Without running your program I know that WSASV (EP4) and PSAVE (QPTR) will  
add padding, sometimes even 1 Long more than needed.
They were written in QL mode days and clearly never changed for High  
Colour times.
The same is probably true for the "Books", this padding is not mentioned  
there. That's why SQRview tests for any padding.


When saving such a PIC as SPR the padding is already there and needs not  
to be added but too much padding may result in a slanted sprite if lines  
are not cut properly as it relies on x-width and not on line increment as  
PICs do.


Bob

--
The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/;

---
Deze e-mail is gecontroleerd op virussen door AVG.
http://www.avg.com

___
QL-Users Mailing List

Re: [Ql-Users] Graphic objects and padding

[pjwitte via Ql-Users]

On 13/04/2018 17:46, Dilwyn Jones via Ql-Users wrote:

Could someone please explain the rules to me regarding the padding of
graphics objects for the two main formats: Sprites and Pics/PSA?

I thought Id worked it all out, at least for some modes, but my rule-
book does not appear to be complete, nor provide stable answers in 
all

cases. Also, there are some  formats Im not able to test.. So now Im
confused and would like to get a "definitive" take on the matter.

(...)


As I understand it,
Sprites must always be padded to Longs for all modes QL or GD2.

PIC/PSA must be padded for modes 4 & 8.
The GD2 modes 16 to 33 should/need not be padded and some viewers 
may have problems if they are.

SQRview will detect excess padding and not show it.

Bob
This agrees with my experience of sprites and PIC files from when I 
was writing Q-Dock. Some unusual things can happen if the sprites 
aren't long word padded.


I haven't much experience of PSA files, but since they are 
essentially PIC files with an extra long word in the preamble, I 
would assume they would handle exactly the same as PIC files after 
taking the extra long word into account.


Dilwyn 
Thanks for your replies, most of which agree with my understanding 
but, unfortunately, not with my recent experience. (Eg see my post on 
the Forum for one example: 
http://www.qlforum.co.uk/viewtopic.php?f=3=2272=40#p22823)


And that is the crux of the matter: Without a definitive description 
its each to his own interpretation. This is bad for those of us trying 
to produce fun or useful stuff. And the number of offerings out there 
that dont really work, or work inconsistently, dont exactly evoke the 
sense that "The QL" is a serious or relieable machine. It certainly 
puts me off at times (my own failings in this regard notwithstanding ;)


If those who "wrote the book" on these matters arent able/willing to 
pipe up, then we'll have to waste some time R-ingTFBs and doing the 
tests ourselves. I'll be back.


Per
___
QL-Users Mailing List

Re: [Ql-Users] Graphic objects and padding

[Dilwyn Jones via Ql-Users]

Could someone please explain the rules to me regarding the padding of
graphics objects for the two main formats: Sprites and Pics/PSA?

I thought Id worked it all out, at least for some modes, but my rule-
book does not appear to be complete, nor provide stable answers in all
cases. Also, there are some  formats Im not able to test.. So now Im
confused and would like to get a "definitive" take on the matter.

(...)


As I understand it,
Sprites must always be padded to Longs for all modes QL or GD2.

PIC/PSA must be padded for modes 4 & 8.
The GD2 modes 16 to 33 should/need not be padded and some viewers may have 
problems if they are.

SQRview will detect excess padding and not show it.

Bob
This agrees with my experience of sprites and PIC files from when I was 
writing Q-Dock. Some unusual things can happen if the sprites aren't long 
word padded.


I haven't much experience of PSA files, but since they are essentially PIC 
files with an extra long word in the preamble, I would assume they would 
handle exactly the same as PIC files after taking the extra long word into 
account.


Dilwyn 


___
QL-Users Mailing List

Re: [Ql-Users] Graphic objects and padding

[Bob Spelten via Ql-Users]

Op Fri, 13 Apr 2018 12:12:56 +0200 schreef pjwitte via Ql-Users  
:



Could someone please explain the rules to me regarding the padding of
graphics objects for the two main formats: Sprites and Pics/PSA?

I thought Id worked it all out, at least for some modes, but my rule-
book does not appear to be complete, nor provide stable answers in all
cases. Also, there are some  formats Im not able to test.. So now Im
confused and would like to get a "definitive" take on the matter.

(...)


As I understand it,
Sprites must always be padded to Longs for all modes QL or GD2.

PIC/PSA must be padded for modes 4 & 8.
The GD2 modes 16 to 33 should/need not be padded and some viewers may have  
problems if they are.

SQRview will detect excess padding and not show it.

Bob

--
The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/;

---
Deze e-mail is gecontroleerd op virussen door AVG.
http://www.avg.com

___
QL-Users Mailing List

[Ql-Users] Graphic objects and padding

[pjwitte via Ql-Users]

Could someone please explain the rules to me regarding the padding of
graphics objects for the two main formats: Sprites and Pics/PSA?

I thought Id worked it all out, at least for some modes, but my rule-
book does not appear to be complete, nor provide stable answers in all
cases. Also, there are some  formats Im not able to test.. So now Im
confused and would like to get a "definitive" take on the matter.

Variables:
x%/y%
llen% = increment between lines
bpp   = bytes per pixel

The question relates to sprites, of QL modes and all the supported
GD2 modes: Are all lines to be padded to a size divisible by four?
In all modes?

Pic format objects:
QL modes:
I presume x% must always be divisble by 2?
All modes:
Must lines physically be padded beyond that, eg to be dividsible
by four?

If I can get definitive rules on this, Id be happy to write them up
and pass them on to the maintainers of the relevant documentation.

Per

___
QL-Users Mailing List