SmileBASIC 4 Discussion「プチコン4」
Really, the roughest part of buttons in SB4 are the new constant names, I think. #B_RRIGHT is just way clunkier than #A, for example. However, nothing's stopping you from defining your own constants in SB4, thanks to the new CONST keyword, so let's look at a comparison of BUTTON in SB3 and SB4, assuming you've made constants in SB4 defined as CONST #A=#B_RRIGHT, etc.
'First line is SB3, second is SB4 'Check if X is being held BUTTON() AND #X BUTTON(0,#X) 'Check if A was pressed this frame BUTTON(2) AND #A BUTTON(0,#A,2) 'Check if L and R are both being held (BUTTON() AND #L) && (BUTTON() AND #R) BUTTON(0,#L) && BUTTON(0,#R) 'Check if B isn't being held this frame !(BUTTON() AND #B) !BUTTON(0,#B)The SB4 version of BUTTON doesn't seem too bad to me. In fact, I'd say it's easier to understand! It's just unfortunate how verbose the button constants are now, if you stick with the default names of #B_LLEFT and #B_RDOWN and so on.
Really, the roughest part of buttons in SB4 are the new constant names, I think. #B_RRIGHT is just way clunkier than #A, for example. However, nothing's stopping you from defining your own constants in SB4, thanks to the new CONST keyword, so let's look at a comparison of BUTTON in SB3 and SB4, assuming you've made constants in SB4 defined as CONST #A=#B_RRIGHT, etc.Button constants aren't super hard to understand. #B is button, R/L is whick side of the controller, UP/DOWN/LEFT/RIGHT is which button to press on that side. You just need to know the system. EDIT: notifications just went literally from 44 to 1'First line is SB3, second is SB4 'Check if X is being held BUTTON() AND #X BUTTON(0,#X) 'Check if A was pressed this frame BUTTON(2) AND #A BUTTON(0,#A,2) 'Check if L and R are both being held (BUTTON() AND #L) && (BUTTON() AND #R) BUTTON(0,#L) && BUTTON(0,#R) 'Check if B isn't being held this frame !(BUTTON() AND #B) !BUTTON(0,#B)The SB4 version of BUTTON doesn't seem too bad to me. In fact, I'd say it's easier to understand! It's just unfortunate how verbose the button constants are now, if you stick with the default names of #B_LLEFT and #B_RDOWN and so on.
Button constants aren't super hard to understand.I mean "easier" in the sense that you don't have to deal with bitwise operations like AND, nor do you risk screwing up by using == instead. SB4 button constants aren't hard to understand, but they're more awkward to type, and though I assume #B_RLEFT, etc. were chosen because of sideways Joy-Cons not having ABXY button labels, I feel like that change was a bit unnecessary.
I see. Actually, after researching more about the button command, it seems easier than the original to me too.Button constants aren't super hard to understand.I mean "easier" in the sense that you don't have to deal with bitwise operations like AND, nor do you risk screwing up by using == instead. SB4 button constants aren't hard to understand, but they're more awkward to type, and though I assume #B_RLEFT, etc. were chosen because of sideways Joy-Cons not having ABXY button labels, I feel like that change was a bit unnecessary.
How do I change the name for the owner of a project? I’m trying to port a project over but I want to put my name for the author to match my Nintendo Account’s. P.S. I’m still giving credit to the original author by putting their username in the description.I don't think that's a good idea. They're the creator of the project, and your work would be secondary to that, I feel. I would recommend leaving them as the author, and putting your name in the description, as well as clearly explaining that it's an unofficial port.
Okay, I’ll do that.How do I change the name for the owner of a project? I’m trying to port a project over but I want to put my name for the author to match my Nintendo Account’s. P.S. I’m still giving credit to the original author by putting their username in the description.I don't think that's a good idea. They're the creator of the project, and your work would be secondary to that, I feel. I would recommend leaving them as the author, and putting your name in the description, as well as clearly explaining that it's an unofficial port.
Is there a command that converts SB3 text color values to RGB in SmileBASIC 4? Just wondering in case I have to code one myself.You could just use a lookup table.
0: &h00000000 '(transparent) 1: &hFF000000 2: &hFF840000 3: &hFFFF0000 4: &hFF008400 5: &hFF00FF00 6: &hFF848400 7: &hFFFFFF00 8: &hFF000084 9: &hFF0000FF 10: &hFF840084 11: &hFFFF00FF 12: &hFF008484 13: &hFF00FFFF 14: &hFF848484 15: &hFFFFFFFF
You can quite literally do this in SB4 with array initializers:Is there a command that converts SB3 text color values to RGB in SmileBASIC 4? Just wondering in case I have to code one myself.You could just use a lookup table.0: &h00000000 '(transparent) 1: &hFF000000 2: &hFF840000 3: &hFFFF0000 4: &hFF008400 5: &hFF00FF00 6: &hFF848400 7: &hFFFFFF00 8: &hFF000084 9: &hFF0000FF 10: &hFF840084 11: &hFFFF00FF 12: &hFF008484 13: &hFF00FFFF 14: &hFF848484 15: &hFFFFFFFF
DIM TCOLOR%[] = [ \ &h00000000, \ &hFF000000, \ &hFF840000, \ &hFFFF0000, \ &hFF008400, \ &hFF00FF00, \ &hFF848400, \ &hFFFFFF00, \ &hFF000084, \ &hFF0000FF, \ &hFF840084, \ &hFFFF00FF, \ &hFF008484, \ &hFF00FFFF, \ &hFF848484, \ &hFFFFFFFF \ ]Though if you were smart and used the named constants in SB3 it's as easy as changing the constant names in your ported code.
COLOR #TRED 'old COLOR #C_RED 'new
Really, the roughest part of buttons in SB4 are the new constant names, I think. #B_RRIGHT is just way clunkier than #A, for example. However, nothing's stopping you from defining your own constants in SB4, thanks to the new CONST keyword, so let's look at a comparison of BUTTON in SB3 and SB4, assuming you've made constants in SB4 defined as CONST #A=#B_RRIGHT, etc.So, it seems that Smireboom got the Ls & Rs Light. This will be fun.'First line is SB3, second is SB4 'Check if X is being held BUTTON() AND #X BUTTON(0,#X) 'Check if A was pressed this frame BUTTON(2) AND #A BUTTON(0,#A,2) 'Check if L and R are both being held (BUTTON() AND #L) && (BUTTON() AND #R) BUTTON(0,#L) && BUTTON(0,#R) 'Check if B isn't being held this frame !(BUTTON() AND #B) !BUTTON(0,#B)The SB4 version of BUTTON doesn't seem too bad to me. In fact, I'd say it's easier to understand! It's just unfortunate how verbose the button constants are now, if you stick with the default names of #B_LLEFT and #B_RDOWN and so on.
Well, the buttons are literally named and labeled L and R in multiple places, it's not like they've never seen the English alphabet.Really, the roughest part of buttons in SB4 are the new constant names, I think. #B_RRIGHT is just way clunkier than #A, for example. However, nothing's stopping you from defining your own constants in SB4, thanks to the new CONST keyword, so let's look at a comparison of BUTTON in SB3 and SB4, assuming you've made constants in SB4 defined as CONST #A=#B_RRIGHT, etc.So, it seems that Smireboom got the Ls & Rs Light. This will be fun.'First line is SB3, second is SB4 'Check if X is being held BUTTON() AND #X BUTTON(0,#X) 'Check if A was pressed this frame BUTTON(2) AND #A BUTTON(0,#A,2) 'Check if L and R are both being held (BUTTON() AND #L) && (BUTTON() AND #R) BUTTON(0,#L) && BUTTON(0,#R) 'Check if B isn't being held this frame !(BUTTON() AND #B) !BUTTON(0,#B)The SB4 version of BUTTON doesn't seem too bad to me. In fact, I'd say it's easier to understand! It's just unfortunate how verbose the button constants are now, if you stick with the default names of #B_LLEFT and #B_RDOWN and so on.
That's tolu.
I know how to use the constants, and I honestly prefer them. But there’s a line of code in Dot Racer that uses hex codes that translate to a text color code, and it would be a pain to change this and have the program change colors manually. I already made a command that converts these numbers to their RGB equivalents, so I don’t need any help with this anymore. Thanks for the advice though.You can quite literally do this in SB4 with array initializers:Is there a command that converts SB3 text color values to RGB in SmileBASIC 4? Just wondering in case I have to code one myself.You could just use a lookup table.0: &h00000000 '(transparent) 1: &hFF000000 2: &hFF840000 3: &hFFFF0000 4: &hFF008400 5: &hFF00FF00 6: &hFF848400 7: &hFFFFFF00 8: &hFF000084 9: &hFF0000FF 10: &hFF840084 11: &hFFFF00FF 12: &hFF008484 13: &hFF00FFFF 14: &hFF848484 15: &hFFFFFFFFDIM TCOLOR%[] = [ \ &h00000000, \ &hFF000000, \ &hFF840000, \ &hFFFF0000, \ &hFF008400, \ &hFF00FF00, \ &hFF848400, \ &hFFFFFF00, \ &hFF000084, \ &hFF0000FF, \ &hFF840084, \ &hFFFF00FF, \ &hFF008484, \ &hFF00FFFF, \ &hFF848484, \ &hFFFFFFFF \ ]Though if you were smart and used the named constants in SB3 it's as easy as changing the constant names in your ported code.COLOR #TRED 'old COLOR #C_RED 'new
Does anyone know how I can remove the right stick from touch screen inputs?
When gathering data from touch(), the right stick influences the result even when the right stick hasn't been used with sticks().
Hi, I was using SmileBasic for Switch last night and have a few more questions if anyone knows the answer.
So, on the topic of text colors, in old SmileBasic (3DS) and Petit Computer (DS) the color command took two parameters, the text color and the background color. Now it appears that while you can optionally supply a text screen to set the color of, you can only pass in one color. I found TBACKGROUND, but that sets the background color for the whole screen. Is there a way to set the text background color (for each character)? I really don't want to have to do GFILL commands behind my text if possible.
My second question is about GPAGE. It appears that it is gone, is that right? Did it get renamed and I couldn't find it? The closest approximation I could find was to use GTARGET to draw to an offscreen surface, then to use GTARGET to point back to the visible surface and GCOPY everything over. That seems like it should be much slower than simply changing which page of memory you were pointed at. Is that the best we have? Or is there a better way I missed?
Thanks in advance.