Re: [ql-users] Changing DISP_SIZE under SMSQ/e
In a message dated 08/12/2003 22:16:46 GMT Standard Time, [EMAIL PROTECTED] writes: Coming to think about it, Rich, I think that the cursor is shut off on the non SMSQ/E versions to protect against garbled image... Surely if that crept by mistake into the QPC version (and the cursor is not turned on before exiting) QPC should appear dead (no curson, no switching right?) Nope it doesn't do this on QPC - as I say, if you configure QWord to use the existing display resolution or SuperBASIC's windows are smaller than 640x480, you do not have a problem with switching to SuperBASIC. --Rich Mellor RWAP Services35 Chantry Croft, Kinsley, Pontefract, West Yorkshire, WF9 5JHTEL: 01977 610509Visit our website at:URL:http://www.rwapsoftware.co.ukIn need of adventure?URL: http://www.rwapadventures.comStuck with ordinary dial up internet connection ?? Read our review of internet accelerators and broadband at:URL:http://www.rwapservices.co.uk
Re: [ql-users] Changing DISP_SIZE under SMSQ/e
[EMAIL PROTECTED] wrote:
On 8 Dec 2003 at 5:49, [EMAIL PROTECTED] wrote:
(...)
Surely if the screen resolution is altered, any jobs which have windows which
fall outside the new area should be suspended rather than removed and only
reinstated once the screen size is large enough to accomodate their windows..
Umpf, and how do you test for that? What happens if the user unsuspends the job
whilst the screen is still too small?
I have made it configurable in QWord (similar to Launchpad) as to whether it
can alter the screens resolution and colour depth, but this does not help if
SuperBASIC is killed off, even after the program resets the screen resolution
and colour depth.
Job 0, the mother of all SBasics isn't killed off. I don't think it can be killed at all.
The easiest way around your problem is to set up a hotkey
eg ert hot_wake ('b','sbasic'). This will call up a new sbasic, with the standard windows,
whenever there is none there yet..
I think it cannot be killed but CAN BE replaced (ie from another shell
or whatever... at least I think that's what TT said at one point) (or
something)
Also, if anyone has followed my work on QWord, they will notice that I now
need to perform two main tasks if a QWord is QUIT - namely, remove the QTYP
device driver and reset the colour depth and screen resolution if necessary.
1-
As a general idea, I would think it to be a pretty bad idea to remove a device driver
simply because a job no longer needs the device. Surely it is better to load the device
driver separately by way of a boot program. Many of us will have it installed anyway.
What happens if the driver is there twice? Which one is removed?
(BTW - are you sure you're allowed to link the QPYP extensions into your program?).
IIRC he is ie the extensions are royalty free. (Of course don't hold me
to that but I can assure you that whatever Rich does is 1000% (yes the
extra 0 is intended) legal. And even if the extensions weren't freely
distributable Rich will always pay royalties...
2-
Surely it would be better if your QWord adapted itself to the existing screen resolution
colour depth rather than the other way around?
Not really. Remember QWord (the same executable) works regardless of the
presence of Colour Drivers (ie it runs on Minerva and QDOS Classic). In
the latter cases it manually modifies the hardware registers to switch
to the colour depth and resolution required. So if QWord was to adapt to
the existing screen colour depth, you would only get 4 colour QWord on
the Aurora with Minerva or non-colour SMSQ/E ;-) Plus that the whole
thing is based around careful measurements that are resolution specific.
Unless of course someone wants to implement for just one game
scaleable graphics and draw every object on the screen (plus icons, plus
letters, 3D effects, shadows etc.) instead of using pre-rendered
graphics. They are sure welcome to try ;-)
Of
course, it cannot do this if the job is killed from outside or loses focus -
we really need an event which can be monitored (aka Windows) to allow a
program to take certain action when it is killed externally or loses focus.
Do you mean that you want to quit the job every time it loses focus? Does this make
any sense on a multitasking machine?
Again, the major problem is for systems without colour drivers where
Q-Word has to hog the system (suspending the scheduler would be a good
idea if it weren't for the Audio server ;-)
Sorry if I sound rather critical, perhaps I haven't really understood what you meant.
Rather the latter :-)
Phoebus
Re: [ql-users] Changing DISP_SIZE under SMSQ/e
In a message dated 08/12/2003 15:16:37 GMT Standard Time,
[EMAIL PROTECTED] writes:
On 8 Dec 2003 at 5:49, [EMAIL PROTECTED] wrote:(...)
Surely if the screen resolution is altered, any jobs which have windows which
fall outside the new area should be suspended rather than removed and
only reinstated once the screen size is large enough to accomodate
their windows..Umpf, and how do you test for that? What happens if
the user unsuspends the job whilst the screen is still too
small?
The unsuspend routine could surely check the screen dimensions and refuse
to unsuspend the job if the screen is too small...
Sorry - not too well today, so not thinking straight... Not sure if
this is possible
I have made it configurable in QWord (similar to
Launchpad) as to whether it can alter the screens resolution and
colour depth, but this does not help if SuperBASIC is killed off,
even after the program resets the screen resolution and colour
depth.Job 0, the "mother of all SBasics" isn't killed off. I don't
think it can be killed at all.The easiest way around your problem is to
set up a hotkeyeg ert hot_wake ('b','sbasic'). This will call up a new
sbasic, with the standard windows, whenever there is none there
yet..
Hmm - very odd - I wonder why if SBASIC is set to OUTLN #0,512,256,0,0 and
I execute QWord (which resets thescreen to 640x480), it is fine when I
switch to SBASIC (or quit QWord).- Remember that QWord resets the original
screendimensionswhen Quit.However, if I set SBASIC to OUTLN
#0,800,600,0,0 and then run QWord, on quitting QWord, the screen dimensions are
reset to 800x600, but there is no cursor available to #0 - in fact, QPC just
hangs !!
Also, if anyone has followed my work on QWord,
they will notice that I now need to perform two main tasks if a QWord
is QUIT - namely, remove the QTYP device driver and reset the colour
depth and screen resolution if necessary.1-As a general idea, I would
think it to be a pretty bad idea to remove a device driver simply because
a job no longer needs the device. Surely it is better to load the device
driver separately by way of a boot program. Many of us will have it
installed anyway. What happens if the driver is there twice? Which one is
removed?
Not too sure - I was hoping for some input from TT. QTYP uses
SMS.LIOD to link the new device driver and I am storing the address of the link
to use for the pointer to remove the device with SMS.RIOD. Not actually
tested this yet.
The idea is to avoid a boot program altogether, so that people who have not
installed QTYP on their system as a default, do not have to remember to run a
BOOT program before executing QWord. Surely that is the main reason for
linking in extension toolkits when compiling a program !
(BTW - are you sure you're allowed to link the QPYP
extensions into your program?).2-Surely it would be better if your
QWord adapted itself to the existing screen resolution colour depth
rather than the other way around?
As Phoebus has pointed out - this is nigh impossible with the way that the
graphics are designed. QWord can be configured to use the existing screen
resolution and colour depth (though at present does not support mode 4 or mode
8). However, it does mean that if the resolution is smaller than 640x480
on QPC, it will not run (reports an error), and if the resolution is greater,
then the tiles appear smaller on screen (and harder to read).
Feedback from users suggests that they would rather QWord be configurable
to set the screen accordingly so that it appears as large as possible.
Of course, it cannot do this if
the job is killed from outside or loses focus - we really need
an event which can be monitored (aka Windows) to allow a program to
take certain action when it is killed externally or loses focus.Do you
mean that you want to quit the job every time it loses focus? Does this make
any sense on a multitasking machine?
No - I would want the job to be able to realise that it had lost focus so
that it could then reset the colour depth and resolution, or maybe do something
in the background instead (such as stop writing to the screen). The only
way it can do this at the moment is to have a small window open on the screen
that it attempts to PRINT to and use error trapping to take alternative action
when focus is lost (such as not output data). However, this is not always
apt !!
Sorry if I sound rather critical, perhaps I haven't
really understood what you meant.
I accept any criticism - postive or otherwise
--Rich
Mellor RWAP Services35 Chantry Croft, Kinsley, Pontefract, West
Yorkshire, WF9 5JHTEL: 01977 610509Visit our website
at:URL:http://www.rwapsoftware.co.ukIn need of adventure?URL:
http://www.rwapadventures.comStuck with ordinary dial up internet
connection ?? Read our review of internet accelerators and
broadband
at:URL:http://www.rwapservices.co.uk
Re: [ql-users] Changing DISP_SIZE under SMSQ/e
I have made it configurable in QWord (similar to Launchpad) as to whether it can alter the screens resolution and colour depth, but this does not help if SuperBASIC is killed off, even after the program resets the screen resolution and colour depth. I found out the hard way some of the things that can go wrong if a job does something like this, if you know how to do it, even Launchpad can crash itself by doing this, never mind what it can do to other jobs or even to the OS itself with the problems caused by some programs' inability to cope with the situation. I'm glad I was persuaded to alter the way Launchpad behaves, it makes it that much more flexible even though it was a bit more of a chore to make it adapt itself to whatever it found itself running in. -- Dilwyn Jones
Re: [ql-users] Changing DISP_SIZE under SMSQ/e
On 8 Dec 2003 at 12:44, Phoebus Dokos wrote: I think it cannot be killed but CAN BE replaced (ie from another shell or whatever... at least I think that's what TT said at one point) (or something) ? It's a moot point here since that is not what is happening. (...) IIRC he is ie the extensions are royalty free. (Of course don't hold me to that but I can assure you that whatever Rich does is 1000% (yes the extra 0 is intended) legal. I don't intend at all to question his honesty. I just didn't know that you're allowed to do that. (...) 2- Surely it would be better if your QWord adapted itself to the existing screen resolution colour depth rather than the other way around? Not really. Remember QWord (the same executable) works regardless of the presence of Colour Drivers (ie it runs on Minerva and QDOS Classic). In the latter cases it manually modifies the hardware registers to switch to the colour depth and resolution required. So if QWord was to adapt to the existing screen colour depth, you would only get 4 colour QWord on the Aurora with Minerva or non-colour SMSQ/E ;-) I understand (now). Still, instead of automatically chaning the screen resoultion colour depth, At LEAST make it configurable, i.e. 'Do you want this program to change colour depth resolution automatically Yes/no. If not, and if it doesn't run on a system already having higher colour, then don't switch. Plus that the whole thing is based around careful measurements that are resolution specific. Does that mean that wen I run in a higer resolution, its doesn't change the screen? Unless of course someone wants to implement for just one game scaleable graphics and draw every object on the screen (plus icons, plus letters, 3D effects, shadows etc.) instead of using pre-rendered graphics. They are sure welcome to try ;-) Prowess? (...) Wolfgang
Re: [ql-users] Changing DISP_SIZE under SMSQ/e
On 8 Dec 2003 at 16:36, [EMAIL PROTECTED] wrote:
Umpf, and how do you test for that? What happens if the user unsuspends the
job
whilst the screen is still too small?
The unsuspend routine could surely check the screen dimensions and refuse to
unsuspend the job if the screen is too small...
And the user wouldn't be happy.
(...) I have made it configurable in QWord (similar to Launchpad) as to whether
it
can alter the screens resolution and colour depth,
Ah, great, then!
(...)
Job 0, the mother of all SBasics isn't killed off. I don't think it can be
killed at all.
The easiest way around your problem is to set up a hotkey
eg ert hot_wake ('b','sbasic'). This will call up a new sbasic, with the
standard windows,
whenever there is none there yet..
Hmm - very odd - I wonder why if SBASIC is set to OUTLN #0,512,256,0,0 and I
execute QWord (which resets the screen to 640x480), it is fine when I switch
to SBASIC (or quit QWord). - Remember that QWord resets the original screen
dimensions when Quit. However, if I set SBASIC to OUTLN #0,800,600,0,0 and then
run QWord, on quitting QWord, the screen dimensions are reset to 800x600, but
there is no cursor available to #0 - in fact, QPC just hangs !!
Not here, it doesn't.
my disp_size is 1024,768
ert hot_wake ('B','')
ert hot_wake ('b',sbasic')
ALT +B - job 0
DISP_size 800,600
job 0 seems to disappear.
alt +b get a new sbasic, type disp_size 1024,768
alt + B brings back job 0 with t working cursor in channel#²0
(ok, sometimes it's windows aren't reset correctly
(...)
Not too sure - I was hoping for some input from TT. QTYP uses SMS.LIOD to
link the new device driver and I am storing the address of the link to use for
the pointer to remove the device with SMS.RIOD. Not actually tested this yet.
It should work...
The idea is to avoid a boot program altogether, so that people who have not
installed QTYP on their system as a default, do not have to remember to run a
BOOT program before executing QWord. Surely that is the main reason for
linking in extension toolkits when compiling a program !
Indeed it is.
I do suggest, however, that a device driver as such isn't a toolkit, but a system
extension.
Alternative : why not test for the presence of qtyp before re-installing it (if that is
possible at all).
()
QWord can be configured to use the existing screen
resolution and colour depth (though at present does not support mode 4 or mode 8).
However, it does mean that if the resolution is smaller than 640x480 on QPC,
it will not run (reports an error), and if the resolution is greater, then the
tiles appear smaller on screen (and harder to read).
Yes, this seems indeed the way to go!
Feedback from users suggests that they would rather QWord be configurable to
set the screen accordingly so that it appears as large as possible.
Fair enough. I personally wouldn't want that...
(...)
No - I would want the job to be able to realise that it had lost focus so
that it could then reset the colour depth and resolution, or maybe do something
in the background instead (such as stop writing to the screen). The only way
it can do this at the moment is to have a small window open on the screen that
it attempts to PRINT to and use error trapping to take alternative action when
focus is lost (such as not output data). However, this is not always apt !!
If Qword uses the PE, then there is a way to find out if it has lost focus or not.
Read the pointer with a timeout and check the returned pointer position
(e.g. if using QPTR's RD_PTRT, the xrel,yrel parameters will return -1 if the pointer
is
outside the job's window).
I accept any criticism - postive or otherwise
Perhaps the above was less otherwise
Wolfgang
