BBC BASIC for SDL 2.0 version 1.36a released

[Hated Moron]

I have released version 1.36a of BBC BASIC for SDL 2.0 - the cross-platform programming language for Windows, Mac OS, Linux, Raspberry Pi OS, Android, iOS and in-browser. The changes in this version are as follows:

1. BASIC Interpreter / Run Time Engine
   
   Updated the Windows and MacOS editions to use SDL 2.28.1.
   
   Updated the iOS edition so that the virtual back button is recreated if required, also fixed VAL not working with a unary minus in iOS.
   
   
2. IDEs and Utilities
   
   Updated the 'compiler' to create a standalone EXE file in Windows! You can still create a ZIP archive if you prefer by explicitly adding .zip to the application bundle filename.
   
   Updated SDLIDE.bbc to support bi-directional text (e.g. right-to-left scripts like Arabic and Hebrew in a quoted string). This requires SDL2_ttf 2.20.0 or later.
   
   Updated SDLIDE.bbc to support window resizing when comparing programs.
   
   
3. Libraries
   
   Updated webgllib.bbc to support emissive materials and alpha-blending without external code, and to increase the maximum number of lights from 5 to 8. Also created a functionally-equivalent library for BBC BASIC for Windows.
   
   Updated script.bbc to support positioning the text caret (cursor) and selecting (hilighting) text. Also created a functionally-equivalent library for BBC BASIC for Windows.
   
   Updated arraylib.bbc to support MOD and SUM operations on a partial-array.
   
   Updated filedlg.bbc to support changing the filter by entering '*.ext' as the filename.
   
   Updated utf8lib.bbc to add FN_umidx() which behaves like MID$ with only two parameters.
   
   Added the DejaVuSans-Oblique.ttf font, which gives better results than slanting the standard font (desktop editions only).
   
   
4. Example Programs
   
   Added Hello_Box2D.bbc in examples/physics/samples/.
   
   Added analyser.bbc, an audio spectrum analyser, in examples/general (desktop editions only).
   
   Updated kerning.bbc (in examples/general/) to work around an apparent bug in the Harfbuzz shaping engine.

This version may be downloaded, for all the supported platforms, from the usual location (the Android and iOS editions should be installed from the appropriate App Store). The GitHub repository has also been updated.

[Hated Moron]

Updated the 'compiler' to create a standalone EXE file in Windows!

Although something of a cheat (as previously discussed) this should resolve one of the reasons sometimes cited for preferring BB4W to BBCSDL.

Standalone executables aren't a panacea however, they are inevitably more likely to attract the unwanted attention of a virus scanner than a ZIP file, and trigger a false-positive detection.

As an example of what is generated, here is a standalone Windows executable made from the BBCSDL conversion of David Williams' Alien Eliminator. Just as with BB4W executables, the first time it is run the resources etc. have to be extracted so it can take longer (sometimes a lot longer) than when run for a second and subsequent times.

[Hated Moron]

On 31/07/2023 17:09, Mark Moulding wrote (cross-posted from the Discussion Group):

Being able to send out a single executable, which requires no installation, was one of the most important features for me that BBCBasic for Windows provided, and that the SDL version did not. In many cases, this will solve the sole issue that was keeping me from migrating entirely to BBCSDL.

The exceptions are those cases where I want the executable to make no lasting changes to the user's system at all; the SDL executable leaves behind a bin directory, as well as a (?tokenized?, and therefore unreadable) copy of the original source. Many times that doesn't matter, but sometimes (for appearances to the client) it does.

When a BB4W application has resource files (images, sprites, sound effects, music, custom libraries and sub-modules etc), which the great majority of non-trivial programs will, it 'leaves these behind' in exactly the same way, this is essential to minimise the load time.

If it was necessary to extract these files from the EXE every time the program is run it would often be too slow (and it would be incompatible with installing the application in a 'write-protected' region of the file system such as C:\Program Files\).

So it's only when there are no resource files that a BBCSDL executable behaves differently from BB4W. Even then it needn't leave anything behind: it could do what BB4W executables do and store the libraries etc. under %temp% and delete them on exit.

If you think that would be a worthwhile change from the viewpoint of "client acceptance" I could consider it, but it would only significantly affect programs that don't need resource files.

[Hated Moron]

Standalone executables aren't a panacea however, they are inevitably more likely to attract the unwanted attention of a virus scanner than a ZIP file, and trigger a false-positive detection.

I should perhaps have said that standalone executables generated by BBCSDL are compatible with being digitally signed. If you have a suitable certificate you can easily use the Microsoft signtool utility to do so. Any alternative method should also work, so long as it updates the SECURITY_PTR field in the Portable Executable header.

I've now replaced the Alien Eliminator executable with one that has been signed.

[Hated Moron]

If you think that would be a worthwhile change from the viewpoint of "client acceptance" I could consider it, but it would only significantly affect programs that don't need resource files.

I have now updated the Windows edition (only) to v1.36b. In this version standalone executables behave more like those created by BBC BASIC for Windows, in that libraries and DLLs are deleted after the program has terminated rather than been left lying around on the disk.

Load time may be slightly increased, because the libraries must be extracted every time the program is run, but it's less wasteful of disk space and - in the case of a program which needs no resource files - admin privileges are not needed to run the program in a write-protected directory.

[Hated Moron]

On 01/08/2023 20:45, Mark Moulding wrote (cross-posted from the Discussion Group):

The load time is barely noticeable, but on modern hardware it's small enough to not be a bother (about a second, or two at most), and so is not a problem. I suppose that if someone were using it as a CGI-called program, that would be not such a good thing

For a CGI-called program there are the BBC BASIC Console Mode editions which are designed for just such applications. They are lightweight, compact and load very quickly, although of course they don't have graphics or sound (the Raspberry Pi Pico edition does have sound).

perhaps it could be a "compiler" option whether or not to delete the libraries when the program terminates. For my purposes, though, it's great this way - thanks again

I don't consider a Windows-specific compiler option like that to be desirable. The cross-platform credentials of BBC BASIC for SDL 2.0 are paramount, and although to a degree the 'compiler' must be more platform-aware than many other utilities (because each platform has its own preferred way of distributing applications) I want to minimise the extent to which the user is impacted.

Indeed the reason that I initially left the libraries in situ after the program terminated, unlike the way BB4W works, was precisely because every other platform does the same, i.e. it extracts all the files from the application bundle (MacOS .dmg, Android .apk, iOS .ipa or Linux .zip) just once on installation.

So whilst I can see the argument for things working a little differently in Windows, I don't want to complicate it by adding options specific to that one platform. You still have the choice of creating a ZIP file rather than an EXE, and there's nothing stopping you repackaging the contents in an alternative way, such as with an installer like Inno Setup.

[Hated Moron]

Updated SDLIDE.bbc to support bi-directional text (e.g. right-to-left scripts like Arabic and Hebrew in a quoted string).

Here's an example of what happens if you select (highlight) part of a line containing right-to-left text! It's the same behaviour as in BB4W of course, so shouldn't come as a surprise, but a major enhancement for SDLIDE.

highlight.png

[JeremyNicoll]

Here's an example of what happens if you select (highlight) part of a line containing right-to-left text! It's the same behaviour as in BB4W of course, so shouldn't come as a surprise, but a major enhancement for SDLIDE.

Why are there two blue areas? Is the selection the area between the blue parts, or the blue areas and the characters between them? Or something else?

[Hated Moron]

Why are there two blue areas? Is the selection the area between the blue parts, or the blue areas and the characters between them? Or something else?

The blue area is the selection, that's the whole point! Try it yourself, then it will be obvious (it's a shame you didn't do that before posting).

Here's the same thing in Microsoft's Notepad (Windows 11), I'm sure Word and LibreOffice etc. do the same:

notepad.png

[JeremyNicoll]

The blue area is the selection, that's the whole point! Try it yourself, then it will be obvious (it's a shame you didn't do that before posting).

I've tried it now, and you're right. I do now see what's going on.

If one starts a mouse selection within the text 'arabic1$ = "' as you move the mouse to the right it successively highlights the a, r, a, b, i, c, 1, $, space, =, space, and the first double quote. Then as soon as the mouse moves further right it reaches the leftmost arabic character - which because of the right-to-left order - is the last one in the quoted text, so all the arabic characters become selected.

It's quite tricky to adjust a selection eg to have only the first two (ie visually) rightmost arabic chars, as well as the L->R text before it.

I noticed while doing that (in BB4W 6.15a) that selection (in normal left-to-right text) doesn't work the same way as in my normal text editor, or eg Notepad. If you start a drag selection in a piece of text then drag to the right and end the drag you have some text selected. If you shift click somewhat further to the right then the length of the selected area grows. If you shift click to the left of the starting point of the original selection then you end up with text from that point up to the start of the original selection point highlighted. If though you make the original selection then shift click somewhere in the middle of the selected area, in Notepad etc the selection shrinks to just the text between the start point and the latest shift-click point, but in the BB4W editor the length of the selected area is unchanged.