Smile Basic

[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 :)

[joyrider3774]

yeah but fuze (well same for smilebasic) can be a step in those directions. It starts with fun (like children being able to see games they created or modified or even programmed themselves on their own switch has a big impact) and can indeed make them warm for programming in the future. But i understand what you mean, i think fuze as is smilebasic are actually good starting platforms. i remember when i was younger it was not as easy and it was some kind of ultimate goal to see things running on a console fuze and smilebasic make this a lot easier it's great for education and indeed potential professional careers. It evoluted that way with me also (interest in programming as a child due to games and not understanding how it could work, to making my own games to being a developper to make a living)

[Dave]

@niconii I can't help but notice that the 28fps you're getting with the most recent test is the exact same frame rate you got the first time you ran these tests a year ago. You then re-ran the test with an "optimised for fuze" version of the test and got 40fps. Are you sure you ran the test with the optimised for Fuze version this time?

[niconii]

yes, I'm sure, the unoptimized version now runs at ~21 fps

[niconii]

quick correction, since i just noticed 3.0.0 came out
the unoptimized version now runs at ~23 fps
the optimized version now runs at ~34 fps