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

SmileBASIC 4 Discussion「プチコン4」

Root / General / [.]

📌
MZ952Created:
What happened to maps in SB4?
All that's gone is that there isn't a built-in map editor for SB4 (at least not yet, who knows if one'll be added). Map files themselves aren't anything special, they're just integer arrays saved to DAT files using SAVEV "DAT:NAME",ARRAY. The main thing is just loading the data and getting it into a format that TLOAD can use, because this has changed since BGLOAD in SB3. TLOAD expects an integer array that looks like this:
  • The array is three-dimensional, with the size [height, width, 2]. (2D or 1D arrays are fine too, as long as the data's in the right order.)
  • Each tile is represented with a pair of values, so for the tile at coordinates (x, y), ARRAY[y, x, 0] gets the first value, and ARRAY[y, x, 1] gets the second value.
  • The first value holds the display attributes in the upper 16 bits, and the character code in the lower 16 bits.
  • The second value holds the color of the tile, which is the color you set with COLOR, TCOLOR, etc. Usually, this is white.
Now, keep in mind that this is just the format that TLOAD expects. If you make a map editor, there's probably more information you'd store in that file, like what the width and height actually are, or maybe storing multiple BG layers into a single file. It really doesn't matter what format you use, as long as you're able to load it one way or another.

Also, while messing around with that, found an undocumented attribute for tiles: Bit 7 (i.e. 128) is reverse video. It forces the tile color to black (respecting alpha), and uses the color set for that tile as the background color. ATTR won't allow you to set it (it gives an Out of range error), but you can set it with TLOAD, TARRAY, and probably other commands. EDIT: "Forces to black" isn't quite right. It only looks like that in front of a black background. Basically, wherever the font is opaque, it makes the tile transparent there, and vice versa. See below for screenshots that make it much clearer what's going on.

Also, while messing around with that, found an undocumented attribute for tiles: Bit 7 (i.e. 128) is reverse video. It forces the tile color to black (respecting alpha), and uses the color set for that tile as the background color. ATTR won't allow you to set it (it gives an Out of range error), but you can set it with TLOAD, TARRAY, and probably other commands.
Could you send some example images? This seems really interesting.

Also, while messing around with that, found an undocumented attribute for tiles: Bit 7 (i.e. 128) is reverse video. It forces the tile color to black (respecting alpha), and uses the color set for that tile as the background color. ATTR won't allow you to set it (it gives an Out of range error), but you can set it with TLOAD, TARRAY, and probably other commands.
Could you send some example images? This seems really interesting.
I don't have images on hand, but basically just imagine you could set the background color of text, but the foreground color had to be #C_CLEAR. That's pretty much all it is. EDIT: Okay, here they are. While taking these, I found something even more bizarre about this feature: It only works on text screen 4. Considering it's not documented, stuff like ATTR forbids using it, and it's specific to text screen 4, this really feels like some left-over feature they didn't think to remove.

Hmm, so it's like the trick in SB3 where you set the text foreground to transparent and the text background to black. The text screen is basically stenciled by the text characters. IIRC this was faster to make custom text coloring than GPUTCHR was.

The inverse bit seems to be illegal for sprite attributes (Out of range.) If there is one for sprites I can't find it. It is illegal to use the text inverse bit on ATTR TPUT TFILL so the only legitimate way to use it is with TLOAD or a TARRAY/TUPDATE. This seems like a useful feature even if it is weird and smileboom should try to make it more accessible.

So does it invert all the channels? or something more complex?

So does it invert all the channels? or something more complex?
(with colors normalized from 0.0 to 1.0)
(font ARGB = actual pixel colors in GRP)
(tile ARGB = color set with COLOR, etc.)
(ARGB = color displayed on screen)

Normal:
A = font A * tile A
R = font R * tile R
G = font G * tile G
B = font B * tile B

Reverse:
A = (1.0 - font A) * tile A
R = tile R
G = tile G
B = tile B

Are you sure it's not R = (1-font R) * Tile R etc.?

Are you sure it's not R = (1-font R) * Tile R etc.?
Yes, I'm sure. The color of the font is completely ignored other than alpha. (I've done more tests than the screenshots I showed earlier.) The equation might be a little more complicated than just A = (1.0 - font A) * tile A, though. I am sure that the font's RGB channels are ignored, however.

What do all of the function keys do?

What do all of the function keys do?
There's a list of the default keyboard bindings in the reference.

What do all of the function keys do?
There's a list of the default keyboard bindings in the reference.
Some useful ones to know: F1 is help F5 is run F12 is TOP MENU F9-F11 are the smile tools F7 opens the code editor to Slot 0 and F8 is DIRECT MODE

What do all of the function keys do?
There's a list of the default keyboard bindings in the reference.
Some useful ones to know: F1 is help F5 is run F12 is TOP MENU F9-F11 are the smile tools F7 opens the code editor to Slot 0 and F8 is DIRECT MODE
Ctrl+0 is direct and Ctrl+1-4 is edit slots 0-3. IIRC X on the controller switches between edit and direct.

Is there an easy way to load GRP's from SB3 to SB4? I transferred the file over but I can't just use GLOAD.

LOADG "DAT:SB3GRP",0
SAVEG "GRP:SB4GRP",0
Keep in mind this is LOADG/SAVEG, not GLOAD/GSAVE.

Does anyone have a USB mouse that actually works with SB4? Can you read the wheel and tell me what the output looks like?

Mine outputted a number that increased and decreased as I scrolled the mouse wheel up and down. It only seemed to output multiples of 120.

Damn, too bad I'll never get a Switch until Nintendo eventually discontinues it or so...

Has anyone messed around with the IRsensor shooting mode? I’m trying to set something up like the Wii controller where a sprite moves across the screen depending on where you’re pointing a controller. Should I be looking more into the gyroscope or do you think the IRsensor is the right way to pull it off?