Smile Basic

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.

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