LoginLogin
Nintendo shutting down 3DS + Wii U online services, see our post

SB3/SB4 Cross-compatible code

Root / Programming Questions / [.]

AveryCreated:
Programs uploaded the SB servers via SmileBASIC 3 are downloadable by both SB3 and SB4. This means it's currently possible to host programs which can be downloaded, and if doen correctly, RUN on both as well. There are two ways to go about this. 1: Carefully write the code to use only common command and function syntax, so that the resulting execution is the same on SB3 and SB4 2: Perform a check so the program can determine which version of SmileBASIC it is running on, and have it branch its code accordingly. The best check I am aware of.
IF #CHKS AND 32 THEN EXEC "PRG:MAIN.SB3" ' Start SB3 code
IF #CHKS AND 8 THEN EXEC "PRG:MAIN.SB4" ' Start SB4 Code

Since we have a convention established to use MAIN.PRG as the common entry point for every project, using that as a little bootstrapper is probably a smart idea. Since it's separate from your real code it doesn't really matter what it detects and if it uses OPTION STRICT or not. If you want to save on rewriting your code, you could try and put in the effort to separate your program into "main code" and "platform code" in separate files. Main code would work everywhere and call to COMMON DEFs in the platform code loaded by the bootstrapper to fill in the gaps.

Constants: - #CHKUV, #CHKI, #CHKR, #CHKS, #CHKC, #CHKV have different values in SB3/SB4 - 65536*65536: 4294967296 in SB3 and 0 in SB4 (works with any integer operators when used on constants: in SB3 the value is converted to a float if it overflows, while in SB4 it isn't) Other fun things: - VAL("&H1_1") (underscore in hex/bin literals only works in SB4)

Here's the real pain point though: SB3 keys work on SB4, but SB4 keys don't work on SB3. Plus SB3 projects don't show in the SB4 download gallery, so you're hurting the discoverability of your program. It's in your best interest to host two versions of the same project anyway. Of course, if you follow the design patterns listed above and make the SB3 version first, making the SB4 version gets a whole lot easier. Plus in the case of maintaining two versions you don't really need a bootstrapper, unless you want to load different platform code in the SB3 version or warn people who downloaded it on SB4 that they got the wrong one. You're just shooting yourself in the foot using only a SB3 key, but starting there makes life pretty easy.

and the SB3 upload limit is much smaller, especially since you can't use compressed files without hacking

Plus, that would require you do all of your editing on SB3 and you're beholden to 512x512 GRP sizes. Imagine having to constantly redownload your project on a different system just to test it.

I wasn't aware of the discoverability issues involved. Also, I thought I would be able to upload from SB4 without a server ticket, but I think I've heard you get one ticket included free. How many uploads does that allow?

I wasn't aware of the discoverability issues involved. Also, I thought I would be able to upload from SB4 without a server ticket, but I think I've heard you get one ticket included free. How many uploads does that allow?
10, but you're rate limited to every 8 hours IIRC.

I know you're rate-limited to once every 8 hours for downloading without a ticket. I haven't heard anything like that about uploading with a ticket, though.

I know you're rate-limited to once every 8 hours for downloading without a ticket. I haven't heard anything like that about uploading with a ticket, though.
That's probably what I'm thinking of, then.