🆕 _AUTODISPLAY and ❇ _DISPLAY

_AUTODISPLAY

Although BASIC Anywhere Machine ignores the statement, it does recognise it when encountered as a valid QB64PE statement.  This is part of a longterm effort to get QB64PE programs running in BASIC Anywhere Machine (as much as possible) as is (without too much futzing about to get a program running.)

_DISPLAY

Modified so that when encountered, it actually causes a program to pause just long enough (a micro-fraction of a millisecond) to trigger a screen refresh.

🆕 _D2R

In the effort to make BASIC Anywhere Machine reasonably compatible with QB64pe:

The _D2R function converts a degree value into a radian value.

🆕 LPRINT

BASIC Anywhere Machine, being browser-based,  cannot implement output to hardware devices like traditional/installed BASIC implementations can.

However, can implement related BASIC statements in a way that maintains compatibility with the original intent of those statements, providing BAM with useful functionality that does work within the confines/constraints/rules of web browsers.

LPRINT has entered the building...

This first implementation of LPRINT keeps it simple by not allowing a list of expressions as normally typical in any BASIC:

LPRINT takes the string resulting from an expression and outputs that string to a text file. The string can contain a very large number of characters.

Syntax

LPRINT string_expression

• string_expression
  • this can be as simple as a string literal or a string variable, or a string expression of whatever complexity

🪲 Interface to the Web Audio API (beep, sound)

 A strange bug I noticed tonight, which started I don't know when.

In trying to figure out what recent change to BASIC Anywhere Machine caused the problem, I dug out an older version of BASIC Anywhere Machine that had no issues with audio, and I discovered the problem there, too.

The strange problem: the first sound played in a program via either BEEP or sound does not happen.

And subsequent sounds will only happen if the first failed sound played for at least half a second, the BEEP/SOUND statement immediately followed by a _DELAY of at least half a second to seemingly give Web Audio a chance to kick in.

Something like that.

This may only be an issue on my Chromebook and a recent update to either Chrome or Chrome OS.

As a workaround to the problem, I've setup the interpreter to not run any BASIC program until after a half-second delay, during which the interpreter "initialises" web audio.

Something like that.  Not easy to coherently explain what is going on when I can't make heads of tails of it.

So audio in BAM fixed for my device.  Now I have to find a way to see if other devices are fine.

🆕 POINT

 The POINT function returns the pixel COLOR attribute at a specified graphics coordinate.

Syntax

POINT (x,y)

x	the horizontal coordinate on the screen, which is an integer number, one of: a literal integer, an integer variable, or a numeric expression resulting in an integer
y	the horizontal coordinate on the screen, which is an integer number, one of: a literal integer, an integer variable, or a numeric expression resulting in an integer

BAM's implementation or POINT is partially compatible with both GW-BASIC and QB64PE.

In GW-BASIC and QB64, the POINT function has two syntax forms: the first returns the pixel color attribute at a specified graphics coordinate, and the second syntax returns the pixel color at the current graphic cursor position.

As per the GW-BASIC User's Guide:

Purpose:

To read the color or attribute value of a pixel from the screen.

Syntax:

POINT(x,y)

POINT(function)

Comments:

In the first syntax, x and y are coordinates of the point to be examined.

If the point given is out of range, the value -1 is returned.

POINT with one argument allows you to retrieve the current graphics coordinates.

POINT(function) returns the value of the current x or y graphics coordinates as follows:

Function	Returns
0	the current physical x coordinate.
1	the current physical y coordinate.
2	the current logical x coordinate if WINDOW is active; otherwise, it returns the current physical x coordinate as in 0 above.
3	the current logical y coordinate if WINDOW is active; otherwise, it returns the current physical y coordinate as in 1 above.

🆕 _DISPLAY and _LIMIT and ❇ _NEWIMAGE

_DISPLAY and _LIMIT

Although BASIC Anywhere Machine ignores these statements, it does recognise them at runtime as valid QB64PE statements.  This is part of a longterm effort to get QB64PE programs running in BASIC Anywhere Machine (as much as possible) as is (without too much futzing about to get a program running.)

I'm thinking I might never get around to fully implementing these statements in BASIC Anywhere Machine.  I do, however, allow myself to change my mind ...

_NEWIMAGE

BASIC Anywhere Machine still only has this as a parameter for the SCREEN statement.

So partial compatibility with QB64PE.  In QB64PE, _NEWIMAGE is a function, with a return value that can provided to the SCREEN statement directly or via a variable that gets set to the return value of the function.

Today's new version of BASIC Anywhere Machine allows a little bit more compatibility with QB64PE.  BAM was allowing only screen modes in _NEWIMAGE's third parameter.  Now, the third parameter also allows one of the following values:  256 or 32.

Although this helps running QB64PE programs as-is in BAM, BAM converts both of the values 256 and 32 to 21 (screen mode 21), resulting in 32 bit (16 million colors).

I might eventually get around to setting up a 256 color mode in BAM if and when it becomes a hot request.

For now, I think this is good enough.

🆕 Significant changes in today's release of BASIC Anywhere Machine

Just a quick note for now.  I'll try and do a video about this in the next week or two.

Summary of changes:

• Improvements for small touchscreen (i.e. mobile) devices
• Redesign of menus
• General redesign with a focus on source code management and the concept of promotion levels (just for the currently implemented levels: development and production)
• Big effort setting up menu items to analyse differences between the production version and development version of a program
• Big effort taking into consideration "includes" of program modules into other programs (via the "include" metacommand)
• Fixes to some issues with export options, addressed while simultaneously tweaking the export mechanisms to properly handle includes
• Experimental GraphViz service to via "include diagrams".

The current version of BASIC Anywhere Machine.

The previous version.

Improvements for small touchscreen (i.e. mobile) devices

Until I can get my hands on a smartphone for some real-world testing, I can't be sure that these changes actually improve things.

As per  screenshot below:

I've setup dropdown menus to hug the left edge of the display, instead of hugging the left edge of the menu label.

On desktops/laptops, the menus dropdown on mouse hover over the labels.  On mobile devices, "on hover" elements in a browser require being touched to trigger the "on hover" actions.  To hide an open dropdown menu, a mobile device user has to tap somewhere else on the display, which can cause unintended actions.  So to close an open dropdown menu with a mobile device, I've added that little icon to the left of the "File" menu label to touch.  Touching that will move the focus away from the label of the currently opened dropdown menu, causing the menu to close.

Redesign of the Menus

I reduced the number of menus to, hopefully, improve the interface for mobile device users and to generally simplify the menus.