0.12.18 released

[chrisws]

This is just a minor update mostly to fix the issue with keyboard handling in the SDL version.

See: https://github.com/smallbasic/SmallBASIC/releases/tag/0_12_18

Download here:

https://smallbasic.github.io/pages/download.html

Btw, the .exe's included in the zip file are:

- sbasicg64.exe - uses SDL for fast graphics rendering, compiled as a 64 bit executable.
- sbasicg.exe - uses SDL for fast graphics rendering, compiled as a 32 bit executable.
- sbasici.exe - My original port of SmallBASIC that I abandoned several years ago but recently brought back to life using FLTK 1.4.
- sbasicw.exe - Web server version that renders to your browser.
- sbasic.exe - console command line.

Cheers,
Chris

[bplus]

Yea! I can edit again! Don't have have time to give it a better check at moment but so far so good for g64.exe

[round157]

- sbasici.exe - My original port of SmallBASIC that I abandoned several years ago but recently brought back to life using FLTK 1.4.

Report: sbasici.exe still has the bug. This one:
https://www.syntaxbomb.com/index.php/topic,6677.msg33610.html#msg33610

[lettersquash]

That's great Chris, thanks - numpad keys work as expected. I don't have to keep remembering to use the numbers above the main keys now. Thanks also for the clarification of the files. I'm sticking with the SDL g64 version for now for those fast graphics on my Windows 7.

Another oddity I noticed is that the arrow keys give ASCII 27, same as the Escape key. Is that how it should be?

[bplus]

That's great Chris, thanks - numpad keys work as expected. I don't have to keep remembering to use the numbers above the main keys now. Thanks also for the clarification of the files. I'm sticking with the SDL g64 version for now for those fast graphics on my Windows 7.

Another oddity I noticed is that the arrow keys give ASCII 27, same as the Escape key. Is that how it should be?

I haven't checked with current update but arrow keys give two character code usually the first, an escape is it? and second (or one on right), for sure, the arrow number code.

Code: [Select]

' Get key codes.bas SmallBASIC 0.12.9 (B+=MGA) 2017-12-18
WHILE 1 'find code for keypress
    k$ = INKEY
    IF LEN(k$) THEN
        SELECT CASE LEN(k$)
            CASE 1: PRINT "1 char keypress = "; ASC(k$)
                IF ASC(k$) = 27 THEN EXIT loop
            CASE 2: PRINT "2 char keypress = "; ASC(RIGHT$(k$, 1))
        END SELECT
    END IF
WEND



[lettersquash]

Oh wow, that's a revelation to me, I didn't realise keys gave two keys like that.
I added,

Code: [Select]

asc(left(k$,1)), and yes, it's the escape 27.

Also, the numpad gives some further keys. Numpad 8, for instance, gives:
2 char keypress = 27    9
1 char keypress = 56
So a second single after the two-byte code. Numpad 8 has the dual function of Up (ascii 9) and an 8 (ascii 56). With numlock off, just the number code is output. But there are some odd things, DEL and INS, etc. - I guess it'll depend on the keyboard layout.

Anyway, thanks, that script gives me the ability to use many more keys with inkey.

Chris, I don't know if you're reading this or it's the right place to ask, but a big request of mine would be if inkey could be speeded up. Its slow speed makes it unusable in any kind of real-time control situation like a game.

[round157]

Hi,

Another report: forget adding this feature to the sbasici.exe.
https://www.syntaxbomb.com/index.php/topic,6677.msg33355.html#msg33355

[round157]

but a big request of mine would be if inkey could be speeded up. Its slow speed makes it unusable in any kind of real-time control situation like a game.

Hi..I don't understand. I want to know more about this "inkey". How slow is the "inkey"? Any example? Thanks.

[bplus]

but a big request of mine would be if inkey could be speeded up. Its slow speed makes it unusable in any kind of real-time control situation like a game.

Hi..I don't understand. I want to know more about this "inkey". How slow is the "inkey"? Any example? Thanks.

It doesn't show as much here in this example so maybe Chris fixed something along the way but there is a difference with INKEY commented out or NOT, and make sure you have everything else off in Windows.

Code: [Select]

'Updated Plasmatic with Full Color Mixing.bas translated to SmallBASIC b+ 2020-01-24
' from QB64 "Color Mixing 4 Plasmatic" ' b+ 2020-01-23
' continued study of what makes Plasmatic tick,
' here the color palette is updated for full range of color mixing options,
' PLUS I think color band creation for palette has been a little demystified,
' PLUS more fully commented code.

' common shared unchanging variables and static arrays
const xxmax = 500 'need smaller screen for interpreted Basic
const yymax = 400
const xoff = (xmax - xxmax) \ 2
const yoff = (ymax - yymax) \ 2
dim c(360), p(6), f(6)

'start program
randomize timer

label restart 'select rgb1 and rgb2 based on mode of color mixing
IF mode = 0 THEN 'new plasma option ANY color for border and ANY color for middle
    r1 = RND * 255: g1 = RND * 255: b1 = RND * 255: r2 = RND * 255: g2 = RND * 255: b2 = RND * 255
ELSE ' traditional high contrast plasma black borders, white centers
    r1 = 0: g1 = 0: b1 = 0: r2 = 255: g2 = 255: b2 = 255 'regular Plasma
END IF

'create 6 x 60 bands of color palette based on coloring mode (rgb1 set and rgb2 set)
FOR i = 0 TO 360
    IF i MOD 60 = 0 THEN r = RND * 255: g = RND * 255: b = RND * 255 'start new color band
    m = i MOD 60 'color bands have width of 60, 4 stages
    if m < 15 then ' 1st stage increase rgb1 towards rgb color in 15 steps
       c(i) = midInk(r1, g1, b1, r, g, b, m / 15)
    elif m < 30 ' 2nd stage increase rgb color towards rgb2 set in 15 steps
       c(i) = midInk(r, g, b, r2, g2, b2, (m - 15) / 15)
    elif m < 45 ' 3rd stage decrease rgb2 color back to rgb color in 15 steps
       c(i) = midInk(r2, g2, b2, r, g, b, (m - 30) / 15)
    elif m < 60 ' 4th and finally decrease rgb back to starting rgb1 set in 15 steps
      c(i) = midInk(r, g, b, r1, g1, b1, (m - 45) / 15)
    END if
NEXT

' behind the scenes variables for motion, weighting and shaping color mixing
FOR n = 0 TO 5
    p(n).x = RND * xxmax: p(n).y = RND * yymax: p(n).dx = RND * 2 - 1: p(n).dy = RND * 2 - 1 'create points
    f(n) = .1 * RND ' create the inverse size and weight factor, large f = small globs but carry weight
NEXT

'screen labeling 3 lines for title above, 2 lines instruction below
cls
at xoff, yoff - 60
if mode = 0 then
  CP yoff - 60, "New Color Options for Plasma:"
else
  CP yoff - 60, "Traditional High Contrast Plasma: Black Borders and White Centers"
end if
CP yoff - 40, "Borders: RGB(" + str(r1 \ 1) + ", " + str(g1 \ 1) + ", " + str(b1 \ 1) + ")"
CP yoff - 20, "Centers: RGB(" + str(r2 \ 1) + ", " + str(g2 \ 1) + ", " + str(b2 \ 1) + ")"
CP yoff + yymax + 10, "Press t to toggle between Traditional and New Color Options Plasma"
CP yoff + yymax + 30, "Press spacebar to get a new color set."

'plasma in motion   
WHILE 1
    'get user input choices
   
    ' Here! Check out Plasmatic with and without INKEY
    k = INKEY   '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    IF k = " " THEN GOTO restart
    'if k = "q" or asc(k) = 27 then end
    'IF k = "t" THEN mode = 1 - mode: GOTO restart
   
    'move points
    FOR i = 0 TO 5
        p(i).x = p(i).x + p(i).dx
        IF p(i).x > xxmax OR p(i).x < 0 THEN p(i).dx = -p(i).dx
        p(i).y = p(i).y + p(i).dy
        IF p(i).y > yymax OR p(i).y < 0 THEN p(i).dy = -p(i).dy
    NEXT

    'calculate each screen x, y color based on distance to 6 points
    FOR y = 0 TO yymax - 1 STEP 3
        FOR x = 0 TO xxmax - 1 STEP 3
            d = 0
            FOR n = 0 TO 5
                dx = x - p(n).x: dy = y - p(n).y
                k = SQR(dx * dx + dy * dy)
                d = d + (SIN(k * f(n)) + 1) / 2
            NEXT n: d = d * 60
            rect x + xoff, y + yoff STEP 3, 3, c(d) filled
        NEXT
    NEXT
    'showpage 'guess this not needed might work better without
WEND

'report the color number between rgb1 and rgb2 at fraction fr from rgb1
func midInk(r1, g1, b1, r2, g2, b2, fr)
  midInk = rgb(r1+(r2-r1)*fr, g1+(g2-g1)*fr, b1+(b2-b1)*fr)
end

'Center Print at topYpixel down from top
sub CP(topYpixel, stringg)
  at (xmax - txtw(stringg))/2, topYpixel :print stringg
end sub

On my system with INKEY this graphics intense program runs a bit slower and more jerky. But I have to say this is not as bad as it once was. PS run on v sbasicg64.exe

Hey I wonder if that is what slows down the editor version from FKLT, inkey has to be on all the time. eh?

BTW using the editor may be really slow testing runs but much more pleasant for editing with tabbed files and Help access right there, but Aurel's should have that maybe more but no help access.

[lettersquash]

but a big request of mine would be if inkey could be speeded up. Its slow speed makes it unusable in any kind of real-time control situation like a game.

Hi..I don't understand. I want to know more about this "inkey". How slow is the "inkey"? Any example? Thanks.

Hi round157, here's a better example for being a bit simpler. It's also the basis of many games where you use A,Z and <> to control something. I could name at least one other language where you'd have to put delays in to stop it whizzing off the screen before you know where you are.

Code: [Select]

REM SmallBASIC
REM created: 24/03/2020
x=xmax\2:y=ymax\2
? "INKEY speed test. Use a,z and <> keys to move '@' - see how fast it is?"
? "To compare (random motion)  without the inkey statement, hit q."
? "There's still a select case, in the loop, but a random slice of 'az,.' instead of inkey."
? "Or make it a constant of your choice to see it just go in one direction."
repeat
  k=inkey
  at x,y,:? " "
  select case k
    case "a":y--
    case "z":y++
    case ",":x--
    case ".":x++
  end select
  at x,y:? "@"
  showpage
until k="q"

repeat
  at x,y:? " "
  k=mid("az,.",(rnd*4)+1,1)
'  k=","
  select case k
    case "a":y--
    case "z":y++
    case ",":x--
    case ".":x++
  end select
  at x,y:? "@"
  showpage
until 0
end
Testing for a mouse click is way faster - hardly slows things down at all, but that doesn't give much in the way of different control inputs in a loop. I'm doing all this on Windows 7, not Android, with a middling kind of processor and plenty of memory. How does it compare on yours?

[chrisws]

The best way to achieve "real time" keyboard support is using the DEFINEKEY function.

Here's an example:

https://github.com/smallbasic/smallbasic.github.io/blob/5601c8bc1d794c5b143d863555bb7c15a5966a3c/samples/node/1360.bas

[chrisws]

Hi,

Another report: forget adding this feature to the sbasici.exe.
https://www.syntaxbomb.com/index.php/topic,6677.msg33355.html#msg33355

I've created an issue for this: https://github.com/smallbasic/SmallBASIC/issues/93

[round157]

here's a better example for being a bit simpler.

I have tried your example. The problem of "Inkey" is typematic delay: when I press a key but don't release, the "@" will move one step, then will stop a moment, then will move again. I see, "@" did not move continuously. It is a problem.

[round157]

Hi,

Another report: forget adding this feature to the sbasici.exe.
https://www.syntaxbomb.com/index.php/topic,6677.msg33355.html#msg33355

I've created an issue for this: https://github.com/smallbasic/SmallBASIC/issues/93

Thank you.

[round157]

Hey I wonder if that is what slows down the editor version from FKLT, inkey has to be on all the time. eh?
BTW using the editor may be really slow testing runs but much more pleasant for editing with tabbed files and Help access right there, but Aurel's should have that maybe more but no help access.

Three editors:

sbasicg.exe -- It is an editor with dark texts(dark green, dark grey, etc.) and black background. Therefore, it is hard to view. If colours can be changed, this editor will be suitable for editing.

sbasici.exe -- "Slow motion" bug. Many graphic examples are adversely affected by the bug.

Aurel's editor -- It is a nice editor. I encourage users to give Aurel useful feedbacks for future versions.

(I tried your example. If the source code was run without the inkey statement(line 64), I could not feel speed increase in the the graphic motion.)