> 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

Reply via email to