Thanks Marcel.
I knew you would know :o)
Norman.
Norman Dunbar EMail: [EMAIL PROTECTED]
Database/Unix administrator Phone: 0113 289 6265
Lynx Financial Systems Ltd. Fax:0113 201 7265
Dilwyn wrote :
only the top left of the screen on an Aurora is used. You should
only save the actual number of bytes used for the screen resolution
used, i.e. for mode 0 and mode 8, this is pixel_width DIV 4.
Is this mode 0 the same as mode 4 then, or has Aurora got mode 0, 4 and 8 ?
So I
only the top left of the screen on an Aurora is used. You should
only save the actual number of bytes used for the screen
resolution
used, i.e. for mode 0 and mode 8, this is pixel_width DIV 4.
Is this mode 0 the same as mode 4 then, or has Aurora got mode 0, 4
and 8
Mode 0 is in fact Mode 4.
Duncan wrote :
Could the phantom black window be a default channel opened by using
SCR_XLIM
without any channels opened? This forces SMSQ/E to open a channel. You
could
check the size using the qpac2 Exec menu channels function?
I will give this a try out and see, it does look like a
Franois wrote :
My conclusion is: SCR_XLIM and SCR_YLIM functions open a primary window.
I think you may be correct - I shall revisit the source code and see if I am
calling scr_ylim before opening a channel.
Maybe Marcel can let us know what scr_xlim/ylim do in reality as he has the
source
Norman Dunbar wrote:
Maybe Marcel can let us know what scr_xlim/ylim do in reality as he has the
source code :o)
It's true, all scr_ functions need a channel block in order to get the
information (and open one themselves if there isn't any). One could
try opening a small window (1 to 1 pixel
Remember that Aurora screens are different - the bytes per line
increment may not be the same as the number of bytes used to store
one
line of pixels in mode 4.
Does this mean that the width of a display line as returned by
DISPLAY_WIDTH
could be, for example, 200 bytes, but in the
On 28 Mar 2001, at 23:11, FranoisVan Emelen wrote:
Well, I really can't tell. I'm not a programmer; my skills are unfortunately
limited to some Sbasic.
What I know about SCR_LIM and SCR_YLIM is this:
If launch the procedure below in QD with F10 (Sbas/QD thing), you will see a
black window
Dilwyn wrote :
Remember that Aurora screens are different - the bytes per line
increment may not be the same as the number of bytes used to store one
line of pixels in mode 4.
Does this mean that the width of a display line as returned by DISPLAY_WIDTH
could be, for example, 200 bytes, but in
Nasta wrote :
The line increment on Aurora is always either 256 bytes (QL mode 4 and 8)
or 512 bytes (Aurora 16 and 256 colour mode).
I presume this is reflected in the SCR or CON channel definition block for
the number of bytes per screen line ?
If so my DISPLAY_WIDTH function will simply
Franois Van Emelen wrote :
2) Background Basic. This option doesn't draw a phantom background.
Could this be the solution to your problem?
Don't know yet - but I will give it a try. I was under the impression that
this only showed you what the designed menu would look like superimposed on
a
Duncan Neithercut wrote:
Hi
Could the phantom black window be a default channel opened by using SCR_XLIM
without any channels opened? This forces SMSQ/E to open a channel. You could
check the size using the qpac2 Exec menu channels function?
Duncan
Hi,
Well, I really can't tell.
Dear all,
Firstly, QLiberator has behaved perfectly today - no compilation worries and
no crashes on running. I wish I knew what was causing the problems :o(
PER : I even managed to REDUCE the stack and heap size from 8K each to 4K
stack and 2K heap as the program only used about 1K stack in
Next, Screen Snatcher has been updated to save the correct size of a
full
screen. It does this by working out the number of bytes per screen
line and
the number of lines in the full screen depth, then it saves
(line_width *
screen_depth) bytes to file.
Remember that Aurora screens are different
On 3/27/01 at 6:32 PM Dilwyn Jones wrote:
Remember that Aurora screens are different - the bytes per line
increment may not be the same as the number of bytes used to store one
line of pixels in mode 4. In some modes you may find that the line
increment is equal to the number of bytes required
Norman Dunbar wrote:
Dear all,
Firstly, QLiberator has behaved perfectly today - no compilation worries and
no crashes on running. I wish I knew what was causing the problems :o(
PER : I even managed to REDUCE the stack and heap size from 8K each to 4K
stack and 2K heap as the
In article [EMAIL PROTECTED],
Norman Dunbar [EMAIL PROTECTED] writes
Dear all,
Firstly, QLiberator has behaved perfectly today - no compilation worries and
no crashes on running. I wish I knew what was causing the problems :o(
PER : I even managed to REDUCE the stack and heap size from 8K each
17 matches
Mail list logo
