LoginLogin

Fuze Basic - First Impressions

Root / Programming Questions / [.]

seggiepantsCreated:
Despite the fact that I don't have a Switch, the closing of MiiVerse prompted me to check out Fuze Basic on the computer. I've got to say, this is one of the strangest BASIC variants I have seen. I was wondering what everyone else thought of it, or if anyone else has even tried it. So let's list of some of the annoyances and oddities I have seen so far in my first 30 or so minutes of poking around.. My computer has several memory card slots. Every time I go into Edit mode, it pops up an error message for every slot without a memory card in it. This is infuriating since when you click RUN, it closes the editor. So you basically have to dismiss the errors over and over and over again. You also can't edit a file and try things out in immediate mode at the same time. Going into Edit mode blocks input in immediate mode until you are done. I found that it is easier to edit in Notepad++ then LOAD("") the file before running. This is just sad. May not be an issue on the switch. If you know me, you know that I REALLY REALLY like to declare my variables ahead of time. VAR on SmileBasic is very much non-standard but I am quite fond of it. The standard way would be to use DIM. FuzeBasic has DIM, but it is for Array's only (super strange). There is also a keyword called LOCAL where I can declare variables local to a function/procedure, but there is no way to pre-declare a global variable. Grrr. I think the % and # modifiers may be gone too. Haven't looked for PUSH/POP/SHIFT/UNSHIFT. Will be super sad if they aren't there. Speaking of Functions, the syntax is different and you have to put FN in front of a function when calling it ... weird. I would miss the OUT parameters in SmileBasic. I expect the graphics library to be different so I won't go into that. Smile Basic's graphics library is very much non-standard after all. I will say everything seems to be double-buffered. You have to call UPDATE to move changes to the screen. That might be a good thing, not sure. Looping constructs are non-standard. Instead of FOR / NEXT , you have FOR LOOP/REPEAT. While and Repeat loops are also different syntax. PRINT doesn't let you print out multiple variables (ex. Print A, B), if you want them both printed it seems you have to wrap them in STR$() and concatenate them. It doesn't seem quite as primitive as I feared but I would still miss SmileBasic. Still no user-defined types unfortunately. I really wanted that one. I guess I have time to play around with it. I don't think it comes out until Q2 2018. I will say I would rather have a SmileBasic for Switch. Obligitory Screen Shot:

does it currently have any sprite functionalities at all or even music or sound features? how fast is the pixel render? Can you draw pixels to the screen and fill it, is there a primitive filled box command? can you set the draw color AT THE VERY LEAST... AT THE VERY LEAST we could create our own sprite format that has the sprites built into the code, and then move them around by constantly re-drawing each one from a 2D pixel based array... buuuut.... if it lags or is too slow then that's a no-go..

does it currently have any sprite functionalities at all or even music or sound features? how fast is the pixel render? Can you draw pixels to the screen and fill it, is there a primitive filled box command? can you set the draw color AT THE VERY LEAST... AT THE VERY LEAST we could create our own sprite format that has the sprites built into the code, and then move them around by constantly re-drawing each one from a 2D pixel based array... buuuut.... if it lags or is too slow then that's a no-go..
I think there are sprites but no BG tiles.

I heard, on their website, that they are going to improve on their language for the switch. Currently, there is no PUSH/POP/SHIFT/UNSHIFT

I made a small program where you have a character walk around for a second test (see below). I did see something in the help file about sound, but I can't say I have tried it out. I did a small pixel plotting test for a 640x480 window and got about 8 frames per second (quite a bit faster than I expected actually) but that is probably processor dependent. Today's annoyances include having to type REM instead of ' for comments, and there not being an ELSEIF command. Here is a screen shot of the test program. Finally, the test program.
REM Create a sprite for the walking guy.
REM Why don't we have the ability to do a texture atlas :(
frames = 4
REM 200 pixels/second.
speed = 200
game_over = FALSE
frame_num = 0
frame_count = 0
frame_time = 64000

SETMODE(640, 480)

guy = NEWSPRITE(frames)
FOR i = 0 to frames - 1 LOOP
	LOADSPRITE("walk" + str$(i) + ".png", guy, i)
REPEAT
guy_X = (GWIDTH / 2) - 8
guy_Y = (GHEIGHT / 2) - 8
t2 = MICROTIME - 16

SETSPRITESIZE(guy, 200)
REM For some reason 0, 0 is the bottom left instead of top left ... Grr.
PROC DrawBackground(100)
PRINTAT(0, 0)
PRINT "Q = EXIT"
PRINT "LEFT, RIGHT, UP, and DOWN to move."

LOOP
	t1 = t2
	t2 = MICROTIME
	REM For time based movement.
	dt = t2 - t1 
	key_left = SCANKEYBOARD(scanLeft)
	key_right = SCANKEYBOARD(scanRight)
	key_up = SCANKEYBOARD(scanUp)
	key_down = SCANKEYBOARD(scanDown)
	game_over = SCANKEYBOARD(scanQ)
	CLEARKEYBOARD
	
	IF key_left AND (NOT key_right) THEN
		guy_X = MAX(0, guy_X - ((dt * speed)/1000000))
		SETSPRITEFLIP(guy, 1)
	ELSE
		IF key_right AND (NOT key_left) THEN
			guy_X = MIN(GWIDTH - 32, guy_X + ((dt * speed)/1000000))
			SETSPRITEFLIP(guy, 0)
		ELSE
			IF key_up AND (NOT key_down) THEN
				guy_Y = MIN(GHEIGHT - 32, guy_Y + ((dt * speed)/1000000))
			ELSE
				IF key_down AND (NOT key_up) THEN					
					guy_Y = MAX(0, guy_Y - ((dt * speed)/1000000))
				ENDIF
			ENDIF
		ENDIF
	ENDIF
	
	frame_count = frame_count + dt
	IF key_up OR key_down OR key_left or key_right THEN
		IF frame_count > frame_time THEN
			frame_count = frame_count - frame_time
			frame_num = (frame_num + 1) MOD frames
		ENDIF
	ELSE
		frame_count = 0
		frame_num = 0
	ENDIF
	
	PLOTSPRITE(guy, guy_X, guy_Y, frame_num)
	UPDATE
	
REPEAT UNTIL game_over = TRUE

PRINT "Bye"
END

DEF PROC DrawBackground(NumBoxes)
	LOCAL i
	LOCAL w
	LOCAL h
	LOCAL x
	LOCAL y
	
	FOR i = 0 TO NumBoxes - 1 LOOP
		RGBCOLOUR(RND(255), RND(255), RND(255))
		w = RND(GWIDTH / 2)
		h = RND(GHEIGHT / 2)
		x = RND(GWIDTH - w)
		y = RND(GHEIGHT - h)
		RECT(x, y, w, h, TRUE)
	REPEAT
ENDPROC

This definitely seems like a language that would be ok for learning programming for the first time, but as soon as you want to do something for yourself it would get really annoying. I hope we get SB on the switch...

This definitely seems like a language that would be ok for learning programming for the first time, but as soon as you want to do something for yourself it would get really annoying. I hope we get SB on the switch...
We should make a petition to request SmileBoom to port SB to the switch and compile a list of features we want. We should also make sure they understand that everyone on that petition will want to at one point or another actually make the purcahse. only people planning to actually buy it should sign the petition that way this gives SmileBoom a valuable amount of information on the demand that would exist and on estimated guaranteed purchases. If we can get enough people to sign it who actually are LIKELY to buy a switch and buy SB on switch then we can appeal to their financial side.

I don't think a petition is the right way to go. To be honest, if money were really their primary motivator, they would not have made a BASIC for the 3DS. Ultimately, I think they'll make it if they want to make it, so trying to rally a big group of people to sign a petition to motivate them financially feels unnecessary. Not only that, I think it would end up having the opposite effect. It's been years since SmileBASIC came out in Japan and North America, and it came out very late in the 3DS life cycle in Europe and Oceania. There's not many people paying attention to SmileBASIC at the moment, so most people that would be interested probably won't hear about the petition to begin with. That's going to mean few signatures, which is just going to make a Switch version look like a worse financial choice than it actually is. For what it's worth though, it seems that the president of SmileBoom is already considering it.

I don't think a petition is the right way to go. To be honest, if money were really their primary motivator, they would not have made a BASIC for the 3DS. Ultimately, I think they'll make it if they want to make it, so trying to rally a big group of people to sign a petition to motivate them financially feels unnecessary. Not only that, I think it would end up having the opposite effect. It's been years since SmileBASIC came out in Japan and North America, and it came out very late in the 3DS life cycle in Europe and Oceania. There's not many people paying attention to SmileBASIC at the moment, so most people that would be interested probably won't hear about the petition to begin with. That's going to mean few signatures, which is just going to make a Switch version look like a worse financial choice than it actually is. For what it's worth though, it seems that the president of SmileBoom is already considering it.
Oooh already considering it did I hear that right?
For what it's worth though, it seems that the president of SmileBoom is already considering it.

Today I tried porting over some smile basic code. I must say, if you tried Petit Modem 1.27 and it doesn't work, then try Petit Modem 1.3. It is tons more reliable. Super slow, but it actually works now. I decided to be easy on myself and attempted to port the mandelbrot and julia set code I made while following along with Coding Train on youtube. Irritants I found today include:
  • RGBCOLOUR changes the current pen color. So you can't say something like. B = RBG(0, 0, 0), then pass it into a graphics call. It requires saving three values then calling RGBCOLOUR before the graphics call. This turns one line of code into two.
  • There is no LEN() function for arrays, only strings. Ended up hard coding things.
  • Needed to reverse some mapping calls to accommodate 0, 0 being in the bottom left. Otherwise my drawings were upside down.
  • Parser can sometimes give you vague error messages without a line number of the problem. Turns out END SWITCH will do that if you meant ENDSWITCH and so on. Normally it will tell you the line number of a parse error. Just not always.
I worry that if FuzeBasic comes out we may not get SmileBasic for Switch. Will Nintendo really want two BASIC interpreters on the system? I would probably get both myself if offered. But I can see how SmileBoom or Nintendo may not want competing interpreters. Or we may get only one in each region or something like that. Still I guess I shouldn't worry too much until I actually buy a switch. Things I would like to see in a future version of SmileBasic:
  • Sharing that doesn't rely on secret codes you have to hunt around the internet for. There is no MiiVerse soon and that kind of breaks the current SmileBasic without it.
  • Ability to Save/Load code to the SD card. Perhaps the ability to link to something like GitHub for version control would be awesome. Ties in with the previous one kind of.
  • User Defined Types
  • Ability to New/Delete objects so I can make data structures like say a Binary Tree. Again ties in with the previous one.
  • A collection type that I can add/remove to the middle of. A dictionary object would be all kinds of awesome too.
  • Some 3D capabilities
    • Matrix Multiplication tools
    • Ability to draw a z-buffered textured triangle or quad
  • A better sound recording tool, and sound recording/playback options in general. Actually, does the switch even have a microphone?
  • A better map tool that lets you specify a map size. Preferably letting you add/delete columns at design time.
I would much prefer a version of SmileBasic for Switch, I hope we get it eventually. Here is today's code if anyone is interested:
REM MANDELBROT
DIM CLUT(256, 3)
MAX_ITERATIONS = 50.0
SHOW_MANDELBROT = True

A = 0
BI = 0

RAD
REM LEN(CLUT) - 1 not supported?
REM NO DYNAMIC RADIAN TO/FROM DEGREES EITHER?
FOR i = 0 TO 255 LOOP
 CLUT(i, 0) = 255 * ABS(SIN(FN RAD(1.75 * i)))
 CLUT(i, 1) = 255 * ABS(SIN(FN RAD(360 - i)))
 CLUT(i, 2) = 255 * ABS(SIN(FN RAD(i/2.2)))
REPEAT

SETMODE(640, 480)
CLS
PROC MANDELBROT
SHOW_MANDELBROT = False

PRINTAT(0, 0)
PRINT "TAP THE SCREEN FOR A MATCHING JULIA SET";
PRINTAT(0, THEIGHT - 1)
PRINT "PRESS [Q] TO EXIT";
UPDATE

WHILE (INKEY != ASC("Q") AND INKEY != ASC("q")) LOOP
	IF (MOUSEBUTTON & 1) != 0 THEN
		SWITCH(SHOW_MANDELBROT)
			CASE True
				PROC MANDELBROT
			ENDCASE
			CASE False
				A= FN MAP(MOUSEX, 0.0, GWIDTH - 1, -2.12, 1.06)
				BI= FN MAP(MOUSEY, 0.0, GHEIGHT - 1, -1.2, 1.2)
				PROC JULIA_SET(A, BI)				
			ENDCASE
		ENDSWITCH
		UPDATE
		
		SHOW_MANDELBROT = NOT SHOW_MANDELBROT
	ENDIF
 ENDIF
REPEAT
PRINTAT(0, 0)
PRINT "Bye"

END

DEF PROC JULIA_SET(A, BI)
	LOCAL I, J, I0, J0, X, Y, ITERATIONS, CLR
	RGBCOLOUR(0, 0, 0)
	RECT(0, 0, GWIDTH - 1, GHEIGHT - 1, True)
	
	FOR Y = 0.0 TO GHEIGHT - 1 LOOP
		FOR X = 0.0 TO GWIDTH - 1 LOOP
			I0 = FN MAP(X, 0.0, GWIDTH - 1, -2, 2)
			J0 = FN MAP(Y, 0.0, GHEIGHT - 1, 1.2, -1.2)
			I = I0
			J = J0
			
			FOR ITERATIONS = 0.0 TO MAX_ITERATIONS LOOP
				REM (A^2 - B^2) + 2ABi = (A + Bi) * (A + Bi)
				NEW_I = (I * I) - (J * J) + A
				NEW_J = (2.0 * I * J) + BI
				
				I = NEW_I
				J = NEW_J
				
				IF (((I * I) + (J * J)) >= 32.0) THEN
					BREAK
				ENDIF
			REPEAT
			
			IF ITERATIONS >= MAX_ITERATIONS THEN
				RGBCOLOUR(0, 0, 0)
			ELSE
				REM Why no LEN() function for Arrays.
				CLR = FN MAP(ITERATIONS, 0, MAX_ITERATIONS, 0.0, 255)
				RGBCOLOUR(CLUT(CLR, 0), CLUT(CLR, 1), CLUT(CLR, 2))
			ENDIF
			PLOT(X, Y)
		REPEAT
		UPDATE
	REPEAT
ENDPROC

DEF PROC MANDELBROT
	LOCAL I, J, I0, J0, X, Y, ITERATIONS, CLR
	
	RGBCOLOUR(0, 0, 0)
	RECT(0, 0, GWIDTH - 1, GHEIGHT - 1, True)
	
	FOR Y = 0 TO GHEIGHT - 1 LOOP
		FOR X = 0 TO GWIDTH - 1 LOOP
			I0 = FN MAP(X, 0.0, GWIDTH - 1, -2.12, 1.06)
			J0 = FN MAP(Y, 0.0, GHEIGHT - 1, 1.2, -1.2)
			I = 0
			J = 0
			FOR ITERATIONS = 0.0 TO MAX_ITERATIONS LOOP
				REM (A^2 - B^2) + 2ABi = (A + Bi) * (A + Bi)
				NEW_I = (I * I) - (J * J) + I0
				NEW_J = (2.0 * I * J) + J0	
				
				I = NEW_I
				J = NEW_J
				
				IF (((I * I) + (J * J)) >= 32.0) THEN
					BREAK
				ENDIF
			REPEAT
			
			IF ITERATIONS >= MAX_ITERATIONS THEN
				RGBCOLOUR(0, 0, 0)
			ELSE
				REM Why no LEN() for Arrays
				CLR = FN MAP(ITERATIONS, 0, MAX_ITERATIONS, 0.0, 255)
				RGBCOLOUR(CLUT(CLR, 0), CLUT(CLR, 1), CLUT(CLR, 2))
			ENDIF
			PLOT(X, Y)
		REPEAT
		UPDATE
	REPEAT
ENDPROC

DEF FN MAP(VALUE, MIN1, MAX1, MIN2, MAX2)
 LOCAL PERCENT
 
 PERCENT = ((VALUE - MIN1)/(MAX1 - MIN1)) + MIN1
 
= (PERCENT * (MAX2 - MIN2)) + MIN2

DEF FN RAD(ANGLE)
= (ANGLE * PI) / 180

Oooh already considering it did I hear that right?
Yeah. Nothing's been actually confirmed yet, but Takaki Kobayashi, SmileBoom's president, discussed it a bit on his Twitter account. The impression I have is that he would want to do it. However, the main problem discussed was backwards-compatibility with SmileBASIC and SmileBASIC BIG (the Japan-only Wii U version). For instance, the Switch only has one screen compared to the two screens of the 3DS and Wii U versions. In addition, there's the issue of typing when the Switch is docked, though he did notice that the Switch can use a USB keyboard. If SmileBoom decides to do it, it will probably still be a while before it happens. Right now Kobayashi seems focused on working on the current versions of SmileBASIC, and there is still a fair amount for them to do. He's writing a new, vastly improved Smile Tool to replace the original one, since it was made while the language was still in development, and thus is pretty minimal. He's also working on Petit Computer Magazine #2, assuming that's not come out yet in Japan. Furthermore, now that Miiverse is going down, he has to think of what they'll do there, since one of the things he liked about it was that it was a good place for kids to ask questions about BASIC that more experienced people could answer, and unlike similar communities, it was run by Nintendo so parents were more likely to accept it. Unlike Nintendo, SmileBoom doesn't necessarily have the resources to run a moderated community, especially in multiple regions that speak different languages, so it's not an ideal situation for them. Even after they decide to make it, and get it developed, there's also the concern of how long it will take to localize it, though this is not as big of a problem as on the 3DS and Wii U given that the Switch is region-free.

Ah so I see someone here watches The Coding Train as well! Coolio

So I downloaded FUZE BASIC and I made a static demo. On pc, atleast it outperforms SmileBasic by hurdles.
cls

Print "             Static Demo"
COLOUR=RND(30)

while true loop
for x=640+100 to 100  step -1 loop
for y=480+100 to 100 step -1 loop
COLOUR=RND(30)
plot(x, y)

repeat
repeat
update
repeat
This creates static noise, that updates. A few things to note here: DO NOT call update in Fuze Basic until you WANT to actually see what's been drawn. Reason? SLOW. try moving the update call to the inner loop of the for's , and you'll see what I mean. Bit annoying since it could have been optimized to also update just as fast.. but I suppose it has to keep swapping render buffers when it does that.. due to being double-buffered.

Darn, I can't quite tell is there a version for OSX yet?

I only see versions for Windows, and Raspberry Pi, sorry. Hopefully they will make it available on Mac.

Yeah, so I found this. https://www.youtube.com/watch?v=-1CZQOK4ihY&t=3s Made me think there was a way, guy responded almost immediately! Too bad, he has a dev version. Oh well, I need to dust off the old PC anyway soon.

I finally finished porting over my text adventure game "I LOST MY BALL" (BDWE58AV). It seems to work but I could have forgotten to put PROC or FN in front of some function calls. That was getting old really quick. For bad news, it looks like you can't call RESTORE and pass it a line number. It only starts READ/DATA over all the way. In fact I don't know if there are line labels at all in this thing. I also had to butcher the split function. It doesn't look like you can pass in an array or return one. Had to do things globally. I really wish arrays were handled better. On the plus side, while it is non-standard you can use // for comments instead of printing out REM. Strange, but welcome. I really expected that to be a lot easier than it was. I might experiment with Find The Exit (K2KYJCS) or Quad Connect (9K4NND46) next. Oh, and look at that font.... it is UGLY!

Fuze must have done a press release or something today (http://www.nintendolife.com/news/2018/01/learn_how_to_code_your_own_games_with_fuze4_nintendo_switch_later_this_year). It sounds like they are on track for a 2nd quarter 2018 release (I am guessing June/July). For a price they only said less than 30 pounds or about $40 in US dollars. Pretty steep for a downloadable title. I personally have a hard time paying over $10 for anything that doesn't come on disc or cartridge. Assuming I buy a Switch I will probably still get it, but I am the super fan type. It still may be too steep for people on the fence. Purchasing additional Game Packs sounds a bit problematic to me. Especially if they are anything like the ones Smile Basic had in Japan where you could only use them if you bought the DLC, but couldn't really share anything you made with them unless the target user also bought the DLC. If they do something similar you can't share your game with many people. If they don't it seems prone to piracy. Speaking of sharing, I really wish they detailed how sharing code would work more. It appears you can share with nintendo network friends, and there is something about hubs. Smells like an online site they control just like Smile Basic. I just hope we can save to and from the SD card. I really want to be able to put my code in source code control (SVN, GitHub, etc.). For the cool factor they pretty much say there will be 3D assets. Not sure how they will make that new programmer friendly. I should probably mention that I haven't experimented much with the PC version since my last post. I got Quad Connect partially working. It turns out that their sprites don't seem to have a concept of Z-Ordering. So if you think of something like Double Dragon, if Jimmy Lee is higher on the screen than Billy you want Jimmy to be further back in the z-order. If he later moves down the screen past Billy he should now be nearer in the z-order than Billy. Without that, you get one always drawn over the other which would look really bad when Jimmy is behind Billy but is legs cover up Billy's face. To get around this I basically dumped the sprites and did it all manually with in memory graphics. It works but is very disappointing to not use the sprite functionality. Anyway do you all think it is worth my time trying to port things to Fuze Basic before launch. I did have an idea of making either a YouTube series or a beginning game programming book featuring Fuze Basic, but I don't know if anyone really would want that content. I also don't know if I would be stuck typing in everything back in by hand when it came out. This is what Quad Connect on Fuze Basic looks like at the moment. It doesn't work yet. Had to redraw all of the stuff built in to SmileBasic.

NintendoLife is dumb so here are the materials https://www.fuzebasic.com/bin/LearntoCodeonNintendoSwitchPressReleaseJune2017.pdf
FUZE4 Nintendo Switch makes learning to coding more accessible than ever and what’s more, is children can learn while having fun.
great. The directory is indexed: https://www.fuzebasic.com/bin/ SwitchFUZE.wmv and avg.wmv can be found on their youtube channel: https://www.youtube.com/channel/UC2xD4m1Obefwy0c7IxNgyVQ I notice they don't make any claims about being as powerful as those other languages. From the recent press release:
So far, Pixel Art heroes Kenney, Eder Muniz, Ravenmore, DinV Studio and Untied Games have all agreed to allow us to include their content with FUZE4 Nintendo Switch.
The bundled assets are currently valued at over $150 and this will only rise as more artists submit their work. With FUZE4 Nintendo Switch retailing at less than £30 [$40, as noted], this represents incredible value for money.
SmileBASIC BIG was ~$30 before the price drop (now 15). Mmmmm. There's this weird "Back at FUZE HQ" joke section at the end that I guess is supposed to be funny but...
Luke on the other hand, in his Marvin like monochromatic tone pronounced “Jonnyboy is right once in a hundred times. The only excitement I get is watching him suffer my awesome skillz – poor lad, doesn’t stand a chance, now hmmm... another biscuit or a sip of soda, you know what, I’ll have the cake… this is the life.”

I was going to post some code for a fractal snowflake and carpet in FuzeBasic, but found this this morning. http://www.nintendolife.com/news/2018/02/code_your_own_games_on_switch_with_the_return_of_petit_computer I am happy it is coming, although I will probably buy both Fuze and Smile Basic. Which do you think will be better? SmileBasic Switch better have USB keyboard support. Also we can laugh at NintendoLife for calling them SlimeBoom.