Smile Basic

niconii

i created a benchmark to compare smilebasic 4 and fuze, involving 4096 ball sprites bouncing around the screen

the results were as follows:
smilebasic 4: 60 fps (~85 fps when uncapped)
fuze: ~28 fps

in fuze, the sprites themselves seem fast enough, rather the issue seems to be the language interpreter; smilebasic compiles to bytecode and it seems to have a speed advantage because of it

i posted more details and videos/screenshots on twitter here:

i tried to make the sb4 and fuze versions of the programs as close to each other as possible in the interest of fairness, but i admit that i'm more experienced with smilebasic than fuze, since smilebasic has been around since the DSi... so, if you have any suggestions for making the fuze program faster while remaining equivalent, i would really appreciate it

PB____

If you make the project public (by submitting it), people can look at the source.

Personally I've not bought SmileBasic though. Is it true that you need to pay €5 euro's to add content to the platform. And you need to pay to download from the platform as well, without paying the creators?

SteveZX81

I tried to use it again last night and there are a couple of things I like about it but sadly I am utterly put off by the UI which is just incredibly user unfriendly and I just don't see me ever using it as it's too annoying and that is a shame as more options are always better. Fuze is far from perfect but much easier to use in my opinion.

pianofire

@PB____ It has been submitted it is just awaiting approval

niconii

i don't know about euro prices in particular as i live in the US, but it works something like this:

smilebasic 4 itself costs $25, and out-of-the-box allows for only one download per 8 hours, and no project uploads
smilebasic 4 with one server ticket costs $30, and allows for unlimited downloads and 10 project upload slots
each additional server ticket past the first one adds 10 more project upload slots

server tickets never expire or get used up, they're permanent expansions despite the odd name choice

now, some caveats with this:

technically speaking the $25 version was never supposed to exist. originally smilebasic 4 was planned to only be sold as a bundle with one server ticket, but they had issues with it not showing up properly in the eshop unless it was sold standalone
it's possible to have multiple program files in one project. the project size limit is 20 MB, and as you might know, text doesn't take up much space, so you could easily have hundreds of small programs in a single project
project upload slots can be reused if you take down older projects. the 3ds version of smilebasic had a similar system, and what i often saw people do was issue new programs as separate projects initially, but later down the road consolidate multiple into a single project

personally speaking, i've owned smilebasic 4 since it launched in japan 11 months ago, and have never felt the need to buy more than the one server ticket bundled with it. i think it ought to be viewed as a $30 game with $5 upload expansions for the diehard fans, but i'm sure others won't see it that way

pugmartin

Very interesting info niconii really appreciate the detail. The comparison is fantastic.
I see where Steve is coming from though regards the UI - it’s the biggest barrier to entry.
Discostew- I get your point regards ease etc however my feedback is as someone who acknowledges Fuze’s sample images, maps functionality etc and... still chooses to create everything from scratch. I’ve always written my own handlers where relevant, and still think Fuze comes out on top primarily because... the UI is excellent. That barrier to entry is a little less

Martin

Just for the record, I'll be keeping a close eye on this thread. Being all grown up and acknowledging that a competing product exists is one thing but if we start to get into the realms of it being an advert for Smile Basic then clearly that's not going to be allowed as this is the community forum for Fuze4

pugmartin

Thats fine @Martin i’ve winced a few times reading through - it must be tough for you guys trying to walk the line between fair and having to pull the plug

petermeisenstein

@Martin Yeah i think also on the one hand this thread is also maybe a new inspiration for the fuze team but i dont think that we need advertisment here.

pianofire

@niconii I managed to get another 10 fps by using the sprite speed functions rather than using separate variables and setting the location but I suspect that the bytecode compilation is making the difference. I believe that Fuze is working on something similar.

Martin

@pianofire I somewhat surprisingly got a modest couple of FPS by using len(sprites) as the upper loop bound in each case. Using custom sprite properties instead of the two additional arrays however dropped around 3 FPS. Didn't really expect that.

niconii

@pianofire i tried to use setSpriteSpeed but in the end i only managed about 2 fps more... could you show me the code you have?

pianofire

Sure

numSprites = 4096
array sprites[numSprites]
setMode(1280, 720)
ballImg = loadImage("Ball", false)
sf = 35
for i = 0 to len(sprites) loop
    sprites[i] = createSprite()
    setSpriteImage(sprites[i], ballImg)
    setSpriteColor(sprites[i], rnd(1.0), rnd(1.0), rnd(1.0), 1.0)
    setSpriteLocation(sprites[i], rnd(gWidth()), rnd(gHeight()))
    setspritespeed(sprites[i], (rnd(40)-20) * sf, 0 )
repeat

gw = gwidth()
gh = gheight()
loop
    clear()
    for i = 0 to len(sprites) loop
        if sprites[i].y >= gH then
	    sprites[i].y = gH
   	    sprites[i].y_speed = ( -10-rnd(30) ) * sf
	endif
	if sprites[i].x <= 0 or sprites[i].x >= gw then
            sprites[i].x_speed *= -1
	endif
	sprites[i].y_speed += sf
    repeat
    updateSprites()
    drawSprites()
    update()
repeat

PB____

@Martin said in Smile Basic:

Just for the record, I'll be keeping a close eye on this thread. Being all grown up and acknowledging that a competing product exists is one thing but if we start to get into the realms of it being an advert for Smile Basic then clearly that's not going to be allowed as this is the community forum for Fuze4

I think that's fair enough.

It's interesting to read about the differences between FUZE and SmileBasic, but I hope FUZE won't try to be SmileBasic.

If I'm honest, I'm personally not much of a fan of the BASIC syntax 😱. Of course FUZE is basic too, but it's more evolved, more modern, to something that I can enjoy (even though that I'd much rather use } in stead of ENDIF, but that I can live with). When I see coding samples of SmileBasic, that doesn't make me happy.

Also I think FUZE has a really nice community and a well designed website. You guys clearly have put in the effort where it matters for your targeted audience, and I'm sure there will be other people who see that.

pugmartin

With you on the { and } mate definitely. Even as a beginner I found it more intuitive

Something

Personally, I could go for an even simpler programming tool in addition to these ones. Even Fuze is quite hard for me to understand. Does anyone remember Warioware DIY on the DS? Something like that would be cool. There was no actual coding, it was entirely visual. So not good for teaching how to code like these ones can, but you could make games with it. The options and tools were quite restrictive in what you could do in order to preserve ease of use. But if you thought about it enough and used some creativity, you make pretty much anything in 2D. The one major roadblock was that each game could be no longer than a few seconds long.
As far as I know, you can't get the cartridge anymore and the online server was turned off. So I guess I count myself lucky I got it before then.

Martin

@Something bear in mind that Fuze the company exists in order to teach and promote the teaching of code to youngsters, not to promote creating games. Of course the fact that you can pretty much guarantee that the bulk of the target audience love creating games is a very happy coincidence.

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.