Sorry, that was supposed to be:
dc.b "THB",57 ; not "THM",57
On 13 November 2017 at 17:59, Per Witte <pjwi...@online.no> 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:
> .. 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?
> > 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
> > 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
> 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:
> dc.b "THM",57
> dc.w $200
> dc.w $FFC0
> 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.
> On 13 November 2017 at 15:50, François Van Emelen via Ql-Users <
> firstname.lastname@example.org> 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?
>> 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