Hi,

>> Theme file format...
>> 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?

It's the typical chicken-and-egg problem - if you don't have any
standard, nobody is (ever) going to use it. If you create a standard
now, nobody is currently using it (exept perhaps some in-house
productions) - but somebody **might** in the future.
You will not be worse off with the latter, but maybe better.



> 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.

Or to legibility. I'd personally prefer a text file - because it is text
and you can alter it with a simple text editor which is generally faster
than using spmething like wined to edit the bianry file directly.
Granted, you can also totally muck it up by merrily editing the file
beyong all recognition, but -to me- that would be a small price to pay.


> 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.

True. On the other hand, a program would normally only do that when
starting up and the time taken to parse the palette file, compared to
the time taken to start up, would probably not be very important.

> 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? ;)
>

Actually, I would prefer:
00 : $200
01 : $ff00

etc....

Thay way, I'd know right away what to edit.

> I propose to use a binary format (see below) and use LBYTES instead.

The debate of plain text config files (large, take a while to process)
vs binary files (unreadable to us normal humans) isn't new...

> This cuts space and time, and would allow a number of such files to
> be concatenated. 

You could also concatenate text files.

> 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.

Oh, if you want something standard, a header is definitely needed. A
program could perfectly well only use the first 30 or so of the colours
and have a theme file only for those. One would need to know honw many
colurs are un that aplette file. I do notice that your proposal seems to
have the number of colours (after the "THM")?

>> 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?

Not unless they want to use the new format. As I said above, if they
don't use it, you're not worse off than now.

> 
>> 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.

A certin number of prowess progs have a different filetype if I'm not
mistaken. The problem here is that, apart from maybe being a pain in the
neck for filemanagers, nobody notices them. Chicken-and-egg again. Same
reasoning may apply.

> 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:
> 

Well if one goes with a binary format, and to put the fox amongst the
chickens (what's it with me and chickens today?) why not have a standard
theme file that can be edited with MenuConfig. One could probably have
the "SCLx" extension, which would give you enough options to play with
(SCL0-9, SCLA-Z, SCLa-z). Of course, parsing that would be even more
difficult.

Regards

Wolfgang
_______________________________________________
QL-Users Mailing List

Reply via email to