📚 About CIRCLE: First, how CIRCLE behaves in GW-BASIC

A same CIRCLE statement produces, proportionally, the same-looking circle regardless of screen mode.

However, creating a box with the line statement does not produce the same-looking box in all screen modes.

So what does this say about the CIRCLE statement in GW-BASIC ?  To be continued ...

Here are some screenshots to compare results, using GW-BASIC running in a virtual console at the Internet Archive:

🖥 Four-Pointed SineWavy Thing

A QB64 program by bplus (a mod to vince's mod to bplus' program?), ported to BAM with mods to improve performance.

QB64 is blazzingly (the programs are compiled), so I had to but the screen resolution by half for the BAM version to have comfortable performance.

This BAM program created with, and exported from, the development version of BASIC Anywhere Machine, which doubles the speed of the CIRCLE statement and includes "Rgba" statement include libraries.

• Run the program
• View the source code
• Try the development version of BAM

🖥 Colour-Changing Fractal Fern

• Run the program
• View the source code

📚 OPTION EXPLICIT !!!

Wow.  I'm only discovering this now.

While haphazardly scanning the wwwBASIC.js code, I stumbled upon the javascript code that handles  "OPTION EXPLICIT" in a BASIC program.

I wish I had noticed that before.  That's a big deal.

Without OPTION EXPLICIT, a variable name typo gets treated like a new variable created on the spot.  And that can lead to programming errors that are very hard to pinpoint.

Let's consider a simple program example:

greeting$ = "hello there"

print gretting$

The program will run without error, but the results will be incorrect.  "gretting$" (a typo of "greeting$") gets immediately treated as a new variable, has no value assigned to it, and gets printed.  (The result: nothing printed.)

To avoid that kind of problem, which would be very hard to resolve in a long and complex program, start the program with an "OPTION EXPLICIT" statement.

OPTION EXPLICIT

greeting$ = "hello there"

print gretting$

Upon running the above program, we immediately get an error about "greeting$" being an undefined variable.  So we define it and run the program again.

OPTION EXPLICIT

DIM greeting$ = "hello there"

print gretting$

Upon running the above program, we immediately get an error about "gretting$" being an undefined variable.  And we know that this is a variable name typo.

Awesome.

Give that a spin in BASIC Anywhere Machine.

🖥 Catrun.bas, a GW-BASIC/PC-BASIC program ported to BAM

This BASIC Anywhere Machine program is a port (and mod) of a GW-BASIC program transcribed by  Solo88 from a YouTube video.

From the description for Jason Doucette's YouTube video:

Cat animation programmed in GW-BASIC, running from PC-BASIC emulator of Tandy GW-BASIC. The source of the animation data comes from an old 1984 book called "Create Your Own - Games Computers Play" by Keith S. Reid-Green

• Run the BAM program
• View the BAM source code

Jason Doucette's video

🖥Spinner, a QB64 program by b+

A program by b+ setup to work, as is, in both QB64 and QBJS, and that ported to BAM by moi:

• Run the program
• View the source code

🖥 Spinning spiral wheel

This QB64 program by "Dav" ported to, and exported from, the development version of BASIC Anywhere Machine (with speed improvement to the CIRCLE statement.)

• Run the program
• View the source code
• Development version of BAM

⚗ RgbaCircle Biaxial Mosaic

I've made some headway developing an RgbaCircle include library statement.

To test the function, here is the "RgbaCircle Biaxial Mosaic:

• Run the program
• View the source code
• Try in the development version of BASIC Anywhere Machine

📽 Version Control Features

 

🖥 Graviton, a QB64 program ported to BAM

• Run the program
• View the source code

🖥 Shell of another color (QB64 program ported to BAM, with animation mod)

• Run the program
• View the source code

This program was created with and exported from the development version of BASIC Anywhere Machine (improved performance of CIRCLE.)

🚧 In the works: faster CIRCLE

To compare the difference between the current "production" implementation of CIRCLE and the "development" implementation of CIRCLE, try running the "Flower Wheel" program:

• Production version of BASIC Anywhere Machine
• Development version of BASIC Anywhere Machine

(Both versions of BAM show the "Flower Wheel" program in the IDE at startup.)

This will be PHASE 1 of improving the performance of CIRCLE.

Improving the performance of CIRCLE will involve incremental steps, with the internals handling CIRCLE with new code in some circumstances, and handling CIRCLE with the old code in other circumstances.

Phase 1

• The old code gets triggered when any of the following optional parameters are specified: start angle, end angle, aspect
• Otherwise, the new and faster code gets triggered

Phase 2

The old code will get triggered when the aspect parameter is specified

Otherwise, new and faster code will get triggered

Phase 3

New code will handle everything, and the old code will be entirely gone.

🖥 Ever-Changing Mandala: a GW-BASIC program ported to BAM

• Run the program
• View the source code

⚗ RgbaCircle Prototype

Prototype Version 2

I've created a second version of the first prototype discussed earlier (see below.)

This version replaces the pixels in the circle's border (to delimit the area for painting) with the pixels that were there before drawing the circle, and applies the rgba colour to each of those pixels.

Compare this second version of the app (via the links immediately below) to the first version of the app (via the links at the very far bottom of this blog item) 

• Run the program
• View the source code

Prototype Version 1

Just starting to sketch out code for an eventual include library.

I think the process will involve drawing the circle in some "reserved" colour, filling that circle, and then either "undoing" the border, or replacing the border with the the original pixels (before circle drawing), and then applying the rgba colour to those original pixels.

That will mean that I will need to setup the code to copy the screen area before drawing the circle, so that we can have access to the pixels that ought to be where the border is.

Why bother with the border and why not setup the algorithm to just paint there too?

My circle algorithm, to not have any gaps in the circle, likely repeats the drawing of some pixels in the border (rounding issues etc. related to aspect ratio between pixel width and pixel height which can be different from screen mode to screen mode).  Doing rgba painting while drawing the circumference, I was getting some lines painted twice, so some of the painting coming out darker, because of double (or more) rgba painting in the same spot.

By using a "reserved" colour to draw the circle border, we can use that colour to figure out the circle area for rgba painting: we just need to find the leftmost inner border colour and the rightmost inner colour, for every line of pixels in the area, and paint between the inner borders.  Nice and tidy.

Something like that.  I'm going to need to sleep over it a little.

• Run the program
• View the source code
• Try the code in the BAM development version

🖥 GW-BASIC binary to decimal converter ported to BAM

I really love finding small and interesting GW-BASIC programs which I can quickly port to BASIC Anywhere Machine.  This is wonderful to celebrate GW-BASIC and to test out BAM's compatibility with GW-BASIC (for the BASIC things that work well in the confines of a web browser.)

This little gem by Benito Navarro Martinez and ported to BAM by yours truly (barely any effort there; YES!):

• Run the program
• View the source code

⚗ CIRCLE Algorithms Testing Enhanced

 Follow-up to ⚗ When CIRCLE feels too slow, try and test some triangle math

A fellow BASIC community member (paul doe) suggested I expand my previous test app with  a couple of fast and well-known algorithms for drawing circles:  Bresenham's circle algorithm and the midpoint circle algorithm.  paul doe also graciously shared FreeBASIC subroutines that were very easy to integrate into my BAM program with very little futzing about.

Strangely enough, my "triangle-math-based" routine (converted from GOSUB routine to subroutine for apples and apples comparison) is on pretty equal footing with both Bresenhaum's and midpoint algorithms.

Let it run long enough, and we find that my routine bests both of the other ones by a hair, with Bresenhaum's algorithm coming in second, and midpoint coming in third.  All three are all better than twice as fast as the CIRCLE statement implemented in javascript.

Now, hard to say how the three subroutines would compare if implemented in native javascript.  That's not an exercise I want to do.

Do note that all three routines have been altered to handle "aspect ratios" for different screen modes, something I insist on keeping in BAM to maintain compatibility with GW-BASIC screen modes.

I intend on replacing/enhancing BAM's CIRCLE implementation to improve the speed of circle drawing.  This comparison test with BASIC code transpiled to javascript when a BAM program is executed, it is enough to convince me that I should just go ahead and convert my BASIC subroutine into the equivalent javascript code for a re-implemented CIRCLE statement.

However, like many things, I'm going to digest it all for a bit, and wait to see if any of the awesome brains out there have notice flubs in my code or have any suggestions.

Version 2 of the CIRCLE tester:

• run the program
• view the source code

⚗ When CIRCLE feels too slow, try and test some triangle math

BAM will never be any kind of speed demon, BASIC code being transpiled at run-time to javascript.  But still, sometimes some things feel like they could be faster.

I've long felt that the CIRCLE statement in BASIC Anywhere Machine, as-is since I nabbed the wwwBASIC.js code back in Dec 2020, wasn't performing quite as fast as it could.

Not one to enjoy looking javascript in the eyeballs for any length of time, I sucked it up and looked just long enough to see too-much-for-my-liking trigonometry going on.

So I decided to apply the "test it with code" philosophy.  Not javascript code, but rather a BASIC subroutine that I'll implement in javascript when I'm ready for the bruising.

Triangle math related to triangles with right angles.  I remembered it faintly enough to think it would be useful, and knew just enough to go search the web.

If "C" is the corner of a triangle with a right angle, then the side "c" (right across from that right angle) has a length of (say a and b are the other sides):

length of "c" = square root ( "a" squared + "b" squared )

If "c" is the radius of a circle, then when "a" is the range of possible values for x, then we can calculate "b" as every value for y.  And we can do vice versa:  when "b" is the range of possible values for y, then we can calculate "a" as every value for x.  (we need to calculate both ways to not miss any pixels around the circumference of a circle.)

Lo and behold, my BASIC subroutine is twice (plus a hair or two) as fast as the CIRCLE statement's implementation in wwwBASIC.

You may find the source code for this program useful for your own testing with your BASIC implementation(s).

The program takes stop-watch-like time of drawing 50 circles with the subroutine, then does the same thing using the CIRCLE statement.  Information is printed on the screen, and the program keeps repeating all of this in an endless loop.  So we can see the time differences cumulatively over time.

• Run the program
• View the source code

The circle on the left (c1)  is drawn with the "triangle math" BASIC subroutine.

The circle on the right (c2) is drawn with the CIRCLE statement.

The "count" indicates the total number of circle-drawing iterations.  The number indicates the number of times both circles have been drawn.  1 means each circle was drawn once.

Time is measured in the number of seconds taken to draw all of the circles for each approach.  So for that count of circles for each approach, the c1 circles cumulatively took 46 seconds, and the c2 circles cumulatively took 96 seconds.

Aside: about that "aspect_ratio" thing, which most folk likely wouldn't need.

That's needed in BASIC Anywhere Machine to maintain compatibility with GW-BASIC screen modes (GW-BASIC being a high priority.)

If you have access to GW-BASIC (run GW-BASIC at the Internet Archive in a web-based emulator, or whatever that is), write a program that draws a circle and a box around it, then run it in the various GW-BASIC screen modes.  You'll see the CIRCLE always stays a circle, but the box is sometimes a square, but often a rectangle.  That's because in the various screen modes, pixel height is greater by some ratio than pixel width.  CIRCLE in GW-BASIC has been implemented in such a way that it adjusts the circle as per the aspect ratio of pixel height versus width.

Trying to smooth out BAM-related communications

Communicating anything and processing (of the cognitive kind) anything, these things do not come by easily for me.  I find these things exhausting.

Using the right tool for the job helps me immensely.  However, the right tool for me is often times only the right tool for a subset of tasks.

Since I started the BASIC Anywhere Machine project in December 2020, I have found myself in a continuous struggle of refactoring workflow and choice of "tools" to try and reduce cognitive and sensory overload.

Over the course of that time, I've taken a lot of flack over communications when, really, I have no idea how to communicate anything.

So here's the plan:

• I'll be using this blog for all writing/sharing.
• I'll be using forums to
• Share links to blog items for much-better-suited discussions in those forums
• Share any link to a blog item with only the forum(s) that have a scope matching the blog item

Blogger will be central

Blogger (i.e. this blog) will be my go to communication platform for writing and sharing.  It is for me the best tool for the job of writing.  I rely heavily on formatting features to help organize my thoughts.  I cannot stand markup as it is too distracting.

I had thought that Reddit would be good as a primary communication platform, but it seems to require an app on mobile devices, and requires an account for Windows XP (as reported by one individual.)

The forums

BASICAnywhereMachine Reddit

I generally really like it, for many reasons I haven't quite yet figured out.  However, I have figured out that I really appreciate how a post in Reddit can easily be shared via "cross-posts" to other communities on Reddit.  I like this idea: "cross-pollination" of communities.

For every blog item, there will be a matching post in this Reddit.

GotBASIC Discord Channel

I find discord a bit overwhelming (everything is a shiny object), but the GotBASIC channel has got my attention something silly.  I know of nothing else that does the job of "celebrating BASIC" as well.  So whatever challenges I have with Discord, that is totally worth it.

I'm pretty sure every blog item will have a matching post in the "bam" sub-channel in GotBASIC.

BASIC Programming Language Facebook Group

Although this also screams "celebrating BASIC", and I find it much less overwhelming than discord, it is a really big bucket that makes it challenging to focus on a particular context.  I do love to reminisce on all things BASIC, and this group is stellar for being quite active: it is a very large community, so there is always very good stuff to find every day.

Here, I'll only post links to BAM programs for running and for viewing source code.

If somebody shares a program in this group and I port that program to BAM, I'll share that program as a comment to the OP in the Facebook Group.

BASIC, QBasic, GWBasic computer programming Facebook Group

Ditto (BASIC Programming Language Facebook Group)

RetroCoders Community

Although a small and not very active community it is a nice focus on "Retro Programming".  I do find it a little bit challenging to communicate there because formatting is done with markdown, which I cannot stand because I rely heavily on WYSIWYG formatting to organize my writing/thoughts and markup really painfully distracts me.

There, I'll only post about programs or BAM enhancements that support the scope of "retro programming".

Friends of Basic 

That is pretty much a dormant forum except for occasional posts be two or three of us.  Although the WYSIWYG editor is nice, the advertisements are a little bit annoying.

I post there as I post to RetroCoders because it is worth trying to give anything good for BASIC some kind of pulse.

QB64 Phoenix Edition Community

This is a great community.  When created BAM, the original intent was to create a sidekick for QB64 for porting QB64 programs to the web.  Despite lack of interest in BAM in huge interest in QBJS (for porting QB64 programs to the web), the community is very helpful in explaining to me how the QB64 BASIC works for when I'm attempting to create compatible statements/functions, and/or provide workaround code.

Although the community is generally very welcoming of BAM-related posts, there isn't much point in my sharing anything BAM-related in the forum unless it is to provide context when I'm trying to understand how QB64 works.

💡 BAM programs as "web services": The Pie Chart Service

(Nothing fancy in regards to pie-charting.  I aimed at just good enough for demonstration purposes !)

Although "web apps" would look better and perform better in pure javascript and CSS, I much prefer programming in BASIC.

This "Pie Chart Service" demonstrates how a BAM program, exported as a "Stand-Alone" program, can produce pie charts based on data provided to the program via a URL query string.

About "Stand-Alone" program export:

When you select the option to share a program as a stand-alone program, BAM exports to fairly small HTML file the BASIC program, the interpreter (i.e. all of the javascript code that interprets the BASIC program) and the HTML for the single-file web page to run in a web browser.

Share the exported HTML file by email or host it on the web, or store it locally for offline use.

The program accepts two parameters in the query string: screen mode (optional) and data.

Screen mode determines what colours are available to you in the pie chart.  The screen mode options are:

12 (0-12 will be treated as 12; no screen mode specified, 12 will be assumed)

This mode will provide a 16-color palette (colour mode "p16").  Black and white reserved for the program, that will leave you with 14 colours for your pie chart.  (See "About Colour Modes" for information about the ID numbers for the colours.)

17 (13-17 will be treated as 17)

This mode will provide a 64-color palette (colour mode "p256").  Black and white reserved for the program, that will leave you with 62 colours for your pie chart.  (See "About Colour Modes" for information about the ID numbers for the colours.)

27 (any number above 17 will be treated as 27)

If you want maximum flexibility for your colour choices, this mode allows for the 16,777,216 million colours available via RGB values.

To view the available colours for "p16" and "p256", visit the SCREEN Modes documentation and scroll down to the "colour modes" section.

Data defines the pie slices in the pie chart.  Each pie slice has two attributes: [1] a number indicating the size of the slice as a percentage of the entire pie (without the percent sign, i.e. just the number) and [2] the colour of the pie slice specified as a colour ID (for screen modes 12 and 17) or a hex number representing an rgb value (for screen mode 27). Every data value must be followed by a comma.

The program

• View the source code
• Run the program
• Screen mode 12 sample
• url query string: DATA=12,2,13,5,25,8,30,11,20,14,
• (screen mode 12 assumed)
• Screen mode 17 sample
• url query string: SCREEN=17&DATA=12,36,13,12,25,42,30,26,20,49,
• Screen mode 27 sample
• url query string: SCREEN=27&DATA=12,FF0000,13,550000,25,555500,30,00FF00,20,0000FF,

To embed a pie chart in a web site, using the screen mode 17 sample:

<iframe src="https://basicanywheremachine.neocities.org/sample_programs/Pie%20Chart%20Service.prod.run?SCREEN=17&DATA=12,36,13,12,25,42,30,26,20,49," style="width:250px;height:250px;"> </iframe>