Smile Basic
-
@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]tosbut it seemed to drop the fps a small amount. perhapss = 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 parti 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
-
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
-
@niconii I am surprised that it is slower but no it hasn't yet
-
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.
-
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)
-
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.
-
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.
-
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 :)
-
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)
-
@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?
-
yes, I'm sure, the unoptimized version now runs at ~21 fps
-
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
