Smile Basic

[Discostew]

I will say this though. SmileBASIC doesn't have structs that you can define.

[Martin]

OK, so I hate to be "that guy" but re: the benchmark of that sprite program. I do feel a bit compelled to point out that the difference between 4096 sprites on screen in Fuze and 4097 is, well, no difference at all but 4096 is the maximum SB can do. At 8192 sprites on screen Fuze starts to hurt pretty bad mind. Also that there isn't any FPS difference in Fuze between doing 4096 at 1280x720 or 1920x1080 (in my highly un-scientific test).

But of course, these comparisions are pretty pointless. 4096 sprites is a pretty extreme number. Not saying that nobody is ever going to need that many but you get my point. But also, yep, I'm sure there are areas where one product scores hugely over the other in both directions.

What counts is what people do with the products and I'm very much looking forward to seeing what comes out of both. Most people in the Western world apart from those hardcore ones that have been using the Japanese release are only just getting to grips with SB so I'm looking forward to seeing what appears.

[Something]

@Martin That makes me think. How much of the Switch's power is available for use in Fuze? I assume it's lower than the hardware specs for various reasons.

[niconii]

@Martin the sprites are beside the point. while it's true that almost no one's going to actually use that many, what's being measured here is actually the speed of the respective interpreters

fuze can absolutely handle 4096 sprites at 60 fps; what slows it down is actually the comparisons and branching within the inner for loop

anyway, both programs have been optimized a bit now:
sb4: ~110 fps
fuze: ~40 fps

i've apparently lost the ability to post links, but the programs are available at the same keys as before, and the new screenshots are in the replies of the previous tweet i posted
sb4 key: 4N3AN43PF
fuze key: NXY3N3GDNA (though it's just pianofire's code from above)

EDIT: false alarm, it's just that tweets seem to be embedded now instead of simply being a link, but firefox blocked it as part of its tracking protection

for those who can see it:

[Martin]

As has already been pointed out, in a twist that I wasn't aware of, you're comparing apples and oranges if one compiles to bytecode and the other doesn't (I was of course aware that Fuze doesn't)

[niconii]

comparing how fast both products perform the same task is not comparing apples to oranges

the fact that smilebasic compiles to bytecode is an implementation detail that is not seen by the user; in both products you simply press f5 in the editor and the code runs near-instantaneously

if fuze in fact had a bytecode compiler and i had simply disabled it, then you would be right in saying that, but that's not the case

i am comparing the two products as they exist today; of course this benchmark can and should be revisited if/when fuze gets a bytecode compiler

[Something]

@niconii In ordinary use it doesn't make much of a difference. Realistically, the main differences are UI, ease of use, level of beforehand knowledge required to use the program and also what it's actually for. Fuze has great tutorials ( hopefully that will be focus of future updates, to add more tutorials ) that can offer an entry level starting point in programming. Smile, on the other hand, appears to be more for people already deep into programming and just want to do it on console instead of PC, which is fine but different.

Apples and oranges aren't a good example, more like tables and chairs. You can eat on your lap or stand by a table, but it's more comfortable to sit on a chair and eat from the table. You can use one or the other, depending on your needs, but if you can, have both.

[Willpowered]

@niconii Haven't tested the following code, but I think these changes to your game loop might speed it up slightly (with some inline comment explanations):

gw = gwidth()
gh = gheight()
loop
    clear()
    for i = 0 to numSprites loop // Remove function call, length of this array never changes. Not a huge deal as this only happens once per loop.
        s = sprites[i] // Reduce array access
        pos = getSpriteLocation(s) // Get the position rather than accessing with .x, .y
        speed = getSpriteSpeed(s) // Will allow us to set s.x_speed and s.y_speed later in one function call
        if pos[1] >= gH then
	    pos[1] = gH
   	    speed[1] = ( -10-rnd(30) ) * sf
	endif
	if pos[0] <= 0 or pos[0] >= gw then
            speed[0] *= -1
	endif
	speed[1] += sf
	setSpritePosition(s, pos)
	setSpriteSpeed(s, speed)
    repeat
    updateSprites()
    drawSprites()
    update()
repeat

I suspect using sprite functions rather than shorthand variable access might increase speed since it will eliminate internal string comparisons for the sprite's variable names. Even though there's a little overhead of creating some new variables, there's a decent chance that might be faster overall. I'd be interested to see if some or all of these changes improve performance!

[Dave]

I'm a little late to the party, it's great to see all the discussion here. Of course we will have to monitor whether this is all crosses a very common sense line for moderation.

I think it is worth saying that the Fuze team has been working on byte code for some time. We haven't been able to put this at the top of the priorities list as of yet, but it's understandbly going to be as we move forward.

Just wait and see :) Thank you so much to @pianofire, @Martin and @Willpowered for your contributions to this thread!

[petermeisenstein]

@Dave You always talking about the priority list.But what is at the priority list ?Maybe it would be interesting to know.Of course in a other thread

[PickleCatStars]

@petermeisenstein they’re doing Fuze Player first, and bugfixes before other things, as far as I know.

[Martin]

Thanks toxibunny. Needless to say, the exact priority list is not something that’s made public. Things are often fluid but even if they weren’t you wouldn’t be able to win, whatever your priorities, they wouldn’t be right for someone

[niconii]

@Willpowered said in Smile Basic:

@niconii Haven't tested the following code, but I think these changes to your game loop might speed it up slightly (with some inline comment explanations):

unfortunately the opposite seems to happen, dropping the fps down to 25 or so... i even tried applying just the advice about changing sprites[i] to s but it seemed to drop the fps a small amount. perhaps s = sprites[i] copies the sprite handle and is somewhat slow as a result, but i don't know much about fuze's internals so that's just speculation on my part

i know this talk of benchmarks is getting on some people's nerves, but i think both the smilebasic and fuze programs are about as optimized as they're going to get now (at least i don't expect more than a 2~3 fps increase), so don't worry, i'll move on from this topic now

the final results for the time being are ~218 fps for smilebasic and ~40 fps for fuze:

i look forward to fuze's bytecode compiler once it's ready, and i'll revisit this benchmark at that time

[niconii]

it's been nearly a year now, so i decided to revisit this benchmark

using the same code as before, the numbers are now ~223 fps for smilebasic and ~28 fps for fuze

judging from this, it seems fuze has gotten a fair bit slower over the past year, so i take it bytecode hasn't been implemented yet

[pianofire]

@niconii I am surprised that it is slower but no it hasn't yet

[SteveZX81]

Sadly our patches are glacially slow but I personally put that down to Nintendo, not Fuze devs. (or course I have no inside information and this is only my personal opinion and could be utter nonsense) After the last big patch, we were supposed to get future updates much faster, sadly the total opposite has happened. I have my suspicions why but this not the place to go into it.

Will we get the updates and features we want? sure but Nintendo will make sure it takes a long l o n g time.

but is it worth it? without a moments doubt, oh yes! very much so.

[joyrider3774]

i also noticed for loops are 10 times slower in fuze compared to smilebasic (i own both programs but i still prefer the basic flavor / language / assets and general program of fuze even though smilebasic is faster)

[PB____]

I do look forward to the performance improvements that the Fuze team have in the pipeline. That would enable either to be less concerned with optimization, or do more within a frame. And both would be nice for Fuze.

However, to have a Fuze vs Smile Basic comparison only based on performance sounds a bit conceited to me. I still haven't tried out Smile Basic, but when I look at the screenshots of the code editor, the Fuze one looks better to me. And the announced update will drastically improve the usability of that editor in Fuze, I like that decision as well.

When it comes to languages like Fuze and Smile Basic, I think the first priority should be to make sure that new unexperienced users can have fun creating something simple on the screen as quickly as possible. And, of course, at the same time, it should be possible to create interesting full projects that inspire as well.

However, lets be real here as well. There are some really good alternatives out there if you don't limit your horizon to programming for the console. So if you want to move away from Fuze based on performance reasons, then maybe it's time to look up in stead of sideways.

[joyrider3774]

i already did a few projects for other (linux) handhelds; raspberry pie, windows and linux in c / c++ and delphi.(so have i gone backwards then ? :)) For me being able to do console stuff on an easy way is actually more fun i also like the assets more in fuze as said before and i agree with the code editor part . As said i still prefer fuze over smilebasic because the overall program looks better and more intutive. I prefer also the language more (like available functions and 3d stuff). also fuze is still interpreted so can't compare it to languages that compile to binary format like the ones i mentioned. But both fuze and smilebasic run on the same platform so it's only natural to compare these and i see nothing wrong with it. however smilebasic from what i understand has had a lot more time for improving things since it existed on other platforms from what i read.

[PB____]

I've created a few games in Fuze as well, and I do have the intention to create more. I don't think Fuze is a step to some negative direction (whether that be backwards or downwards).

What I meant, is that if you are proficient with c / c++ (just to name something from your list), then that's also a skill that can immediately be useful in a professional context. This is not the case with Smile Basic (or Fuze), but when you use Fuze, the point is more to have fun with it :)