Recent Posts

Pages: [1] 2 3 ... 10
1
Code and examples / Re: tiny_tokenizer qb64 version not work?
« Last post by Aurel on 19. March 2019, 16:09:20 »
Thanks to @jack   :)
-member of qb64 forum here is RD evaluator:

Code: [Select]
'recursive descent token evaluator
'trenslation by @jack 19.3.2019
DIM SHARED tc AS LONG
DIM SHARED tokens(8) AS STRING * 1
DIM SHARED token AS STRING

tc = 0
tokens(1) = "2"
tokens(2) = "*"
tokens(3) = "("
tokens(4) = "3"
tokens(5) = "+"
tokens(6) = "4"
tokens(7) = ")"

'execute---------------
CALL gettok 'start
DIM res AS DOUBLE
res = expr#
PRINT res
END

SUB gettok ()
    tc = tc + 1
    token = tokens(tc)
END SUB

FUNCTION expr# ()
    DIM v AS DOUBLE
    v = term#
    IF token = "+" THEN
        gettok
        v = v + term#
    END IF
    IF token = "-" THEN
        gettok
        v = v - term#
    END IF
    expr# = v
END FUNCTION

FUNCTION term# ()
    DIM v AS DOUBLE
    v = factor#
    IF token = "*" THEN
        gettok
        v = v * factor#
    END IF
    IF token = "/" THEN
        gettok
        v = v / factor#
    END IF
    term# = v
END FUNCTION

FUNCTION factor# ()
    DIM v AS DOUBLE
    IF ASC(token) > 47 AND ASC(token) < 58 THEN 'nums
        v = VAL(token)
        gettok
    END IF
    IF ASC(token) = 40 AND ASC(token) <> 41 THEN 'match (...)
        gettok
        v = expr#
        gettok
    END IF
    factor# = v
END FUNCTION
2
Code and examples / tiny_tokenizer qb64 version not work?
« Last post by Aurel on 19. March 2019, 14:10:25 »
well i cannot fig how to properly translate this small piece of my code
to qb64 dialect

so far:

Code: [Select]
'recursive descent token evaluator
'
dim tc as INTEGER : dim token as string : dim v as single
tokens() as string
tokens(1) = "2"
tokens(2) = "*"
tokens(3) = "("
tokens(4) = "3"
tokens(5) = "+"
tokens(6) = "4"
tokens(7) = ")"

sub gettok()
tc=tc+1 : token = tokens(tc)
end sub

sub expr()
v = term()
if token = "+": gettok() : v = v + term(): end if
if token = "-": gettok() : v = v - term(): end if
return v
end sub

sub term()
v = factor()
if token = "*": gettok() : v = v * factor(): end if
if token = "/": gettok() : v = v / factor(): end if
return v
end sub

sub factor()
if asc(token)>47  and asc(token)<58 'nums
v = val(token) : gettok()
end if
if asc(token)=40 and asc(token)<>41 'match (...)
gettok() : v = expr() : gettok()
end if
return v
end sub

'execute---------------
gettok() 'start
float res = expr()
print str(res)
3
Community news and announcements / Re: "New" retro computer
« Last post by Cybermonkey on 17. March 2019, 10:52:52 »
That's so funny and so 80s

4
SmallBASIC / Re: POINT() gives odd output
« Last post by lettersquash on 10. March 2019, 16:30:38 »
Hi Chris, that's great about the predef option, thanks!

EDITED - Oops, I'm an idiot - I posted a problem I was having, but it's obvious what's wrong, so I've deleted it.

Cheers
~
5
SmallBASIC / Re: Non-standard chrs from number pad on keyboard.
« Last post by Cybermonkey on 09. March 2019, 10:00:44 »
Okay, thanks I will try that soon.
The screenshot is unfortunately just a keyboard from Wikipedia showing the German keyboard layout...
6
SmallBASIC / Re: Non-standard chrs from number pad on keyboard.
« Last post by chrisws on 09. March 2019, 00:13:23 »
If you would like to try debugging the underlying code, the problem area is in the file src/platform/sdl/runtime.cpp in function pollEvents()
You could try placing a few fprintf statements to see what's being received from SDL. Example: fprintf(stderr, "%d\n", mod)
There is also apparently a problem with Spanish keyboard layouts.
Is that screenshot a virtual keyboard that I could install on my linux machine?
7
Offtopic / calc.exe is open sourced
« Last post by phred on 08. March 2019, 16:30:39 »
8
SmallBASIC / Re: POINT() gives odd output
« Last post by chrisws on 05. March 2019, 10:22:14 »
Hi Chris, thanks, I'll look into that IMAGE command. But I think there's still a potential issue with RGB values taken from the screen with POINT(), and I think it's probably due to antialiasing. I've found that drawing circles and then addressing random points gives different results from those drawn, which I'm guessing is an antialiasing effect. The following code just takes random positions for their colour rather than the same one plotted or within a larger area of solid colour, so it occasionally gets edges. If I run this and switch drawing mode (pset, rect and circle) only the circles cause different results (I was also causing them earlier by printing results to the same portion of screen I was taking point info from, which also causes the effect).  This is on both Android and Windows. I imagine that if I knew how to switch off antialiasing on either machine, or could do it from the programming language somehow, shapes like circles would just be drawn with the given colour (allowing 'jaggies') and only those colours could be found. I just happened to bump into the issue because I was using POINT() to test for 'collision' of graphic shapes I moved about on screen. As long as people are aware of it, it's just one of those things, a "known issue", so it's not a big deal. My little program can work fine just using pset or drawing rectangles, but if someone was moving circles about and seeing if they meet another (for ball-bouncing games, etc.) they'd meet this issue. They could get round it by just checking for non-background colours or whatever, just not assume that a yellow ball will be the same yellow all over it.

Another slight issue, by the way, is that if I draw circles (filled or unfilled) with radius R in a foreground colour, and then (in order to move them) draw over them in background, I have to use R+1, or they leave little ghost images of themselves. I guess this may also be the antialiased parts.

One possible solution would be if you can implement a command to set or unset antialiasing.

I'll check out the status bar again and get back to you.

Code: [Select]
REM SmallBASIC
REM created: 03/03/2019
repeat
  x=int(rnd*(xmax-300)):y=int(rnd*ymax)
  ' Try each of the following individually...
  'pset x,y,rgb(0xAB,0xCD,0xEF)
  'rect x,y,x+2,y+2,rgb(0xAB,0xCD,0xEF)
  circle x,y,5,1,rgb(0xAB,0xCD,0xEF)
  x=int(rnd*(xmax-300)):y=int(rnd*ymax)
  p = hex(-point(x,y))
  if p != "0" then at xmax-250,py: ? "p = ";p:pause:py+=20
  byte = right(p,2)
  if byte <> "EF" and byte <> "0" then at xmax-250,py: ? "blue = ";byte:pause:py+=20
until 0

Cheers
~

You can add this to the start of your program to turn off anti-alias drawing with LINE and CIRCLE:

Code: [Select]
option predef antialias off

I've added a note about this to the LINE and CIRCLE help pages.
9
SmallBASIC / Re: POINT() gives odd output
« Last post by lettersquash on 04. March 2019, 19:38:00 »
Yes, you're right, the status bar does disappear on scrolling down in Android. Neat. It stays put in Windows, but that's fine for me. (I scroll with the trackpad gestures on Win.)
10
SmallBASIC / Re: POINT() gives odd output
« Last post by lettersquash on 04. March 2019, 12:19:36 »
Hi Chris, thanks, I'll look into that IMAGE command. But I think there's still a potential issue with RGB values taken from the screen with POINT(), and I think it's probably due to antialiasing. I've found that drawing circles and then addressing random points gives different results from those drawn, which I'm guessing is an antialiasing effect. The following code just takes random positions for their colour rather than the same one plotted or within a larger area of solid colour, so it occasionally gets edges. If I run this and switch drawing mode (pset, rect and circle) only the circles cause different results (I was also causing them earlier by printing results to the same portion of screen I was taking point info from, which also causes the effect).  This is on both Android and Windows. I imagine that if I knew how to switch off antialiasing on either machine, or could do it from the programming language somehow, shapes like circles would just be drawn with the given colour (allowing 'jaggies') and only those colours could be found. I just happened to bump into the issue because I was using POINT() to test for 'collision' of graphic shapes I moved about on screen. As long as people are aware of it, it's just one of those things, a "known issue", so it's not a big deal. My little program can work fine just using pset or drawing rectangles, but if someone was moving circles about and seeing if they meet another (for ball-bouncing games, etc.) they'd meet this issue. They could get round it by just checking for non-background colours or whatever, just not assume that a yellow ball will be the same yellow all over it.

Another slight issue, by the way, is that if I draw circles (filled or unfilled) with radius R in a foreground colour, and then (in order to move them) draw over them in background, I have to use R+1, or they leave little ghost images of themselves. I guess this may also be the antialiased parts.

One possible solution would be if you can implement a command to set or unset antialiasing.

I'll check out the status bar again and get back to you.

Code: [Select]
REM SmallBASIC
REM created: 03/03/2019
repeat
  x=int(rnd*(xmax-300)):y=int(rnd*ymax)
  ' Try each of the following individually...
  'pset x,y,rgb(0xAB,0xCD,0xEF)
  'rect x,y,x+2,y+2,rgb(0xAB,0xCD,0xEF)
  circle x,y,5,1,rgb(0xAB,0xCD,0xEF)
  x=int(rnd*(xmax-300)):y=int(rnd*ymax)
  p = hex(-point(x,y))
  if p != "0" then at xmax-250,py: ? "p = ";p:pause:py+=20
  byte = right(p,2)
  if byte <> "EF" and byte <> "0" then at xmax-250,py: ? "blue = ";byte:pause:py+=20
until 0

Cheers
~
Pages: [1] 2 3 ... 10