BBC BASIC for SDL 2.0 version 1.10a released

[Deleted User 9295]

I've released version 1.10a of BBC BASIC for SDL 2.0 - the cross-platform programming language for Windows, MacOS, Linux, Raspbian, Android and iOS. The changes in this version are as follows:

1. BASIC Interpreter / Run Time Engine
   
   Bundled the Box2D physics engine (as famously used by the Angry Birds games) with all editions.
   
   Fixed a bug causing ON GOTO statements to be incorrectly tokenised (64-bit and ARM editions only).
   
   Improved plotting accuracy of 'thick' diagonal lines, outline circles and outline ellipses.
   
   Updated the Android edition to SDL 2.0.10. This has necessitated moving to a different build process (Android Studio) meaning you will need to uninstall then reinstall; see below.
   
   
2. IDEs and Utilities
   
   Updated BBCEdit to version 0.32.3, many thanks to Andy Parkes for this new release.
   
   Fixed a minor problem in SDLIDE with pasting Unicode text containing the à (a-grave) character.
   
   Fixed a bug in the Compiler utility which could cause creation of an app bundle to fail on MacOS if the installation path contains a space character.
   
   Modified the List Variables utility so that a mouse right-click clears the listbox selection.
   
   
3. Libraries
   
   Added box2dlib.bbc and box2dgfx.bbc to support the Box2D physics engine.
   
   Fixed a bug in dlglib.bbc which affected the 'Save As' dialogue in SDLIDE, also improved operability by the Amazon Fire TV remote.
   
   
4. Example Programs
   
   Added kaleidoscope.bbc in examples\graphics, adapted from David Williams's BB4W demo.
   
   Added three Box2D demonstration programs in examples\physics; these are also compatible with BBC BASIC for Windows if the Box2D libraries are installed:
   
   crates.bbc: Falling boxes; on mobile devices tilting the screen has an interesting effect!
   dangle.bbc: Touch the screen or use the mouse to grab the chain; also responds to tilting.
   lotto.bbc: A simulation of a lottery selection machine. Sorry, there's no prize if you win!

This new version may be downloaded, for all the supported platforms, from the usual location. The GitHub repository has been updated (used to build the MacOS, Raspbian, iOS and 64-bit Linux editions, currently).

If you are using the iOS edition you should install this latest release to update the certificate, otherwise BBC BASIC will stop working when the current certificate expires on 23rd February.

If you are using the Android edition you will need to uninstall the previous version before installing this one. Please check whether you have any personal files or folders stored in @usr$ and back them up (e.g. via a USB connection to a PC) so you can restore them after re-installation.

Please remember that if you use the BBC2APK Android Application Generator you should download a new APK template to ensure that any updates to the run-time engine are incorporated in your own apps.

[Deleted User 9295]

If you are using the Android edition you will need to uninstall the previous version before installing this one. Please check whether you have any personal files or folders stored in @usr$ and back them up (e.g. via a USB connection to a PC) so you can restore them after re-installation.

I've been asked to provide a little more detail on how to backup and restore the @usr$ folder. Here are the steps if you have a Windows PC:

1. Connect your Android device to the PC using a USB cable; the charging cable will often be suitable. You may get a popup on the device and/or the PC requesting that you allow the connection.
2. Using Windows Explorer (File Explorer) navigate to the BBCBasic app on the device, the path may vary slightly but is likely to be something like Android/data/com.rtrussell.bbcbasic/
3. You should see the single directory files there, this corresponds to the @usr$ folder in BBC BASIC. Copy that entire directory to somewhere on your PC.
4. Now completely uninstall the BBCBasic app from the Android device; you may need to disconnect it from the PC first. Once uninstalled the new version (1.10a) should install successfully, but you will have lost any personal files such as high-score tables or configuration info.
5. Repeat steps 1-3 above, except that instead of copying the files directory to the PC, copy the contents you saved on the PC back onto the Android device.

This is a once-off exercise made necessary by moving my development platform to Android Studio on a different PC. Future versions of BBCSDL should install normally.

[Deleted User 9295]

lotto.bbc: A simulation of a lottery selection machine. Sorry, there's no prize if you win!

For those who've not run it for themselves, here's what that demo program looks like:

[BigEd]

Rather impressive! I do like a physics engine. This link worked for me:
https://www.youtube.com/watch?v=_4Zox4PLq7s

[sweh]

I dunno if there's a problem with the Linux version, but on my Debian 10 64bit machine I'm not sure it's finding itself properly.

eg

Code: Select all

% cd /home/sweh/bin/bbcsdl.d/                                    
% ./bbcsdl

This starts up but drops me into the Basic ">" prompt. And if I do a "*." then it reports a directory of "/home/sweh/bin/*.bbc" - ie a directory _above_ where I started from.

If I tell it to directly run the bbcsdl.bbc "./bbcsdl $HOME/bin/bbcsdl.d/bbcsdl.bbc" then I get the option to pick an editor. From SDLIDE I can then load the "lotto" demo and it runs just fine.

This issue doesn't occur if I name the directory something different (eg "BBC") so I think your code is mis-matching if the directory name contains "bbcsdl".

Second issue... I loaded the "crate" demo and then compiled it. The contents of the zip file look fine..

Code: Select all

% unzip ../crates.zip 
Archive:  ../crates.zip
  inflating: Box2D231.so             
 extracting: crate32a.png            
  inflating: crates                  
  inflating: crates.bbc              
  inflating: crates_icon.png         
   creating: lib/
  inflating: lib/box2dlib.bbc        
  inflating: lib/box2dgfx.bbc        
  inflating: libstb.so               
  inflating: mkicon.sh  

But running ./crates starts... and then dies with "No such variable in module /tmp/XX/lib/box2dlib"

If I make the zip with the "crunch embedded files" option turned _off_ then it works. So I think there's a problem with the crunching.

[Deleted User 9295]

I think your code is mis-matching if the directory name contains "bbcsdl".

It works for me in Windows. I can install BBC BASIC for SDL 2.0 in a directory called 'bbcsdl' and everything works properly.

Second issue... I loaded the "crate" demo and then compiled it... Running ./crates starts... and then dies with "No such variable in module /tmp/XX/lib/box2dlib".

Again, it works for me in Windows, both using the Test button in the 'Compile' dialogue (which crunches the code just the same) or the Create Application button. It's hard to understand how the cruncher could be behaving differently depending on the OS.

I'm putting a lot of faith, perhaps too much, in SDL2 performing its 'OS abstraction layer' job and hiding the difference between platforms. I'll need to run up a Linux machine to see if I can reproduce the issues you mention.

[Deleted User 9295]

It's hard to understand how the cruncher could be behaving differently depending on the OS.

I figured it out: it's not because of the different OS, it's because I'm running 32-bits and you're running 64-bits. The library that isn't crunching properly (box2dlib.bbc) has a lot of bitness-dependent code, because of big differences between 32-bit and 64-bit ABIs which affect SYS calls.

To fix this I'm going to need to ensure that if two variable names differ only in that one is 32-bit (% suffix) and the other is 64-bit (%% suffix) their crunched versions also differ only in that respect. So if there are two variables original% and original%% they must crunch to (for example) o% and o%% respectively. At the moment they are treated as completely separate variables and crunched independently.

Thanks for reporting this issue, I'm not sure I would ever have noticed it.

[sweh]

OK, the first bug appears to be because I have a "." in the path to the program

I added a copy of debug lines to bbcsdl.c around line 750

Code: Select all

                q = strrchr (szAutoRun, '.') ;
printf("FOO: %s\n",szAutoRun);
                if (q > p) *q = '\0' ;
                strcat (szAutoRun, ".bbc") ;
printf("FOO: %s\n",szAutoRun);

Without a "." in the path I get

Code: Select all

FOO: /tmp/BBCSDL/bin/linux/x/bbcsdl
FOO: /tmp/BBCSDL/bin/linux/x/bbcsdl.bbc

Which is obviously correct.

With a "." however...

Code: Select all

FOO: /tmp/BBCSDL/bin/linux/x.d/bbcsdl
FOO: /tmp/BBCSDL/bin/linux/x.bbc

I'm guessing you're trying to remove filename extensions (".exe") but you're stripping off _any_ '." in the path.

[sweh]

OK, further debugging, I think it's the re-calculation of "p" that's the problem. Because I run as "./bbcsdl" it causes the bad path to be taken.

A simple fix is to just recalculate "p" from scratch, and then the "q>p" protection works.

This "diff" would seem to do the job.

Code: Select all

 		if (p)
 		    {
 			strcat (szAutoRun, p + 1) ;
-			p += szAutoRun - argv[0] ;
 		    }
 		else
 			strcat (szAutoRun, argv[0]) ;
+		p = strrchr (szAutoRun, '/') ;
+		if (p == NULL) p = strrchr (szAutoRun, '\\') ;
+		if (p == NULL) p = szAutoRun;
 		q = strrchr (szAutoRun, '.') ;
 		if (q > p) *q = '\0' ;
 		strcat (szAutoRun, ".bbc") ;

But I can't test on Windows!

[Deleted User 9295]

I think it's the re-calculation of "p" that's the problem.

You're right, the calculation is off - I was trying to be too clever. It's annoying that Linux and Windows differ in how argv[0] is used: in Windows it's guaranteed to contain the full absolute path to the program being run, irrespective of how the program was launched; this is really useful. However in Linux it varies according to how the program was run, it may have an absolute path, or it may have a relative path, or there may be no path at all. This makes argv[0] next to useless unless you deliberately strip off any path and replace it with the correct absolute path (if you can discover it) which is what that code is trying to do.

A simple fix is to just recalculate "p" from scratch, and then the "q>p" protection works.

Yes, it doesn't appeal to my sense of elegance but it works! I'll incorporate that in the next release; meanwhile I will keep my fingers crossed that having a dot in the path is unusual.

To fix this I'm going to need to ensure that if two variable names differ only in that one is 32-bit (% suffix) and the other is 64-bit (%% suffix) their crunched versions also differ only in that respect.

I've added the following code to achieve that, it seems to have the desired effect:

Code: Select all

      CASE TRUE OF
        WHEN RIGHT$(old$,2) = "%%":
          I% = FNsearch(Old$(), LEFT$(old$), num%)
          IF LEFT$(old$) = Old$(I%) IF ASCNew$(I%) > 32 new$ = New$(I%) + "%"
        WHEN RIGHT$(old$) = "%":
          I% = FNsearch(Old$(), old$ + "%", num%)
          IF old$ + "%" = Old$(I%) IF ASCNew$(I%) > 32 new$ = LEFT$(New$(I%))
      ENDCASE

If you want to try the revised version I've put a zipped copy of compiler.bbc here.

[Soruk]

A simple fix is to just recalculate "p" from scratch, and then the "q>p" protection works.

Yes, it doesn't appeal to my sense of elegance but it works! I'll incorporate that in the next release; meanwhile I will keep my fingers crossed that having a dot in the path is unusual.

In the Linux world, calling a program with a . in the path (e.g. ./bbcsdl) is not unusual, when a program is called the current directory is NOT searched for unless . appears in the $PATH variable, and this is generally considered bad practice to add that to the search path. Thus, if you want to run a program from an arbitrary location you have to explicitly state where from, even if you're in the location.

[sweh]

This makes argv[0] next to useless unless you deliberately strip off any path and replace it with the correct absolute path (if you can discover it) which is what that code is trying to do.

Check out the "realpath(3)" function. That should handle the magic.

eg

Code: Select all

#include <stdio.h>
#include <limits.h>
#include <stdlib.h>

void main(int argc, char *argv[])
{
  char r[PATH_MAX];
  realpath(argv[0],r);
  printf("%s %s\n",argv[0],r);
}

% a.out
a.out /tmp/a.out

% ./a.out
./a.out /tmp/a.out

% /tmp/a.out
/tmp/a.out /tmp/a.out

% /home/sweh/../../../tmp/a.out
/home/sweh/../../../tmp/a.out /tmp/a.out

So we can see that no matter how I called the program, the result is always "/tmp/a.out"

[Deleted User 9295]

Check out the "realpath(3)" function. That should handle the magic.

But it's not cross-platform! As you probably saw, I call SDL_GetBasePath() which is documented as returning "the directory where the application was run from". It may well call realpath() under the hood, but the point is that it will work on all the supported platforms, with SDL taking care of the differences. Another reason for avoiding platform-specific functions is the issue of character encoding, for example some platforms use UTF-8 encoding to support extended character sets while others (like Windows) use UTF-16; again SDL takes care of this and guarantees to return a UTF-8 path.

If I could avoid it I wouldn't call any native platform APIs at all, but there are a few functions I need that SDL2 currently doesn't support. That is getting addressed over time though, and it's getting closer to being a comprehensive OS abstraction layer. It almost makes Linux tolerable (I am a dyed-in-the-wool Windows enthusiast)!

[Deleted User 9295]

In the Linux world, calling a program with a . in the path (e.g. ./bbcsdl) is not unusual

That's different: it's not a dot in the (absolute) path to the executable but a dot in the (relative) path that you used to launch it. BBCSDL should not be troubled by that. Only if the string returned by SDL_GetBasePath() contains a dot will the current release possibly misbehave, but that won't be the case simply as a result of the common usage you quote.

[sweh]

If you want to try the revised version I've put a zipped copy of compiler.bbc here.

I'll give it a go when I get home tonight

[sweh]

If you want to try the revised version I've put a zipped copy of compiler.bbc here.

I'll give it a go when I get home tonight

The crates demo worked fine, compressed