Re: [Ql-Users] Theme file format

[François Van Emelen via Ql-Users]

Op 13/11/2017 om 17:59 schreef Per Witte via Ql-Users:


Thanks for your reply  explanation.

François Van Emelen


___
QL-Users Mailing List

Re: [Ql-Users] Theme file format

[Per Witte via Ql-Users]

Sorry, that was supposed to be:

header
dc.b "THB",57;  not "THM",57
data
dc.w $200
dc.w $FFC0
etc..

On 13 November 2017 at 17:59, Per Witte  wrote:

> > Theme file format
> > I had a look at Theme file format on QL forum. Some
> > comments and questions:
> >
> > Rethorical question: Is it worthwhile to create a new
> > format to save some space (a few bytes, I suppose)
> > when we have (QPC2, SMSQmulator)  128MB at our disposal?
> Despite computers getting ever faster and bigger, the likes of
> Windoze still seem slow at times, and just as soon run out of space -
> as they always did.. That may partly be down to BLOAT and lazyness.
>
> In the case of the "QL", software might be expected to run on a wide
> variety of platforms, some fast and big, some slow and tight. IMHO,
> efficiency is rarely a bad thing unless achieving it is considerably
> more costly that what it is likely to save.
>
> I dont know where the current theme file format originated, but a few
> programs use that. It is sometimes (usually?) given the extension
> _thm. It is a pure text file that looks like this:
>
> $200
> $FFC0
> .. etc altogether 57 lines
>
> To load a palette (theme) youd use something like:
> ..
> FOR ofs = 0 to SP_GETCOUNT - 2 STEP 2
>  INPUT#ch; it$
>  POKE_W addr + ofs, HEX(it$(2 to))
>
> Whats not to improve? ;)
>
> I propose to use a binary format (see below) and use LBYTES instead.
> This cuts space and time, and would allow a number of such files to
> be concatenated. But instead of LBYTESing any kind of rubbish, I
> suggested we make a header that would give a strong indication, if
> not absolute certainty, that we were loading the right kind of file.
>
> A number of file formats on the QL scene dont have headers, and this
> sometimes causes confusion not to mention frustration and the
> potential for inelegant crashes unless preventive steps are taken by
> each and every program using them. The _scn extension, for example
> means widely different things..
>
> > Not all palette files have 57 entries.
> Well, thats the current tally, as given by the Wman2 function
> SP_GETCOUNT. If that were to change, a file header might help to
> identify that fact quickly.
>
> > In fact, a complete palette should have 58 entries.
> > The original author forgot to reserve a slot for the
> > border of the error window. Doesn’t a new format imply
> > a rewrite of existing programs?
> No.
>
> > Will Qspread, QD, Files,... comply?
> I dont think any of them load external palettes. If they do, they
> will no doubt happily continue to use whatever standard theyre
> using now.
>
> > Afraid of having 57 entries filled with wrong data?
> Not afraid, as loading the wrong data will not crash the program,
> only display strange colours. POKEing or LBYTESing more data than
> ALCHPed would be seriously problematic.
>
> > Why not create a new type of file? I would suggest type
> > 84 (T for theme).
> File types are sadly not much supported in QL land. Defining a new file
> type could cause problems - for existing file managment programs, for
> example.
>
> > Just my two cents.
> Glad for your interest so this matter can be finalised.
>
> The current suggestion is for theme files to have an additional
> format to the existing one. It will be dead easy to convert theme
> files between "standards", so programmers can choose to support the
> new standard (if it becomes one) - or not. The reason Im bringing this up
> is
> to try to prevent a third and a fourth "standard" to emerge (unnecessary
> creating confusion and nonsense), by engaging anyone who has an
> opinion to "speak now or be forever silent" (as they say at the wedding
> ceremony in the C of E.) As mentioned, the file will be binary, but I
> describe it here in assembler for clarity:
>
> header
> dc.b "THM",57
> data
> dc.w $200
> dc.w $FFC0
> etc..
>
> Other suggestions have been made. This is V3.0, currently my
> preferred option, but Im open to improvements, including a header-less
> binary, considered earlier on.
>
> Per
>
> On 13 November 2017 at 15:50, François Van Emelen via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
>
>> Hi,
>>
>> Theme file format
>> I had a look at Theme file format on QL forum.
>> Some comments and questions:
>>
>> Rethorical question: Is it worthwhile to create a new format to save some
>> space (a few bytes, I suppose) when we have (QPC2, SMSQmulator)  128MB at
>> our disposal?
>> Not all palette files have 57 entries.
>> In fact, a complete palette should have 58 entries. The original author
>> forgot to reserve a slot for the border of the error window.
>> Doesn’t a new format imply a rewrite of existing programs?
>> Will Qspread, QD, Files,... comply?
>> Afraid of having 57 entries filled with wrong data? Why not create a new
>> type of file? I would suggest type 84 (T for theme).
>> Just my two cents.
>>
>> Have a nice day.
>>
>> François Van Emelen
>>
>>
>>
>> 

Re: [Ql-Users] Theme file format

[Per Witte via Ql-Users]

> Theme file format
> I had a look at Theme file format on QL forum. Some
> comments and questions:
>
> Rethorical question: Is it worthwhile to create a new
> format to save some space (a few bytes, I suppose)
> when we have (QPC2, SMSQmulator)  128MB at our disposal?
Despite computers getting ever faster and bigger, the likes of
Windoze still seem slow at times, and just as soon run out of space -
as they always did.. That may partly be down to BLOAT and lazyness.

In the case of the "QL", software might be expected to run on a wide
variety of platforms, some fast and big, some slow and tight. IMHO,
efficiency is rarely a bad thing unless achieving it is considerably
more costly that what it is likely to save.

I dont know where the current theme file format originated, but a few
programs use that. It is sometimes (usually?) given the extension
_thm. It is a pure text file that looks like this:

$200
$FFC0
.. etc altogether 57 lines

To load a palette (theme) youd use something like:
..
FOR ofs = 0 to SP_GETCOUNT - 2 STEP 2
 INPUT#ch; it$
 POKE_W addr + ofs, HEX(it$(2 to))

Whats not to improve? ;)

I propose to use a binary format (see below) and use LBYTES instead.
This cuts space and time, and would allow a number of such files to
be concatenated. But instead of LBYTESing any kind of rubbish, I
suggested we make a header that would give a strong indication, if
not absolute certainty, that we were loading the right kind of file.

A number of file formats on the QL scene dont have headers, and this
sometimes causes confusion not to mention frustration and the
potential for inelegant crashes unless preventive steps are taken by
each and every program using them. The _scn extension, for example
means widely different things..

> Not all palette files have 57 entries.
Well, thats the current tally, as given by the Wman2 function
SP_GETCOUNT. If that were to change, a file header might help to
identify that fact quickly.

> In fact, a complete palette should have 58 entries.
> The original author forgot to reserve a slot for the
> border of the error window. Doesn’t a new format imply
> a rewrite of existing programs?
No.

> Will Qspread, QD, Files,... comply?
I dont think any of them load external palettes. If they do, they
will no doubt happily continue to use whatever standard theyre
using now.

> Afraid of having 57 entries filled with wrong data?
Not afraid, as loading the wrong data will not crash the program,
only display strange colours. POKEing or LBYTESing more data than
ALCHPed would be seriously problematic.

> Why not create a new type of file? I would suggest type
> 84 (T for theme).
File types are sadly not much supported in QL land. Defining a new file
type could cause problems - for existing file managment programs, for
example.

> Just my two cents.
Glad for your interest so this matter can be finalised.

The current suggestion is for theme files to have an additional
format to the existing one. It will be dead easy to convert theme
files between "standards", so programmers can choose to support the
new standard (if it becomes one) - or not. The reason Im bringing this up
is
to try to prevent a third and a fourth "standard" to emerge (unnecessary
creating confusion and nonsense), by engaging anyone who has an
opinion to "speak now or be forever silent" (as they say at the wedding
ceremony in the C of E.) As mentioned, the file will be binary, but I
describe it here in assembler for clarity:

header
dc.b "THM",57
data
dc.w $200
dc.w $FFC0
etc..

Other suggestions have been made. This is V3.0, currently my
preferred option, but Im open to improvements, including a header-less
binary, considered earlier on.

Per

On 13 November 2017 at 15:50, François Van Emelen via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi,
>
> Theme file format
> I had a look at Theme file format on QL forum.
> Some comments and questions:
>
> Rethorical question: Is it worthwhile to create a new format to save some
> space (a few bytes, I suppose) when we have (QPC2, SMSQmulator)  128MB at
> our disposal?
> Not all palette files have 57 entries.
> In fact, a complete palette should have 58 entries. The original author
> forgot to reserve a slot for the border of the error window.
> Doesn’t a new format imply a rewrite of existing programs?
> Will Qspread, QD, Files,... comply?
> Afraid of having 57 entries filled with wrong data? Why not create a new
> type of file? I would suggest type 84 (T for theme).
> Just my two cents.
>
> Have a nice day.
>
> François Van Emelen
>
>
>
> ___
> QL-Users Mailing List
___
QL-Users Mailing List