BAM thingies in the works

[mnrvovrfc]

Some things need to be done to get the programming running correctly.  Compatibility problems with things BAM does not support 100% (like SLEEP with no value.)

RE: SLEEP without a value:
If INKEY$ works on this system like in QB64:

Code: (Select All)

DO : LOOP UNTIL INKEY$ = ""
DO : LOOP WHILE INKEY$ = ""

In QB64 would have to insert a _LIMIT executed by the second loop, otherwise it would hog the CPU.

That code snippet could be put inside a subprogram, and that subprogram's name used in place of "standalone" SLEEP.

EDIT: probably you mean the keypress should be retained after it's processed. That is harder to emulate, might have to depend on a variable that holds the last return from INKEY$, and make sure that it comes from what should have been "standalone" SLEEP.

[CharlieJV]

Some things need to be done to get the programming running correctly.  Compatibility problems with things BAM does not support 100% (like SLEEP with no value.)

RE: SLEEP without a value:
If INKEY$ works on this system like in QB64:

Code: (Select All)

DO : LOOP UNTIL INKEY$ = ""
DO : LOOP WHILE INKEY$ = ""

In QB64 would have to insert a _LIMIT executed by the second loop, otherwise it would hog the CPU.

That code snippet could be put inside a subprogram, and that subprogram's name used in place of "standalone" SLEEP.

EDIT: probably you mean the keypress should be retained after it's processed. That is harder to emulate, might have to depend on a variable that holds the last return from INKEY$, and make sure that it comes from what should have been "standalone" SLEEP.

Yup, for sure although I prefer this:

Code: (Select All)

HOLD$ = INPUT$(1)

[bplus]

https://qb64phoenix.com/forum/showthread...7#pid16467

@vince are you taking coding lessons from ARB? LOL!

[vince]

@vince are you taking coding lessons from ARB? LOL!

I miss him so much!

[CharlieJV]

do you think there's anyway I could get this QB program to run in BAM?
...

Nested IF-THEN in one line (in your loop) will have to be replaced.  System statements: replace those with END statements.  Still reviewing ...

Huh, paint me green and call me Gumby...

Nested single-line IF-THEN seems to work A-1 in BAM.  That said, I'm not all that crazy about it re readability.

The outer IF statement cannot have an ELSE statement, I think.  I'll have to test a bit more.

   

[CharlieJV]

(Added a link to test version of BAM in the OP.)

Here's a sample use case and test program for BETWEEN, CHOOSE, and IFF:

Code: (Select All)

' Test BETWEEN, CHOOSE, IFF

hour$ = left$(time$,2)

again:
    language%=_PROMPT("Select your preferred language:" + chr$(13) + chr$(13) + "1 -> English, 2 -> Francais, 3 -> Espanol." + chr$(13) + chr$(13) + "Or Cancel to end." , "" )

    IF NOT BETWEEN( language%, 1, 3 ) THEN END

    _Greeting:
        PRINT IFF( BETWEEN( hour$, 0, 11 ), _
                   CHOOSE( language%, "Good Morning", "Bonjour", "Buenos Dias" ), _
                   IFF( BETWEEN( hour$, 12, 4), _
                        CHOOSE( language%, "Good Afternoon", "Bon apres-midi", "Buenas Tardes" ), _
                        CHOOSE( language%, "Good Evening", "Bonsoir", "Buenas Noches" ) ) )

    _delay 3
goto again                           

[CharlieJV]

By fluke, I discovered that the interpreter big-time chokes when a sub/function is declared but never defined.

Way too big a pain in the caboose to fix in the interpreter, so I'm setting up the IDE to raise the red flag when there are issues, and provide details to help resolve issues.

[CharlieJV]

Currently, BAM's SLEEP statement requires the argument (a value in seconds), and does not know what to do with zero.

In the upcoming version of BAM, both no parameter and zero parameter will trigger a program to pause until user interaction with the program (either a key press on the keyboard or click/touch of the screen).

   

[CharlieJV]

INSTR currently allows only two arguments: the source string and the substring.  Upcoming version of BAM sill support start position of search:

   

[CharlieJV]

About the (already existing) WIDTH and the (upcoming) HEIGHT statements

BAM's WIDTH statement sets the number of character columns for the current screen mode.

Any screen mode, and any number of columns (not limited to 40 and 80).

BAM's HEIGHT statement sets the number of character rows for the current screen mode.

These statements alter the pixel width and pixel heights of the current screen mode, and will accordingly impact graphics statements (because of the change in number of pixels.

When a program is focused on graphics, use SCREEN _NEWIMAGE(pixel-width, pixel-height, screen_mode) to setup the screen.  Fonts for screen modes being 8x8 pixels (or 8x16 pixels in some modes), the number of columns and rows of text will depend on the pixel-width and pixel-height of the screen.

When a program is focused on text, use WIDTH and HEIGHT to setup the screen for the current screen mode.

You can try this stuff out with the current TEST VERSION of BAM.