Platform Levels

[pjw]

I am assuming you mean the DIY Toolkit SET command written in 1991. (There is SET contanined HCO Toolkit)

Whoops! Yes. Got that one mixed up.

SET only seems to work on non-SMS systems and MInerva up to v1.66
The SETENV command in ENV_BIN works SMSQ/E, Minerva, JS etc...

If you are after compatibility, it look like the DIYTK SET command is that is not compatible.
For that reason I would ENV_BIN over DIY Tooklkit. But since all the source code is available, both extensions could be made compatible.

Do you thikn this is worth perform this level of compatibility programming?

Im not sure that SETENV and DIYTK's SET aim to to the same thing. But by all means: If there is a way to make any useful DIYTK that currently isnt, SMSQ/E compatible, it would be A Good Thing, to my mind. And what a lovely way to spend an otherwise languid Sunday afternoon!

[pjw]

Yes, I agree the system palette is fine for menus etc - but the graphics for a game are a pain if there is detailed graphics and they need converting for the various platforms. [...]

Im not sure this was available when you wrote QWORD (Superb effort and fun game, BTW!) but if you were (re)writing it today you might find it a lot easier. All youd have to to is create two sets of sprites for the tiles and things: One for hicolor and one for QL mode (if you wanted to include this). The system takes care of the differences between the Qx0 and QPC2 colour implementations. For menus and things, you could devise your own palette(s) which can now be applied on a per job basis (See SMSQ/E's SP_JOBOWNPAL). For a game like QWORD, it would still be a struggle to make it work and look good in QL mode, though

[pjw]

[..]
One thing you could do to get started is a survey to find out which systems are the most common and give priority to these when we develop software.[..]

A survey would be useful! Its been a while since the last one. A lot of work, though. And needs careful thought.. Maybe worth a separate thread?

[Giorgio Garabello]

I can only say that I can follow the discussion given the limits of my English .... but I do not think it is very useful to discuss this or that extension individually, but to address the speech in general, working towards greater integration between the various QL subsystems.
Surely making a census of machcines and users would be very useful, you can use Google forms to do it ,; But we have to think well of what questions to ask.

Giorgio

[Martin_Head]

While I think the idea of predefined 'levels' is nice. Somehow I can't see it working in practise.

On one hand your basically dictating to uses what software they must run on their systems. I personally mainly use QPC2, and half of the software you put as 'must have' I don't have installed, and I don't want to. If I try to use some software that needs a particular extension/tooolkit, then I will load it .

On the other hand, I can see programmers inventing new levels, just to suit what ever program they are writing. Or just ignoring the levels entirely.

I'm more inclined to having a Minimum or Recommended system specification, in the programs documentation. Like PC software.

[Derek_Stewart]

Hi,

I had a look at DIYTK SET and ALTER, on Q-Emulator running JSROM.

using the SET command, adds the parameter to the Toolkit 2 EXTRAS list.

Where as ENV_BIN: SETENV set a variable retrived by the applications programme using the GETENV$ command.

It looks to me from a compatibility point of ENV_BIN is going this correctly, as it works with Minerva and SMSQ/E and older version of QDOS.

I think the real point here how can software written in 1991 be upwardly compatible with newer operating system.

The same question as posed when I introduced the Q60 to the community in 2002, with SMSQ/E as the main operating system. Most people wanted to use Text87... written 15 earlier. I actually bought Text87 and thought it was so bad swopped for something that worked.

Back on topic.... 2 option dump DIYTK, not an option really still a good read of commented assembly language of correct the changes to run on more modern QL operating systems.

Who is going to alter Simon's code I am not sure.

[Giorgio Garabello]

While I think the idea of predefined 'levels' is nice. Somehow I can't see it working in practise.

On one hand your basically dictating to uses what software they must run on their systems. I personally mainly use QPC2, and half of the software you put as 'must have' I don't have installed, and I don't want to. If I try to use some software that needs a particular extension/tooolkit, then I will load it .

On the other hand, I can see programmers inventing new levels, just to suit what ever program they are writing. Or just ignoring the levels entirely.

I'm more inclined to having a Minimum or Recommended system specification, in the programs documentation. Like PC software.

That is why I believe it is crucial to have a comprehensive survey to see what people are using ....

Giorgio

[pjw]

While I think the idea of predefined 'levels' is nice. Somehow I can't see it working in practise.

On one hand your basically dictating to uses what software they must run on their systems. I personally mainly use QPC2, and half of the software you put as 'must have' I don't have installed, and I don't want to. If I try to use some software that needs a particular extension/tooolkit, then I will load it .

I dont want to dictate, simply to get some kind of sanity. The extensions I list are my basic assumptions for a minimally, functional system, and my plea is for yall to discuss, and see if we can arrive at some common assumptions.
So you mainly use QPC2. Whats not to like about my Level 3: (SMSQ/E), QLib_run, Turbo_sms_Toolkit, FileInfo2, ENV_bin, ptrmen, Qptr, menu_rext, sound4_bin, sound_bin? With those toolkits loaded it should be possible to test and run most recent software without rebooting between sessions. (A number of these extensions are "systems extensions", ie they cant be compiled into a program, but must or should be loaded at boot time.)

On the other hand, I can see programmers inventing new levels, just to suit what ever program they are writing. Or just ignoring the levels entirely.

Thats pretty much what the world looked like before M$ became dictatorial, in about 1994, and imposed a semblance of sanity. This helped the computer revolution to take off! (And weve hated them ever since..)
The "QL" isnt so much a platform as a number of splatforms! When preparing some program for distribution, do I target those four people, or the two people in the other camp, or the solipsist in the middle?

I'm more inclined to having a Minimum or Recommended system specification, in the programs documentation. Like PC software.

I rest my case.

[pjw]

I had a look at DIYTK SET and ALTER, on Q-Emulator running JSROM.

Derek, these are two very different extensions, that try to achieve very different things. There would be no point in trying to unify them in any way.

[pjw]

There are now almost as many different platforms as there are people producing any new software for the QL environment. Any further fragmentation would make the whole scene an nonviable joke. Porting stuff from other systems, is never going to be equally satisfying to making something that makes use of the unique possibilities the QL offers, which have hardly begun to be explored. (Otherwise, why not just use the other system instead? (However, as a stopgap, for some needs it may be better than nothing..))

To my mind, we should reduce the number of target platforms rather than multiply them, for example by specifying different, standardised capability levels (as suggested earlier in this thread). That would widen the base and bring some kind of sanity into the proceedings..

PS "By reduce the number of platforms", I emphatically dont mean that I wish the Q68 etc away! This will be properly understood by anyone who took the trouble to read my introduction to this thread.