Concept: Open-Source SmileBASIC

If we could add new functions to SmileBASIC, I'd try to do it in a way that's as close to SmileBASIC as possible. For example: A 3D library which can alter the display of existing layers and also draw automatically z-sorted polygons. It would have a system like sprites, only using 3D models as the graphics data, rather than a large spritesheet. For example:

PINIT 1,1,16 'Set up screen, sets 1 unit = 16px, sets perspective(1)/orthographic(0) flag, sets a flag that determines if z-coordinates of sprites and backgrounds should take on the properties of this setup. (0 = no effect on BG/SP, 1 = affect BG, 2 = affect SP, 3 = affect both, 4 = I have no idea this is all just an idea)
VAR points%[32, 3] 'Make the array that we store our model in.
COPY points%, @MODEL_1 'Copy the data in from a model conveniently outside this code preview
PSET 0,points% 'Make a model with the ID of 0, and using the model data we copied in
POFS 0,-26,0,1 'Just off to the left of the screen, and just into the screen enough to be properly seen by the camera.
PANIM 0,"XYZ",-60,26,0,1,0 'Zoom to the right of the screen over 60 frames. Loop this.
'And there you go, a teapot moving at the speed of light!

With that prefix for "Polygon", just like "BackGround", "SPrite", "Graphics", and "Text screen"

That sounds really cool. You can probably make commands like this using DEF, like make a 3d library. Some examples of 3d engines are P3D and Sim.3D.

Bad news, if we go through with this, we can't release the code. I guess we can still develop it, but we can't release it, or we'll have to make our own original assets (and I guess make an alternative version with the original SmileBASIC assets, but not release that one). I spoke with the SmileBoom CEO (@notohoho), and he said that it was okay for personal research, but not if we release it with any assets.

Bad news, if we go through with this, we can't release the code. I guess we can still develop it, but we can't release it, or we'll have to make our own original assets (and I guess make an alternative version with the original SmileBASIC assets, but not release that one). I spoke with the SmileBoom CEO (@notohoho), and he said that it was okay for personal research, but not if we release it with any assets.

Ok, that's nice. I would help, if I knew any language that isn't SB. Maybe it's time for me to try out a new language.

Bad news, if we go through with this, we can't release the code. I guess we can still develop it, but we can't release it, or we'll have to make our own original assets (and I guess make an alternative version with the original SmileBASIC assets, but not release that one). I spoke with the SmileBoom CEO (@notohoho), and he said that it was okay for personal research, but not if we release it with any assets.

Ok, that's nice. I would help, if I knew any language that isn't SB. Maybe it's time for me to try out a new language.

Same lol I've used SB so much I've really gotten used to it I guess we could still develop the interpreter with full SmileBASIC support as long as we don't mention SmileBASIC anywhere in the program. So, first things first, nix the replica-of-the-UI idea. That will cause legal issues right off the bat. I guess the interpreter will load right to the console, with a small, original UI that can be used to save/load programs with ease. Second, no key support. SmileBASIC programs can be imported to the "virtual file system" through the SBAPI website. I guess our recreation of SB should also support metadata, so it's easier to import programs. SBAPI could still be used when the program is first launched to download all of the assets and samples. I'll host a project with these things (fun fact: I've been saving several archives of the files that come with SmileBASIC 3/4, such as the samples). By the way, the fact that the SB4 keyboard pulls it assets from a GRP means that we can include the it with its original assets. But now that I think about it, could SBAPI cause any legal issues? It pulls data from SmileBoom's servers without the SmileBASIC application, so anyone could use it without paying for it. And would it be okay to import assets this way? Anyways, the last thing I want to mention is the name. Obviously we can't get away with naming it "SmileBASIC Interpreter" or something similar, so I was thinking something along the lines of SourceBASIC. P.S. I know SBAPI currently only supports SB3 programs, but I believe SB4 support is in the works. I would try to tackle SB3 BIG instead, but I don't have that for reference, so I could never guarantee 100% compatibility, which is what I'm aiming for. Plus, SB3 has two-screen support, while SB4 only has one, making it more compatible with other devices.

so when do we see a working interpreter and not how many features can we fit into an incomplete project?

so when do we see a working interpreter and not how many features can we fit into an incomplete project?

lol I think we're in the planning phase.

This isn't planning.

this forum somehow lacks experienced programmers with free time to do this (no offence) so I think this will be in "planning phase" forever lol

and what XOX refers to (I think) is that the people willing to contribute should focus on (trying) to implement basic functionality of the program instead of just giving ideas. i think

This isn't planning.

I guess that's true, but we are trying to clear things out I guess. Idk

and what XOX refers to (I think) is that the people willing to contribute should focus on (trying) to implement basic functionality of the program instead of just giving ideas. i think

bingo

This isn't planning.

I guess that's true, but we are trying to clear things out I guess. Idk

Pretty much. This "project" hasn't even started yet, right now this is just a concept. And yes, this isn't even planning, either. If we were planning, we would be thinking about how the interpreter would work, such as how the interpreter would parse code.

so when do we see a working interpreter and not how many features can we fit into an incomplete project?

This project isn't even incomplete lmao, nothing's been done yet other than me stressing over the possible legal issues that I have to be sure to avoid (no mentions of SmileBASIC anywhere except in the project description, where I'll have to explain the SmileBASIC is a property of SmileBoom and not affiliated with us at all) Yeah you can tell I'm stressed

and what XOX refers to (I think) is that the people willing to contribute should focus on (trying) to implement basic functionality of the program instead of just giving ideas. i think

bingo

Bingo indeed. So before anything is really worked on, who would like to contribute to this? Don't really know who wants to right now. If I can get a team for this, we could probably start working on a PoC, and then (if it works well) go on to expanding its code. I feel like the PoC should really be nothing more than getting most text/math functions, and most necessary sprites/graphics functions to work. Hell, it doesn't even need to have the saving/loading UI I mentioned before or an on-screen keyboard, since the PoC should be Windows-only anyway. In case anyone was wondering why I was mentioning Wii homebrew before, it was because SmileBASIC has a history of being on Nintendo hardware, so I thought it would be a good stretch goal for this project if we actually got a PoC working, just for fun. P.S. Sorry for spamming everyone with edits, I was just adding more responses to my post and fixing typos.

Well. Since @notohoho has gave us the theoretical "thumbs-up" for the project.

Eh, it's more like a sideways thumb. He was originally skeptical of the whole "recreation of SB4" thing, and that's when he gave me all the legal stuff. I think he was even annoyed by it, because he mentioned that if this project was actually finished (in its original state), we would technically be giving SB away for free, rendering their work useless. He said just an interpreter (the whole SourceBASIC idea) would be fine though.

smilebasic interpreter in brainfuck: 1437825639839456740184 characters (boy i need to publish my bf2sb compiler)

Well I probably won't help Sorry

Well I probably won't help Sorry

It's fine, even if you just have ideas, you can still help.

Well I probably won't help Yikes

I'd help, seeing as it's kind of similar to what I'm trying to do writing a PTC mk2 interpreter, but until there's a more concrete plan I'm not sure I could really do anything.

I've grown to love SmileBASIC4 over the past 13 weeks of using it. But... *tries not to look too much like a spambot* If you want something that might come close to SmileBASIC, maybe have a look at AMOS2. AMOS was a BASIC language from the Amiga days, and the author (the original AMOS creator, Francois Lionet) has recently started to port the entire thing over to Javascript. I'm not sure if any of you are old enough to remember AMOS, let alone the Amiga computers, but if you do know what it is, you'll probably get why it's as important as it is. Linkage The author is still at the early stages, but his intention is to create a 100% compatible version, (as in, you could literally copy+paste entire Amiga AMOS game code, and it'd work) and then expand from there. As for cloning SmileBASIC.. As much as I'd like to see it, I'd rather it be attempted by SmileBoom and done "properly" than have the wrath of their CEO come down on anything and everything you might've then created using it. IMO it's better to go your own way, and make a "BASIC Clone" that doesn't land you in hot water. A little ingenuity and a little imagination can create a wonderful new thing. Don't clone. Create.