Smile Basic

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

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.