LoginLogin

Submit Example SB4 Programs / My Direction for an Interpreter

Root / General / [.]

ChatterCreated:
I've decided once again to attempt a SmileBASIC 4 interpreter in Lua. The design I've settled on is:
  • Written in Lua, using LuaJIT.
  • Lexing and parsing using LPeg.
  • Input/output using SDL2.
So, the first step will be writing a lexer and parser using LPeg. SmileBASIC's grammar isn't published, so I plan to do this by looking at other BASIC grammars as well as SB4 programs until the parser can correctly parse SmileBASIC 4 programs. Since SBAPI is down, I would appreciate if anyone could submit SmileBASIC 4 programs. Ideally, they would be representative of a real, actually useful SmileBASIC 4 program, and would not use self-modifying code (not important at this stage, but I plan to use these same programs later to test the full interpreter).

Since SBAPI is down, I would appreciate if anyone could submit SmileBASIC 4 programs.
Bröther, we’ve been trying to get people to submit SB4 programs for years now
Ideally, they would be representative of a real, actually useful SmileBASIC 4 program
What do you mean “actually useful SmileBASIC 4 programs?”

Good luck! You might be able to use SB3 programs to start. The languages should be pretty similar, even if some commands changed.

Since SBAPI is down, I would appreciate if anyone could submit SmileBASIC 4 programs.
Bröther, we’ve been trying to get people to submit SB4 programs for years now
Ideally, they would be representative of a real, actually useful SmileBASIC 4 program
What do you mean “actually useful SmileBASIC 4 programs?”
A program that uses enough features of the language such that the ability to run it would indicate a reasonable likelihood of success with running any given program.

Is it really a good idea to clone a piece of proprietary software that is still for commercial sale?

Could you please elaborate on that?

SmileBoom may not like you making a replica of SmileBASIC 4, as you may take away sales, when your interpreter can do anything that the official interpreter can. SmileBASIC 3 would be a better target, since the eShop is soon closing and is generally considered dead as of 2022 but SmileBASIC 4 might be too far fetched for now.

Back in the day Lotus vs. Borland found that menu tree layout was not copyrightable (Borland's Quattro Pro included a menu mode that mimicked the layout of Lotus 1-2-3) https://www.casebriefs.com/blog/law/intellectual-property-law/intellectual-property-keyed-to-merges/copyright-law/lotus-development-corp-v-borland-international/. Recently Oracle vs. Google https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.#Decision found that Google's use of the Java API in android was fair use. BASIC was created back in 1964, and there are dozens of implementations. QB64 https://qb64.com/ is based on Microsoft's QBasic\Quick Basic specifically without any legal troubles that I am aware of. So making a BASIC interpreter with SmileBasic compatability is probably not going to be a problem even if it is significantly similar to another version. After all is having a command with the same interface really all that different than menu layout or an API entry. However, I am not a lawyer, you could still get a cease and desist just because they feel like it, and I would highly recommend making it quite a bit different if only to make use of the abilities of the new platform (I would say make it as different as SmileBasic and Fuze4 are from one another). One thing that would definitely get you into trouble is if you use the same name, documentation, background images, sprites, sound effects, or music tracks. There shouldn't be any exact copies of SmileBoom's sample code or code in general either. Don't use the SmileBasic or SmileBoom names at all in your program. As for the code request, I have one SmileBasic for Switch program at the following link. Had to type it back in by hand, so beware of type-o/bugs. https://github.com/seggiepants/rosetta/blob/master/SmileBasic/mugwump_2d/Switch/mugwump_2d.prg Overall, it may be easier to port code you are interested to Lua/Love than to make a SmileBasic interpreter. Speaking of Lua, is anyone watching the Lazy Devs Shmup series, I am enjoying it so far. I am porting it to Love just for fun.

It is worth pointing out that Nintendo might be a point of legal concern here, even if all of the legal precedent established above is true. It is especially true that you can do what you want with the language specification. SmileBoom has even supposedly said as much in a tweet or email I can't source currently. So long as you are careful to avoid damaging their copyright you may not enter any legal trouble. But to what degree are you cloning SB4? All of the graphics, audio, and control features are exactly the same? Is the goal to allow people to play existing games on PC, or create games on PC? Not only does Nintendo's way of handling controllers not translate well to a PC, but allowing existing games to be played requires the copyrighted assets to begin with. Would it even make sense? And this last point is entirely my own opinion on ethics and not everyone will agree, but SB3 is abandonware and SB4 isn't. SB4 is still a legitimate part of SmileBoom's business. Is it really right for someone to copy their software feature-for-feature for free? Keep in mind, this is creative software, not utility software. They also sell the core SBScript engine to enterprise customers too. Isn't it more important to try and recreate SB3, which will quickly become abandonware? Do they want to make a PC version in the future? I have a great deal of respect for SmileBoom and the way they conduct their business, and I know you're not a threat, but they're extremely small and have a vanishingly niche customer base. If you intend on doing something like this, it's probably better if you do something similar, but you do it your own way. Creating your own thing is always more fulfilling and it gives you more control over what YOU want. Even if it's basically just SmileBASIC but slightly different, that's still maybe better. Or you can work on cloning and preserving SB3, so it doesn't disappear forever. TLDR: even if you can get away with it, is this the right idea? Is now the right time?

I will try to address the points approximately in the order they were raised. Addressing CyberYoshi64's claim that I might take away sales, I don't see that being an issue, for two reasons. Firstly, as snail_ addressed, SmileBASIC is creative software; it includes many utilities besides the language interpreter, including a code editor, graphics editor, and function documentation, none of which I plan to provide. Heck, even error messages didn't make the list. So, to address snail_'s question, the goal is to allow people to play existing games on PC, not author new programs. Secondly, and somewhat related to the first point, the target demographics aren't really the same. SmileBoom and FUZE's bread and butter seem to be the education market. Their Nintendo Switch platforms appeal because they're batteries-included, idiot-proof (slash off-topic-student-proof), and on a game console (which makes it fun for the kids). Once you transition to PC, you have to keep kids from exiting out the window accidentally, keep them from opening up other off-topic windows, deal with operating system problems, etc. If you're willing to handle all that, there are thousands of other options, and I don't think SmileBoom has the secret sauce necessary to succeed (not that SmileBoom is a bad company or anything; if you look at FUZE's Twitter page, it's mostly Nintendo Switches even though they offer FUZE for PC). The point is, I think my interpreter neither invades SmileBoom's current niche nor fills a potential future niche. Regarding seggiepants's comment, I'm not in a position to have an informed opinion regarding the legality of an interpreter. As for your question, I'm not following the Lazy Devs Shmup series; I despise LÖVE and PICO-8, so I don't pay attention to anything that uses them. Regarding assets, the plan is to expect texture sheets and sounds files with certain names, meaning you could rip SmileBASIC 4's and use them for full compatibility, or use your own. I don't find any joy in creating a modified clone of SmileBASIC. It's just not interesting. If my goal is to implement a compatible-as-can-be (given different hardware) version of the SB4 interpreter, that's a challenge to work towards, and there's satisfaction when it's achieved. Once I'm done, I'll be left with a SB4 interpreter as a bonus. If I were to create my own incompatible version, I'm just left with an implementation of a bad programming language with no cool software library. That being said, and as I kind of touched on in the previous paragraph, this project is more about the journey than the destination. If I were to create a SB3 interpreter, I think that could be equally cool. It seems you guys would be more okay with that?

You know, copyright lasts an outrageous length of time. About 80 years after the authors death if I can remember correctly. The Micky Mouse cartoon "Steamboat Willy" was made around the 1920's and still isn't in the public domain. So, as far as copyright is concerned, Petit Computer, Smile Basic 3DS, and Smile Basic Switch are all under full copyright protection and will still be long after I am dead. It doesn't matter if you can buy it or if it has been abandoned. So I don't think it matters which version you base your code around. Although it is mean to make a work alike of something that is currently being sold. Attack dog lawyers searching for IP infringing content can also send you a cease and desist even if what you are doing is perfectly legal. This is another reason to make your code different and distinct. No reason you couldn't have a superset of SmileBasic. Maybe throw in classes or 3D support. QBasic could still run GW Basic programs, for example. I don't think you will have a large library of code to run either way, most of it is probably locked on a 3DS/Switch or SmileBoom's servers. I thought you were making your interpreter in Lua, so I suggested Love (Pico-8 uses Lua too). If you don't like them that's ok (although I am curious of why you despise them as opposed to simply disliking them). Here is a 3DS SmileBasic sample program, just text mode stuff to try parsing
OPTION STRICT

VAR SCREEN_W = 400
VAR SCREEN_H = 240
VAR FONT_PX = 8
VAR CON_W = SCREEN_W / FONT_PX
VAR CON_H = SCREEN_H / FONT_PX
VAR IDX_X = 0
VAR IDX_Y = 1
VAR IDX_FOUND = 2
VAR NUM_MUGWUMPS = 4
VAR GRID_W = 10
VAR GRID_H = GRID_W
VAR DISTANCE, TURN, I, X, Y
VAR REMAINING, PLAY_AGAIN$

CENTER_PRINT "MUGWUMP"
CENTER_PRINT "CREATIVE COMPUTING  MORRISTOWN, NEW JERSEY"
PRINT
PRINT
PRINT
'COURTESY PEOPLE'S COMPUTER COMPANY

DIM POS[NUM_MUGWUMPS, IDX_FOUND + 1]
PRINT_INTRODUCTION

WHILE TRUE
 INIT_MUGWUMPS
 TURN = 0
 
 WHILE TRUE
  TURN = TURN + 1
  PRINT
  PRINT
  REPEAT
   INPUT "TURN NO. " + STR$(TURN) + " WHAT IS YOUR GUESS? "; X, Y
  UNTIL X >= 0 AND X < GRID_W AND Y >= 0 AND Y < GRID_H
  FOR I = 0 TO  NUM_MUGWUMPS - 1
   IF POS[I, IDX_FOUND] == 0 THEN
    IF POS[I, IDX_X] != X OR POS[I, IDX_Y] != Y THEN
     DISTANCE = SQR(POW(X - POS[I, IDX_X], 2) + POW(Y - POS[I, IDX_Y], 2))
     PRINT "YOU ARE "; FLOOR(DISTANCE * 10) / 10; " UNITS FROM MUGWUMP "; I + 1
    ELSE
     POS[I, IDX_FOUND] = 1
     PRINT "YOU HAVE FOUND MUGWUMP "; I
    ENDIF
   ENDIF
  NEXT I
  
  REMAINING = 0
  FOR I = 0 TO NUM_MUGWUMPS - 1
   IF POS[I, IDX_FOUND] == 0 THEN
    REMAINING = REMAINING + 1
   ENDIF
  NEXT I
  
  IF REMAINING == 0 THEN
   PRINT
   PRINT "YOU GOT THEM ALL IN ";TURN; " TURNS!"
   BREAK
  ELSEIF TURN >= 10 THEN
   PRETTY_PRINT "SORRY, THAT'S 10 TRIES, HERE IS WHERE THEY'RE HIDING"
   PRINT
   FOR I = 0 TO NUM_MUGWUMPS - 1
    IF POS[I, IDX_FOUND] == 0 THEN
     PRINT "MUGWUMP "; I; " IS AT ("; POS[I, IDX_X]; ", "; POS[I, IDX_Y]; ")"
    ENDIF
   NEXT I
   BREAK
  ENDIF
 WEND
 
 PRINT
 PRINT "THAT WAS FUN!"
 REPEAT
  INPUT "WOULD YOU LIKE TO PLAY AGAIN? (Y/N) ";PLAY_AGAIN$
  PLAY_AGAIN$ = LEFT$(UCASE$(TRIM$(PLAY_AGAIN$)), 1)
 UNTIL PLAY_AGAIN$ == "Y" OR PLAY_AGAIN$ == "N"
 
 IF PLAY_AGAIN$ == "N" THEN
  BREAK
 ENDIF
 
 PRINT "FOUR MORE MUGWUMPS ARE NOW IN HIDING."
WEND

END

DEF CENTER_PRINT MESSAGE$
 VAR X = MAX(0, (CON_W - LEN(MESSAGE$))/2)
 LOCATE X, CSRY
 PRINT MESSAGE$
END

DEF INIT_MUGWUMPS
 FOR I = 0 TO NUM_MUGWUMPS - 1
   POS[I, IDX_X] = RND(GRID_W)
   POS[I, IDX_Y] = RND(GRID_H)
   POS[I, IDX_FOUND] = 0
 NEXT I
END

DEF PRETTY_PRINT MESSAGE$
 VAR I, WORDS$[0], DELIM$ = " "
 WORDS$ = SPLIT(MESSAGE$, " ")
 FOR I = 0 TO LEN(WORDS$) - 1
  IF CSRX > 0 AND CSRX < CON_W - 1  THEN
   PRINT DELIM$;
  ENDIF
  IF CSRX + LEN(WORDS$[I]) >= CON_W THEN
   PRINT ""
  ENDIF
  PRINT WORDS$[I];
 NEXT I
END

DEF PRINT_INTRODUCTION
 PRETTY_PRINT "THE OBJECT OF THIS GAME IS TO FIND FOUR MUGWUMPS" 
 PRETTY_PRINT "HIDDEN ON A 10 BY 10 GRID. HOMEBASE IS POSITION 0,0" 
 PRETTY_PRINT "ANY GUESS YOU MAKE MUST BE TWO NUMBERS WITH EACH"
 PRETTY_PRINT "NUMBER BETWEEN 0 AND 9 INCLUSIVE. FIRST NUMBER"
 PRETTY_PRINT "IS DISTANCE TO RIGHT OF HOMEBASE AND SECOND NUMBER"
 PRETTY_PRINT "IS DISTANCE ABOVE HOMEBASE."
 PRINT
 PRINT
 PRETTY_PRINT "YOU GET 10 TRIES. AFTER EACH TRY, I WILL TELL"
 PRETTY_PRINT "YOU HOW FAR YOU ARE FROM EACH MUGWUMP"
 PRINT
 PRINT
END

'SPLIT A GIVEN STING DELIMITED BY DELIMITER
'RETURNS A STRING ARRAY
DEF SPLIT(MESSAGE$, DELIM$)
 VAR RET$[0], CH$, WORD$, I
 FOR I = 0 TO LEN(MESSAGE$) - 1
  CH$ = MID$(MESSAGE$, I, 1)
  IF CH$ == DELIM$ THEN
   IF LEN(WORD$) > 0 THEN
    PUSH RET$, WORD$
    WORD$ = ""
   ENDIF
  ELSE
   WORD$ = WORD$ + CH$
  ENDIF
 NEXT I%
 
 IF LEN(WORD$) > 0 THEN PUSH RET$, WORD$
 
 RETURN RET$
END


'RETURN THE GIVEN STRING EXCEPT WITH 
'WHITE SPACE CHARACTERS REMOVED FROM THE 
'STRINGS BEGINNING AND END.
DEF TRIM$(MESSAGE$)
 DIM I, J, CH$
 IF LEN(MESSAGE$) > 0 THEN
  I = 0
  J = LEN(MESSAGE$) - 1
  CH$ = MID$(MESSAGE$, I, 1)
  WHILE CH$ == " " OR CH$ == CHR$(9) OR CH$ == CHR$(10) OR CH$ == CHR$(13)
   I = I + 1
   IF I >= J THEN BREAK
   CH$ = MID$(MESSAGE$, I, 1)
  WEND
  
  CH$ = MID$(MESSAGE$, J, 1)
  WHILE CH$ == " " OR CH$ == CHR$(9) OR CH$ == CHR$(10) OR CH$ == CHR$(13)
   J = J - 1
   IF J <= I THEN BREAK
   CH$ = MID$(MESSAGE$, J, 1)
  WEND
 
  RETURN MID$(MESSAGE$, I, J - I + 1)
 ELSE
  RETURN ""
 ENDIF
END

'RETURN GIVEN STRING IN ALL UPPER CASE
DEF UCASE$(MESSAGE$)
 VAR I, CH$, RET$
 
 FOR I = 0 TO LEN(MESSAGE$) - 1
  CH$ = MID$(MESSAGE$, I, 1)
  IF ASC(CH$) >= ASC("a") AND ASC(CH$) <= ASC("z") THEN
    RET$ = RET$ + CHR$(ASC("A") - ASC("a") + ASC(CH$))
  ELSE
   RET$ = RET$ + CH$
  ENDIF
 NEXT I
 
 RETURN RET$
END