galleondragon / qb64 Goto Github PK

Comments placed in the first lines inside a TYPE block should be indented to match the definitions.
See picture below for example:

It would be great if I could open my old .BAS sourcefiles, apperantly created with this format. Today it tells me it is not supported.

The _DISPLAY function is a very nice way to do away with manual double-buffering, but it has one drawback -- blinking colours in SCREEN 0 do not continue to blink as expected; yes, the blinking is technically refreshing the display, but the benefit of the blinking colours is that they blink automatically and you're not having to update the colours yourself every frame (what a nightmare that would be).

This could be resolved by copying the screen memory to a private buffer and doing the automated blinking from that buffer -- that way, updates to the screen won't automatically appear on screen until _DISPLAY is called again.

There doesn't appear to be a simple way to read the blinking state of a character on the screen -- I had to resort to reading screen memory; and because I'm forced to use double-buffering (due to blinking) this also screws with reading screen memory; the screen page number has to be stored in a global variable and I need factor that into the screen address calculations. This is a lot of complication that would not be needed if SCREEN 0 continued to blink when using _DISPLAY.

(nb: a function to read the blink-state of a screen co-ordinate would make life easier; e.g. blink = SCREEN(y, x, 2))

I'm not sure how to narrow this down, but basically _TRIM$ is returning the wrong string! (a previously used one, or perhaps some other memory area)

This code:

LET CMD$ = CMD$ + " " + CHR$(34) + FIX_PATH$ + DIR_ENGINE$ + RTRIM$(Engines_Selected.exe) + CHR$(34)

Would produce START /D "saves\gzdoom\DTWID\" "..\..\..\ports\gzdoom-34_x64\gzdoom.exe" for example, but this code:

LET CMD$ = CMD$ + " " + CHR$(34) + FIX_PATH$ + DIR_ENGINE$ + _TRIM$(Engines_Selected.exe) + CHR$(34)

(note _TRIM$ instead of RTRIM$) somehow duplicates the string, giving START /D "saves\gzdoom\DTWID\" "..\..\..\ports\gzdoom-34_x64\START /D "saves\gzdoom\DTWID\" "..\..\..\ports\gzdoom-34_x64\"!

Hi! There is a critical mistype in gl2qb_type_convert() function of opengl_methods.bas

It sets "&&" symbol for _OFFSET data type. It must be "%&".

What steps will reproduce the problem?
1. run setup_lnx.sh from terminal
2. garry-Inspiron-1012 qb64 # ./setup_lnx.sh
QB64 Setup

Building library 'LibQB'
./setup_lnx.sh: 22: ./setup_lnx.sh: ./setup_build.sh: Permission denied
Compilation of ./internal/c/libqb/os/lnx/libqb_setup.o failed!
3.

What is the expected output? What do you see instead?
Expected to see setting up start, it dose try,

Please use labels and text to provide additional information.
Note: I did check and all the file permisions seem to be ok. 
 I am going to look into it more.

Original issue reported on code.google.com by [email protected] on 28 Feb 2013 at 1:14

d9b3d7e fixes sound features for Linux but breaks it for Windows 64bit (tested under Windows 7)

The usual method is to redirect output to a file then read in said file, which is messy and annoying to do.

Is there a means of getting the OpenGL version available on the system? As OpenGL 2.x support is dropped by GZDoom, I'd like to be able to detect the system's OpenGL version and load alternate binaries of configurations as appropriate.

Reported at http://www.qb64.net/forum/index.php?topic=14715.msg127829#msg127829

Hi!
I found one strange thing in QB64. If you include '.' in the name of any sub or function then the IDE doesn't make it highlighted.

When invoking qb64 from the command line to compile a file the following error is returned if the internal/temp/ directory doesn't exist:

QB64 COMPILER V1.2

UNEXPECTED INTERNAL COMPILER ERROR!
Caused by (or after):
LINE 0:

The reason for the failure isn't obvious. It would be nice to print an explicit message, or even better, automatically create the internal/temp/ directory.

The wiki software at qb64.org has more tags in the source code than there used to be, and that needs parsing.

https://www.qb64.org/forum/index.php?topic=624.msg4976#msg4976

Today March 2, the releases page shows that you just released 1.1 but on that same page shows version 1.2 was released 7 days ago and is shown as the "latest" release.

https://github.com/Galleondragon/qb64/releases

You probably just need to get rid of the v1.2 tag on what ever that was 7 days ago.

https://twitter.com/_sorceress/status/1050098390724464640?s=21

call this an rfc- i dunno but...

sdl has sound. If licensing of sdl is gpl then sound libs should also be gpl...therefore the seperate licensing shouldnt be required.

Im working a bgiSDL api for fpc(libgraph)...so I know enough to be dangerous. Initial thinking maybe on similar libs to mplayer's ffmpeg but that also seems gpl not lgpl. I could be wrong.

Im learning the internals as I go..but it really is "simple" even by complex "bgi standards". And NO, FPC doesnt have a port of this. C has 4.Two work with effort. So my work isnt wasted.

Interesting that you tie it to QB though.
For those interested, SFML may provide better "game interface"? code... its really heavy on OGL and complex shaders that SDL needs a lot of work to handle.

GOD its been ages....93-94? GEEZ..Im old.
I dont really care for everyone porting to C/CPP but this is a start. C has dodgy pointers...and its a royal u-know-what to debug. Of course w fpc I have to break out the manual to see what the compiler is complaining about....

Hi. QB64 doesn't show warning at the status bar when a non-_MEM type variable is used with _MEMNEW and _MEMIMAGE. However, it does with _MEMFREE, _MEMGET and _MEMPUT.

A few strange behaviours when a program uses $CONSOLE

1. $CONSOLE:ONLY causes _DESKTOPWIDTH/_DESKTOPHEIGHT to always return 0

2. This code causes the program to soft-lock

   $CONSOLE
   $SCREENHIDE
   _ECHO STR$(_DESKTOPWIDTH)
   

   Using $CONSOLE:ONLY instead prevents the soft-lock but still returns 0 for _DESKTOPWIDTH

I need this work correctly so that I can send the desktop resolution to various DOOM engines from a command-line program.

That is, the ability to use:

_DEFINE "int" AS _UNSIGNED INTEGER
_DEFINE "lng" AS _UNSIGNED LONG

LET intSmallNumber = 65535
LET lngBigNumber = 2 ^ 31

Auto-typing variables (and function!) based on a single letter is a bit risky and I'd prefer the approach common with VB6 (3 letter prefix). It's expected this would be case-sensitive so as to minimize interference with functions, which are typically CamelCased.

Just a head's up; I'm trying to compile a (currently) console-only program, and the presence of $EXEICON causes the compiler to hang at this point:

QB64 COMPILER V1.2
...........................
COMPILING C++ CODE INTO EXE...
OUTPUT: C:\GAMES\DOOM\bin\launcher\launcher.exe

Changing to $CONSOLE solves this.

edit: or more likely at the very early execution stage!

Though the unpredictability of changing the sizes of non-last dimensions in a multi-dimension arrays is common knowledge in most forms of BASIC, the QB64 documentation does not specifically call this out. The documentation implies that it should work, and the compiler / run-time gives no warnings or error. Your data just magically gets messed up!

Test code:

PRINT "REDIM TEST"
REDIM TEST(1 TO 2, 1 TO 3) AS INTEGER
LET TEST(1, 1) = 100
LET TEST(1, 2) = 200
LET TEST(1, 3) = 300
PRINT TEST(1, 1); TEST(1, 2); TEST(1, 3)
REDIM _PRESERVE TEST(1 TO 3, 1 TO 3) AS INTEGER
PRINT TEST(1, 1); TEST(1, 2); TEST(1, 3)
END

Suggested solutions:

• Changing the bounds of a non-last dimension in a multi-dimensional array should produce a run-time error
• QB64 should ensure data integrity and move the data to the correct locations

I am building a two dimensional cross-check array, where the bounds are increasing as new data is read in. It would be difficult to store all the data (without knowing the final bounds until read) and dimension the array at the end.

There doesn't appear to be a way to get the name of the executable once running. I have a stub application "DOSmag" that gets re-packaged for a particular distribution, e.g. "PortaDOOM", so I'd like to set the title of the window based on the current executable name.

the build files are wrong as the units are built on sin (windows). Line endings of all units and makefiles need to be corrected. especially the unix packages...need to be built on unix(or in a vm). This is a lot of work for those just wanting to "build and go". Cant speak if OSX and sin have this problem as well because im running ubu 17. you can subversion commit now to github, so just stay in the box when working on unix code unless you run it natively on unix.

This is a lot of hassle but it will eventually build after hacking the hell out of build files. I had to remove the /bin/bash references despite all of the dos2unix conversion. This isnt per-se needed but I kept getting ^M where they shouldnt have been despite conversion.Removing the line seems to work for now. Building in unix should get rid of this problem entirely.

Also the configure file has two non utf8 chars in it that dont translate. removing them in the awk has no detrimental effect, rather curious why there there.

OFF is a legacy keyword but it's also used for new statements (like _CONSOLE OFF). The new _ALLOWFULLSCREEN keyword uses _OFF, which is aligned with the _FULLSCREEN statement that also uses _OFF. It'll be nice to have these be consistent (that is, have the new statements also accept OFF instead of scrape _OFF altogether - as older code will still contain the _OFF switch occasionally).

What steps will reproduce the problem?
1. Try the url 

What is the expected output? What do you see instead?
Website not available

What version of the product are you using? On what operating system?
This does not apply

Please provide any additional information below.
None

Original issue reported on code.google.com by [email protected] on 1 Jun 2014 at 6:30

What steps will reproduce the problem?
1. Choose another font.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
Tried both  the version here and from qb64.net. Open SUSE 13.1 x64 KDE.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 13 Mar 2014 at 5:20

Attachments:

• QB64_FONT.png

Hello there. The fact that QB64 goes through multiple screen-stretching modes when you use ALT+ENTER is a problem for me. A command to set which mode(s) the fullscreen shortcut uses would be good, allowing users to specify things like 'use only stretched & smoothed mode' or to disable the built-in fullscreen switch entirely so that they can trap the keys and handle it how they want (for example, I've added an F11 shortcut to my app to do fullscreen).

What steps will reproduce the problem?
1. Open uxterm
2. type wine cmd z: at the command line.
3. run program compiled using QB64-GL for windows

What is the expected output? What do you see instead?
N/A

What version of the product are you using? On what operating system?
Wine on Arch Linux

Please provide any additional information below.

Z:\home\main\QB64-WINE\qb64>wm

Z:\home\main\QB64-WINE\qb64>err:dc:CreateDCW no driver found for L":0.0"
freeglut (wm): fghInitialize: CreateDC failed, Screen size info may be incorrect
This is quite likely caused by a bad '-display' parameter
libGL error: dlopen /usr/lib/xorg/modules/dri//r600_dri.so failed 
(/usr/lib/xorg/modules/dri//r600_dri.so: wrong ELF class: ELFCLASS64)
libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: r600
libGL error: dlopen /usr/lib/xorg/modules/dri//swrast_dri.so failed 
(/usr/lib/xorg/modules/dri//swrast_dri.so: wrong ELF class: ELFCLASS64)
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
err:winediag:X11DRV_WineGL_InitOpenglInfo Direct rendering is disabled, most 
likely your 32-bit OpenGL drivers haven't been installed correctly (using GL 
renderer "Gallium 0.4 on AMD ARUBA", version "1.4 (3.0 Mesa 10.2.6)").
fixme:win:RegisterRawInputDevices Unhandled flags 0x100 for device 0.

Microsoft Windows 5.2.3790 (1.7.24)
err:wineconsole:WCUSER_SetFont wrong font
err:wineconsole:WCUSER_SetFont wrong font

Original issue reported on code.google.com by [email protected] on 4 Sep 2014 at 6:21

Requesting an enhancement for the User Types to have the ability to use an array inside the type
Type Userdata
Variables(50) AS INTEGER
. . .
end type

Dim MyType(20) as Userdata

MyType(1).Variables(15)=1024

Variables don't get properly ajusted (capitalization-wise) when used with LBOUND and UBOUND.

I'm trying to get input from a console, without a screen visible -- i.e. $CONSOLE:ONLY or $CONSOLE + $SCREENHIDE -- but this doesn't work. INKEY$ documentation states that if _DEST _CONSOLE is used, input will be taken from the console.

Sample code:

$CONSOLE
$SCREENHIDE
_DEST _CONSOLE

DO
    DIM k$
    LET k$ = INKEY$
LOOP WHILE k$ = ""

Why don't you do this? It's a higher uptime and comes with an option for a Wiki

This happens after a couple of simple test scripts (mainly PRINT with ERROR catching):

Problem signature:
Problem Event Name: BEX
Application Name: cmd.exe
Application Version: 6.1.7601.17514
Application Timestamp: 4ce78e2b
Fault Module Name: StackHash_0a9e
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 00ac2a70
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

This is the other crash:

Problem signature:
Problem Event Name: APPCRASH
Application Name: qb64.exe
Application Version: 0.0.0.0
Application Timestamp: 5b773c1b
Fault Module Name: ANSI32.dll
Fault Module Version: 1.8.4.0
Fault Module Timestamp: 5af5890c
Exception Code: c0000005
Exception Offset: 000024be
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: a7aa
Additional Information 2: a7aa91f17ea749d42a4de3b390fa5b3d
Additional Information 3: a7aa
Additional Information 4: a7aa91f17ea749d42a4de3b390fa5b3d

System is Windows 7 SP1 x64 on Intel i7-3610QM cpu

https://www.qb64.org/forum/index.php?topic=489.msg3405#msg3405

I have a strange bug. I'm using SCREEN 12 with 30-rows (640x480). I am trying to read from the screen to be able to draw a shadow around a dialogue box (read the ASCII code, print a black-background version back).

This is a portion of the code:

    'draw the shadow along the bottom
    LET y% = boxTop% + boxHeight% + 2
    FOR x% = (boxLeft% + 1) TO (boxLeft% + boxWidth%)
        LET char% = SCREEN(y%, x%, 0)
        COLOR DKGREY, BLACK
        LOCATE y%, x%
        PRINT CHR$(char%);
    NEXT

With SCREEN 12: WIDTH 80, 30 the SCREEN(...) function always returns code 219; solid-block, not even space as the documentation says. If I change to 25 rows, it works as expected.

install_lnx.sh aborts because it uses windows eols instead of unix eols.
Also libqb_setup.o and src.o and src.a are missing. Where can they be found?

Searching for things backwards in a string, such as file extensions, path slashes, is very manual. A reverse-INSTR function would be appreciated.

Now this could be its own function, or perhaps you could use a negative value for the START parameter to begin searching backwards, from that point.

The current logic used is very sucky:

• Code includes must use a .h extension
• Dynamic libraries must begin with lib on Linux
• The appropriate places aren't searched for dynamic libraries, causing machine-specific constants needing to be hard coded in
• Probably other problems

Such as support for Chinese?

Just as the title says. Can't seem to find the Debian-based installer now...

As reported by RhoSigma at https://www.qb64.org/forum/index.php?topic=350.msg2335#msg2335

Hi QB64 Team,

It seems I found a longstanding glitch/bug between _FREEIMAGE, _COPYIMAGE and the _MEM functions (probably _MEMIMAGE), which leads to an Critical Error #308 (memory has been freed).

The error happens, whenever _COPYIMAGE does use a handle, which was already used by another image earlier but which got freed in the meantime and hence is available for re-use. I could verify this error starting from the old SDL 0.954 version through different GL builts in between up to the latest GL development built available from QB64.org.

I've made a small program to show the issue. You also need the attached image or in alternative you may adjust the _LOADIMAGE line (3) to use any image on your system (must be at least 1024x768).

To get an understanding of the workflow, first read the comments right above the ModifyBrightness&() function (lines 37-40), then the comments in the main module (lines 14-26).

If you run the program as is, it will show the loaded image and wait for a keypress. When you press a key, it will do the _FREIMAGE and then the final ModifyBrightness&() call and will error out with #308 immediately. After that try to comment the _FREEIMAGE line !!OR!! commenting the _COPYIMAGE in ModifyBrightness&() and instead uncommenting the _NEWIMAGE/_PUTIMAGE pair (lines 63-67) and try again. It will work in both cases, a further keypress will then end the program.

'--- 1st show the original image ---
_TITLE "The original Image, press any key..."
ihan& = _LOADIMAGE("BeachGirl.jpg", 32) 'any image file (at least 1024x768)
IF ihan& >= -1 THEN ERROR 53 'file not found
SCREEN ihan&

'--- now make a darken cascade ---
_TITLE "Darken Cascade, press any key..."
dark& = ModifyBrightness&(ihan&, -0.15, 250, 70, 820, -1)
darker& = ModifyBrightness&(dark&, -0.15, 275, 95, 795, -1)
COLOR _RGB32(255, 255, 200): PRINT "Used Handle: "; dark&: SLEEP

'--------------------------------------------------------------------
'--- With activated _FREEIMAGE the freed handle is re-used by the
'--- next _COPYIMAGE call done in ModifyBrightness&() called right
'--- below the _FREEIMAGE, but the handle in question obviously gets
'--- not correctly initialized by _COPYIMAGE, as the _MEM function(s)
'--- used later to iterate through the image do fail to work on it
'--- (Critical Error #308 (memory was freed)).
'-----
'--- If otherwise the _FREEIMAGE call is commented out, then it works
'--- with _COPYIMAGE, as a new clean handle must be used instead.
'-----
'--- In alternative it also works with activated _FREEIMAGE, but change
'--- the _COPYIMAGE in FUNCTION ModifyBrightness&() into a combination
'--- of _NEWIMAGE and _PUTIMAGE instead to make the image copy.
'--------------------------------------------------------------------
_FREEIMAGE dark&
darkest& = ModifyBrightness&(darker&, -0.15, 300, 120, 770, -1)
'--------------------------------------------------------------------

SCREEN darkest&
COLOR _RGB32(255, 255, 200): PRINT "Used Handle: "; darkest&: SLEEP
'--- done ---
SYSTEM

'This function is a cutout from 'QB64Library\IMG-Support\imageprocess.bm',
'which is part of my Libraries Collection. It takes a source image handle
'and returns a modified image in a new handle usually made with _COPYIMAGE.
'This seems to fail, if for the copy an old (freed) handle is re-used.
'---------------------------------------------------------------------
'NAME
'   ModifyBrightness -- Brightness adjustment, keep alpha
'
'TEMPLATE
'   newImg& = ModifyBrightness& (shan&, change#, minX%, minY%, maxX%, maxY%)
'
'   change# -- must be between -1.0 and 1.0  (clipped)
'
' DESCRIPTION
'   This changes the general brightness of the image. The smaller the
'   value is the darker the image becomes.  0.0 means no change.
'   The alpha channel of the source image is retained and copied 1:1.
'---------------------------------------------------------------------
FUNCTION ModifyBrightness& (shan&, change#, minX%, minY%, maxX%, maxY%)
    ModifyBrightness& = -1 'so far return invalid handle
    IF shan& < -1 THEN
        IF _PIXELSIZE(shan&) = 4 THEN
            '--- get source image size and a copy of the image ---
            swid% = _WIDTH(shan&): shei% = _HEIGHT(shan&)

            '--------------------------------------------------
            '--- This works only, if a new handle must be used,
            nhan& = _COPYIMAGE(shan&)
            '--- and this works for both re-used and new handles
            'nhan& = _NEWIMAGE(swid%, shei%, 32)
            '_PUTIMAGE ,shan&, nhan&
            '--------------------------------------------------

            '--- check selected processing area ---
            IF minX% < 0 OR minX% >= swid% THEN minX% = 0
            IF maxX% < 0 OR maxX% >= swid% THEN maxX% = swid% - 1
            IF minY% < 0 OR minY% >= shei% THEN minY% = 0
            IF maxY% < 0 OR maxY% >= shei% THEN maxY% = shei% - 1
            '--- process copied image ---
            IF nhan& < -1 THEN
                '--- build histogram transformation table ---
                IF change# < -1.0# THEN change# = -1.0
                IF change# > 1.0# THEN change# = 1.0
                REDIM hist%(255)
                FOR i% = 0 TO 255
                    v% = FIX(i% * (change# + 1.0#))
                    IF v% < 0 THEN v% = 0: ELSE IF v% > 255 THEN v% = 255
                    hist%(i%) = v%
                NEXT i%
                '--- for speed we do direct memory access ---
                DIM nbuf AS _MEM: nbuf = _MEMIMAGE(nhan&)
                '--- iterate through pixels ---
                FOR y% = minY% TO maxY%
                    noff%& = nbuf.OFFSET + (y% * swid% * 4) + (minX% * 4)
                    FOR x% = minX% TO maxX%
                        '--- get pixel ARGB value from source ---
                        _MEMGET nbuf, noff%&, orgb~&
                        '--- modify pixel components ---
                        newA% = _ALPHA32(orgb~&) 'ignored (put through)
                        newR% = hist%(_RED32(orgb~&))
                        newG% = hist%(_GREEN32(orgb~&))
                        newB% = hist%(_BLUE32(orgb~&))
                        '--- put new pixel ARGB value to dest ---
                        nrgb~& = _RGBA32(newR%, newG%, newB%, newA%)
                        _MEMPUT nbuf, noff%&, nrgb~&
                        '--- set next pixel offset ---
                        noff%& = noff%& + 4
                    NEXT x%
                NEXT y%
                '--- cleanup ---
                _MEMFREE nbuf
                ERASE hist%
                '--- set result ---
                ModifyBrightness& = nhan&
            END IF
        END IF
    END IF
END FUNCTION

_CONTINUE works only with the current loop it is within. Many languages provide a parameter to specify the depth the statement should loop on. I.e.:

FOR x% = 1 TO 10
    FOR y% = 1 TO 10
        'when y reaches five, skip to the next x%, NOT the next y%
        IF y% = 5 THEN _CONTINUE 2
    NEXT y%
NEXT x%

The ability to specify the FOR variable instead of a depth would be appreciated:

FOR x% = 1 TO 10
    FOR y% = 1 TO 10
        'when y reaches five, skip to the next x%, NOT the next y%
        IF y% = 5 THEN _CONTINUE x%
    NEXT y%
NEXT x%

NB: Since the addition of _CONTINUE to the language, the FOR ... NEXT, DO ... LOOP etc. pages need it adding to their documentation.

When writing a program with a QB64 TUI / GUI, I often write debugging and status information to the console so I can observe what's going on without having to corrupt the text/graphic display. However, managing writes to the SCREEN and CONSOLE is fiddly. I need a log function that will switch the _DEST back and forth, and I lose the simplicity of the PRINT function, such as not requiring a parameter to output a blank line.

I propose two possible improvements:

1. An ECHO command that behaves exactly the same as PRINT but always outputs to the console
2. A parameter for PRINT (and related commands) to specify destination, e.g. PRINT _CONSOLE "Hello, World". This however is fraught with lots of extra design considerations

Kind regards,
Kroc Camen

Thank you for adding _ECHO but I've realised that it doesn't entirely solve the problems of dealing with a command-line driven app that may also have a GUI.

I'm writing PortaDOOM, a Doom launcher; it's replacing a 1500+ line batch script that manages all the parameters and calls the appropriate doom-engine.

The launcher needs to operate in a mix of two modes: if passed command-line parameters it'll need to validate those and call the desired doom-engine without having to bring up a UI. Output will need to be produced on stdout and stderr for interaction with regular batch scripts.

If provided without parameters (such as simply double-clicking the EXE file), or certain parameters, a UI needs to be presented.

Unfortunately $CONSOLE: _CONSOLE OFF always causes a console window to appear momentarily when the executable is launched even when this is not needed. I'd prefer if this didn't happen.

A simple fix would be to specify a way to not show the console until _CONSOLE ON is used, rather than show it by default and await a _CONSOLE OFF command. NB: I can't use $CONSOLE:OFF as I still need to output to console if the app is called from command-line.

An alternative solution is to allow direct writing to stdout / stderr, bypassing any state of QB64's own console (including $CONSOLE:OFF). This would be my preferred solution as, in this instance, I want to output directly to the OS and not work though QB64's console(s). I may want to capture stderr output separate from stdout in a batch file so as to not display any output from my app under batch control, unless an error occurs.

Using $RESIZE:OFF does not disable the form's maximize button. You can click it, and the window attempts to maximize, but just moves into the corner.

This is quite important for my use case as I'm writing an ANSI escape sequence interpreter and when the function is called to print an ANSI string, we need to know what the current fore/back-ground colour are to restore to when the clear or reset colour sequence is used.

Of course, we can read the colour from the current cursor position using _SCREEN(), but given that the ANSI escapes can move the cursor around and that what's on the screen may not be the 'default' colours that the user intends to fall back to, I need to be able to read the currently set foreground colour without actually writing anything to screen in order to do so. For example, a typical usage scenario would be something like this:

LOCATE 15, 5: COLOR 1, 7: ANSI_PRINT some_string$

Here, we want to default to colours 1 & 7 when any ANSI escape sequence changes the colour and then resets it -- but there is no guarantee that the cell at 15, 5 is using those colours!

Here's a sample program that shows _BACKGROUNDCOLOR in use; we can read a colour without it having to be on screen. I'd like to be able to do the same with the foreground colour.

SCREEN 0: COLOR 14, 1: CLS
PRINT
PRINT "The original background is 1"
PRINT
PRINT "But the current background is ";
COLOR , 3
DIM c%: LET c% = _BACKGROUNDCOLOR
COLOR , 1
PRINT c%

This flag is already used for most of the precompiled content but not the compilation of qbx.cpp. It has the potential to give a decent speedup (which god knows QB64 programs need).

With qb64.net being shutdown, qb64.org must be added as main source for help pages.