Post by Ek Bass in BazzBasic ver. 1.4 released

Viewing post in BazzBasic ver. 1.4 released

Bug fix: RGB() with low blue values

Fixed a long-standing bug where `RGB(0, 0, b)` with `b` in the range 0–255 produced wrong colors. The classic example: `RGB(0, 0, 255)` drew **white** instead of blue, because the packed RGB value `255` collided with palette index 255 and fell through to the default "white" branch. The same bug also affected any `RGB(0, 0, b)` with `b ≤ 255` and `RGB(0, 0, 0)` happened to work only by coincidence (palette index 0 is also black).

Internally, `RGB()` now sets bit 24 (`0x01000000`) as a flag so RGB values and palette indices can no longer collide. Drawing primitives (`PSET`, `LINE`, `CIRCLE`, `PAINT`, `DRAWSTRING`, `LOADSHAPE`) all route their color parameter through a single resolver in `Graphics.Graphics`.

DRAWSTRING and LOADSHAPE now accept palette indices

As a side effect of the centralized color resolver, `DRAWSTRING` and `LOADSHAPE` now accept palette indices 0–15 as well as `RGB()` values. Previously they only worked correctly with `RGB()`.

DRAWSTRING "Hello", 10, 10, 12              ' Palette index 12 (light red) — now works
LET S$ = LOADSHAPE("CIRCLE", 50, 50, 9)     ' Palette index 9 (light blue) — now works

If you stored raw packed RGB integers in your code (e.g. `LINE (0,0)-(100,100), 16711680` for red), they will no longer be recognized as RGB and will be treated as out-of-range palette indices (defaulting to white). Use `RGB(255, 0, 0)` instead. There was never a documented way to construct raw packed RGB by hand, so this should affect very few programs.

Download: https://ekbass.github.io/BazzBasic/

david.JamIsFun9 days ago

https://rcbasic.freeforums.net/thread/970/challenge

Hello!
This looks interesting. Any chance to compare the speed of BazzBasic with the speeds of those languages?

Ek Bass9 days ago (3 edits)

Oh, one of these once more ;)

Im not sure what they are comparing there? General speed, in how less lines the code fits or what?

' BazzBasic version 1.4c
' https://ekbass.github.io/BazzBasic/
[inits]"><a href="https://ekbass.github.io/BazzBasic/
[inits]">https://ekbass.github.io/BazzBasic/
[inits]
</a>    LET fizz$ = "Fizz"
    LET buzz$ = "Buzz"
    LET fizzBuzz$
    LET TIMER# = TICKS
[main]
    FOR i$ = 1 to 1000
        fizzBuzz$ = ""
        IF MOD(i$, 3) = 0 THEN
            fizzBuzz$+= fizz$
        END IF
        IF MOD(i$, 5) = 0 THEN
            fizzBuzz$+= buzz$
        END IF
        IF i$ <> "" THEN
            PRINT i$; ": "; fizzBuzz$
        END IF
    NEXT
    PRINT TICKS - TIMER#
END
' 35ms via powershell
' 42ms via cli

Though every now and then, similar topics appears, those actually has next to nothing to do with the speed of the language. Except goin through FizzBuzz algo.

mopser wrote it all in two lines there. While it is possible, I personally do not uderstand why it should be done so.

dim s$[4],n$:s[0]="":s[1]="fizz":s[2]="buzz":s[3]="fizzbuzz"
for i=1 to 101:n=s[((i mod 3)=0)+2*((i mod 5)=0)]:if n="" then:print i;:end if:print n:next

Gives me a headache to read that one ;D

My 35 ms / 42 ms comes almost entirely from PRINT calls and process startup — the loop calculation itself is within a thousandth of a revolution of measurement error. Nobody controls the iron, the warm-up, or what is actually being measured (ditching+running or just running). So the numbers mostly tell you how heavy the I/O path of each interpreter is, not the "speed" of the language.

david.JamIsFun7 days ago

Hello.....actually. being an amateur hobbyist, their discussion is too difficult for me.

Gives me a headache to read that one <--- I agree with you!

So the numbers mostly tell you how heavy the I/O path of each interpreter is, not the "speed" of the language. <--- ok...thanks for explaining.

Ek Bass7 days ago (1 edit)

Im not saying those are complately useless tests, at least they can push you to hone your code faster in some cases.

But as a speed test of a language, it does not work.

FizzFuzz is relatively easy and simple IF...ELSE..END IF algorithm, But what its not, is a full size game with couple of thousand lines of codes, asset loads, importing from external files, handling user-defined functions etc.

And then there is the load up. BB fires up the whole .NET10 for the use of programmer while some other language just sets up the most minimal backends that are required. Just the running up time can change because of that pretty much.

Here is a simple test code you can try yourself if you have BB installed.

' BazzBasic version 1.4c
' https://ekbass.github.io/BazzBasic/
[inits]
    LET fizz$ = "Fizz"
    LET buzz$ = "Buzz"
    LET fizzBuzz$
    LET timesTo$ = 0
[main]
    LET timer$ = TICKS
    FOR i$ = 1 to 500000
        fizzBuzz$ = ""
        IF MOD(i$, 3) = 0 THEN
            fizzBuzz$+= fizz$
        END IF
        IF MOD(i$, 5) = 0 THEN
            fizzBuzz$+= buzz$
        END IF
        'IF i$ <> "" THEN
        '    PRINT i$; ": "; fizzBuzz$
        'END IF
    NEXT
    PRINT "TimesTo: "; TICKS - timer$; "ms"
    SLEEP 5
    IF TimesTo$ < 2 THEN
        TimesTo$+=1
        GOTO [main]
    END IF
    LET kwv$ = WAITKEY()
END

It basically does same thing 3 times. Goes through 500 000 iterations of FizzFuzz.

First round with my PC takes roughly 300-350ms. But the second and third round takes roughly 160-165ms anymore.

This is simply how .NET behaves.

On second and third round, jit has optimized itself and you can see it results.

In short programs, you cant even see this because program ends before optimizer even kicks in.

I commented out the section where "", "Fizz", "Fuzz" or "FizzFuzz" is printed. With that, code takes roughly 15.5 seconds in my PC.

But then, its more about the speed of your CLI, not the language.

Im not saying those speed tests are useless. You can learn tons from them. You just need to understand what about they are and what they compare.

david.JamIsFun4 days ago

"But as a speed test of a language, it does not work.FizzFuzz is relatively easy and simple IF...ELSE..END IF algorithm, But what its not, is a full size game with couple of thousand lines of codes, asset loads, importing from external files, handling user-defined functions etc." <---- Agree!

"And then there is the load up. BB fires up the whole .NET10 for the use of programmer while some other language just sets up the most minimal backends that are required. Just the running up time can change because of that pretty much." <---- Good point! Thanks for pointing out this.

"But then, its more about the speed of your CLI, not the language." <---- Different implementations use different techniques For example, JIT compiler, true compller, interpreter, etc. This complicates speed comparisons. Thus, people should look into speed comparisons of languages more closely.

david.JamIsFun8 hours ago

https://rcbasic.freeforums.net/post/9569/thread

Moreover, the time results of the code written in BazzBasic was also put into the summary anyway..

itch.io

Viewing post in BazzBasic ver. 1.4 released