Re: CHATGPT and GFXLIB2

[Hated Moron]

On 06/10/2023 09:14, Andrew Cool wrote (cross-posted from the Discussion Group):

Out of curiosity, I asked CHATGPT to write a program in BB4W to display stars on a sphere.
The code it produced is below.

This is a nice example of how ChatGPT can produce something which superficially looks sensible but on closer inspection is gibberish! To be fair, programming was not one of the tasks it was designed for.

Where can I download GFXLIB2 from?

If you mean David Williams's library of that name it has been discontinued, as far as I know, and is not (legitimately) available any more.

But the library that ChatGPT purports to be using is a figment of its imagination, as far as I'm aware. Either that or it's a library it has found in its training data that I've never encountered.

Using a sys call on a BB4W LIB also seems a bit suss? How should the GFXLIB routines be called?

David's GFXLIB2 library routines are indeed called with SYS, so that much is right.

What do you actually want to do? Displaying stars as they appear in the sky is something that SkyBaby can do.

[Hated Moron]

On 06/10/2023 22:42, Andrew Cool wrote (cross-posted from the discussion group):

I asked CHATGPT to write a program in BB4W to display stars on a sphere.

The inference there was a 3D sphere rather than a flat 2D circle/rectangle. A nice rotatable, zoomable, scaleable, programmable 3D object.

Expecting ChatGPT to write code to generate a 3D object was, to say the least, optimistic! But the functionality you asked for could very easily be achieved, either in plain BBC BASIC or using the existing 3D libraries: D3DLIBA.bbc in BB4W, webgllib.bbc (etc.) in BBCSDL.

How many 'stars' do you want, and what should determine their positions on the sphere? Random or according to some database?

[Hated Moron]

On 07/10/2023 20:50, Andrew Cool wrote (cross-posted from the Discussion Group):

The Yale Bright Star Catalog is a modest yet convenient catalog in ASCII format of the brightest ~9000 stars (roughly those visible to the naked eye)

SkyBaby's database has 8691 stars (335 named stars), so may possibly derive from the same source.

The 3D sphere can't be transparent - those stars on the far side (daylight) can't be visible through the night time side of the sphere.

I can't visualise it. You are describing a sphere viewed from the outside, but when do actual stars in the sky fit that 3D model? I can understand how the 'fixed stars' might be represented as a sphere, that's exactly what the ancients thought, but that sphere is viewed from the inside so whether opaque or transparent makes no difference.

My suggestion would be to adapt SkyBaby.bbc, since so much of the work has been done for you. Filtering the display so that only those stars brighter than a given magnitude can be seen would be a simple modification.

[Hated Moron]

Filtering the display so that only those stars brighter than a given magnitude can be seen would be a simple modification.

As it is, SkyBaby displays stars with different magnitudes as different shapes. So you'd only need to adapt this code to 'hide' stars fainter than a specified threshold:

Code: Select all

IF Mag(J%) > 7 Vdu$(J%) += Mag$(8) ELSE Vdu$(J%) += Mag$(INT(Mag(J%) + 0.5) + 1)

[Hated Moron]

Out of curiosity, I asked CHATGPT to write a program in BB4W to display stars on a sphere.

A sufficiently advanced AI (and that's probably still some way off) might, in response to that request, generate a program similar to the one listed below. It displays 500 'stars' randomly distributed over the surface of a rotating sphere.

As it turns out this is not what the OP actually wanted at all, but may still be of some interest. It's pretty much generic BBC BASIC code and will run without any modification in BBC BASIC for Windows, BBC BASIC for SDL 2.0 and Matrix Brandy.

You can also run it in your browser by clicking here. The up and down cursor keys move the 'camera' closer to (even inside) and further from the sphere respectively.

Code: Select all

      MODE 8
      ORIGIN 640,512
      GCOL 15
      OFF

      NSTARS = 500
      Radius = 300
      Scale  = 1000
      Camera = 1000

      DIM s(2, NSTARS-1), q(2, NSTARS-1)
      DIM a(2,2), b(2,2), c(2,2), r(2,2)

      FOR I% = 0 TO NSTARS-1
        lon = 2 * PI * RND(1)
        lat = ASN(2 * RND(1) - 1)
        s(0, I%) = Radius * COS(lon) * COS(lat) : REM x
        s(2, I%) = Radius * SIN(lon) * COS(lat) : REM z
        s(1, I%) = Radius * SIN(lat)            : REM y
      NEXT

      *REFRESH OFF
      REPEAT
        CASE INKEY(0) OF
          WHEN 138,142: Camera += 20
          WHEN 139,143: Camera -= 20
        ENDCASE

        a = 0        : REM pitch
        b = TIME/500 : REM yaw
        c = 0        : REM roll

        a() = 1, 0, 0, 0, COS(a), -SIN(a), 0, SIN(a), COS(a)
        b() = COS(b), 0, SIN(b), 0, 1, 0, -SIN(b), 0, COS(b)
        c() = COS(c), -SIN(c), 0, SIN(c), COS(c), 0, 0, 0, 1
        r() = b() . a()
        r() = c() . r()
        q() = r() . s()

        CLS
        FOR I%=0 TO NSTARS-1
          z = (Camera - q(2,I%)) / Scale
          IF z>0 THEN
            X% = q(0,I%) / z
            Y% = q(1,I%) / z
            LINE X%,Y%,X%,Y%
          ENDIF
        NEXT
        *REFRESH
        WAIT 1
      UNTIL FALSE

[Hated Moron]

As it turns out this is not what the OP actually wanted at all, but may still be of some interest. It's pretty much generic BBC BASIC code and will run without any modification in BBC BASIC for Windows, BBC BASIC for SDL 2.0 and Matrix Brandy.

This has been brought up again over at the Discussion Group, and since it is such a good example of what can be achieved with 'generic' BBC BASIC code (not requiring BB4W or BBCSDL-specific extensions) I thought it might be helpful for me to annotate it:

Code: Select all

      MODE 8
      ORIGIN 640,512
      GCOL 15
      OFF

This is standard 'boilerplate' initialisation: setting a 640-pixel-wide window, moving the graphics origin to the centre, setting the draw colour to white and turning off the text caret (flashing cursor).

MODE 8 means different things in different systems: in BB4W and BBCSDL it's a 16-logical-colour mode and in Matrix Brandy (and Sophie's ARM BASIC) it's a 4-colour mode, but in both the highest colour index (15 or 3 respectively) is peak white. GCOL 15 has the desired effect in both cases (because the colour number is ANDed with the appropriate mask).

Code: Select all

      NSTARS = 500
      Radius = 300
      Scale  = 1000
      Camera = 1000

Initialise the global variables. Note that the naming convention being followed here is that all-caps signifies a constant.

Code: Select all

      DIM s(2, NSTARS-1), q(2, NSTARS-1)
      DIM a(2,2), b(2,2), c(2,2), r(2,2)

Declare the global arrays. s() and q() both contain the Cartesian (x,y,z) coordinates of each of the 'stars' (before and after rotation), with the first subscript being 0 for x, 1 for y, 2 for z, and the second subscript being the star number (0 to NSTARS-1). a(), b(), c() and r() are 3x3 rotation matrices.

Code: Select all

      FOR I% = 0 TO NSTARS-1
        lon = 2 * PI * RND(1)
        lat = ASN(2 * RND(1) - 1)
        s(0, I%) = Radius * COS(lon) * COS(lat) : REM x
        s(2, I%) = Radius * SIN(lon) * COS(lat) : REM z
        s(1, I%) = Radius * SIN(lat)            : REM y
      NEXT

Initialise the stars to random positions over the surface of a sphere. I used Google to find the formula for a uniform distribution, which is expressed in polar coordinates (latitude and longitude); these are then converted to the required Cartesian coordinates.

Code: Select all

      *REFRESH OFF
      REPEAT

This starts the main loop. The *REFRESH OFF is not strictly necessary (and isn't accepted by ARM BASIC) but makes the display less flickery in BB4W, BBCSDL and Matrix Brandy.

Code: Select all

      
        CASE INKEY(0) OF
          WHEN 138,142: Camera += 20
          WHEN 139,143: Camera -= 20
        ENDCASE

User controls. Pressing the up-arrow key, or rotating the mouse-wheel upwards, moves the 'camera' (viewpoint) in the negative Z-direction (into the screen); the down-arrow key, or rotating the mouse wheel downwards, moves the camera in the positive Z-direction (out of the screen). In Matrix Brandy and ARM BASIC 5 a *FX 4,1 must be issued for the up and down arrow keys to generate these codes.

Code: Select all

        a = 0        : REM pitch
        b = TIME/500 : REM yaw
        c = 0        : REM roll

Animate the sphere, in this case it simply rotates about the vertical axis at a fixed speed. Pitch is rotation around the x-axis, yaw is rotation around the y-axis and roll is rotation around the z-axis; in this case they take place in that order.

Code: Select all

        a() = 1, 0, 0, 0, COS(a), -SIN(a), 0, SIN(a), COS(a)
        b() = COS(b), 0, SIN(b), 0, 1, 0, -SIN(b), 0, COS(b)
        c() = COS(c), -SIN(c), 0, SIN(c), COS(c), 0, 0, 0, 1

Initialise the rotation matrices, these correspond to the standard equations which can be found in any 3D geometry reference.

Code: Select all

        
        r() = b() . a()
        r() = c() . r()
        q() = r() . s()

Combine the individual rotations (pitch, yaw, roll) into a single composite rotation matrix r() using matrix multiplication (dot product). Then rotate all the stars by multiplying their cartesian coordinates s() by this rotation matrix to give a new set of (rotated) coordinates q().

Code: Select all

        CLS
        FOR I%=0 TO NSTARS-1

Start the display of the 'stars' by clearing the screen (CLS is faster than CLG if the text viewport and the graphics viewport are the same, which they are by default) and looping through all the indices.

Code: Select all

          z = (Camera - q(2,I%)) / Scale
          IF z>0 THEN
            X% = q(0,I%) / z
            Y% = q(1,I%) / z

Convert the stars' 3D coordinates (x,y,z) to their 2D screen coordinates (X%,Y%) using the standard Perspective Projection. Check for the camera's z-coordinate and the star's z-coordinate being the same, because if they are a division-by-zero results; also check whether the star is 'behind' the camera and if so don't draw it.

Code: Select all

            LINE X%,Y%,X%,Y%
          ENDIF
        NEXT

Plot the stars as individual pixels, which is most easily achieved by drawing a zero-length line. Using PLOT 69,X%,Y% would result in them being drawn as 'points' which, depending on the screen mode, may consist of more than one pixel.

Code: Select all

        *REFRESH
        WAIT 1
      UNTIL FALSE

Complete the drawing loop and repeat forever (until ESCape is pressed). The WAIT 1 prevents excessive CPU usage in BB4W (otherwise it will loop as fast as possible using 100% CPU). In ARM BASIC 5 the *REFRESH should be omitted and WAIT 1 changed to WAIT.