SmileBASIC 4 Discussion「プチコン4」

From what I heard, it's to help limit saving too often, and potentially causing issues with the Switch's internal flash. A necessary evil.

Can i have a new link to the discord?

Realized that you can't use multiple filters on the same layer at once. Was trying to use Mosaic alongside Horizontal Raster Deformations, but only the last one set would be used. Oh well.

So I converted BGOFS and BGLOAD to TOFS and TLOAD, and in the original SB3 program the BG moved nice and smoothly, with few bugs. But in SB4 it dissapears if you move too low and jitters back and forth as you try moving sideways. Any ideas why this might happen?

So I converted BGOFS and BGLOAD to TOFS and TLOAD, and in the original SB3 program the BG moved nice and smoothly, with few bugs. But in SB4 it dissapears if you move too low and jitters back and forth as you try moving sideways. Any ideas why this might happen?

Tough to say without a code example, but note that the format of the array you use with TLOAD is a bit different now.

So I converted BGOFS and BGLOAD to TOFS and TLOAD, and in the original SB3 program the BG moved nice and smoothly, with few bugs. But in SB4 it dissapears if you move too low and jitters back and forth as you try moving sideways. Any ideas why this might happen?

Tough to say without a code example, but note that the format of the array you use with TLOAD is a bit different now.

Dunno how SB3's BGs are structures, but with SB4, it's 2 elements per tile. First element is the tile itself, which for user-defined titles begins at &HE800, and can have up to 4096 tiles. I thought the second entry would have rotation, mirroring, etc, but it seems it has the RGBA8 (in SB4 hex, it would be AARRGGBB). Fully visible with no change in color would be &FFFFFFFF, or -1 if you prefer. Maybe those other attribute values are in the first entry in a different position. I'm just barely getting into this stuff myself. edit: Silly me. The ATTR attributes are in the first element, from bit16 - bit19.

Yeah. So uh I fixed the jittering; I had to change how TLOAD and TOFS handled coordinates a little bit. But the BG still disappears after a certain distance. Like if the resolution is 1080 wide then it'll disappear at 388, and if it's 720 it'll disappear at 208. From what I've observed, it seems to disappear when the text reaches the edge of the screen, and that could be why it's different between multiple resolutions. I'm not sure what's happening, though.

Yeah. So uh I fixed the jittering; I had to change how TLOAD and TOFS handled coordinates a little bit. But the BG still disappears after a certain distance. Like if the resolution is 1080 wide then it'll disappear at 388, and if it's 720 it'll disappear at 208. From what I've observed, it seems to disappear when the text reaches the edge of the screen, and that could be why it's different between multiple resolutions. I'm not sure what's happening, though.

It just completely disappears? What do the read values of TOFS say about that text-screen position?

Yeah. So uh I fixed the jittering; I had to change how TLOAD and TOFS handled coordinates a little bit. But the BG still disappears after a certain distance. Like if the resolution is 1080 wide then it'll disappear at 388, and if it's 720 it'll disappear at 208. From what I've observed, it seems to disappear when the text reaches the edge of the screen, and that could be why it's different between multiple resolutions. I'm not sure what's happening, though.

I'm not having any issues like that, so it's hard to tell what's going on without seeing the code.

Is there a way to do color subtraction? Would really help with the effect I'm trying to do, as using color multiplication just doesn't get it right.

Is there a way to do color subtraction? Would really help with the effect I'm trying to do, as using color multiplication just doesn't get it right.

I think you can do this by using "RGB (Color) OUT R,G,B" for each color (use separate variables for each color) and subtracting their values. Then you can assemble the values using RGB().

Is there a way to do color subtraction? Would really help with the effect I'm trying to do, as using color multiplication just doesn't get it right.

I think you can do this by using "RGB (Color) OUT R,G,B" for each color (use separate variables for each color) and subtracting their values. Then you can assemble the values using RGB().

Or maybe multiply by a fraction if I understand the situation.

Is there a way to do color subtraction? Would really help with the effect I'm trying to do, as using color multiplication just doesn't get it right.

I think you can do this by using "RGB (Color) OUT R,G,B" for each color (use separate variables for each color) and subtracting their values. Then you can assemble the values using RGB().

I was hoping for a more automated approach much like how one can use layer composition to do things like additive and multiplicative (as I'm currently using layering for the approximation).

Or maybe multiply by a fraction if I understand the situation.

That is what I'm currently doing as it's the closest I can get without actual subtraction, but unfortunately, it's not quite the result I'm looking for. Ex: while white (1.0) subtracted or divided by gray (0.5) will have the same result, subtracting gray from gray will be 0.0 while multiplying grey by grey will give a darker grey (0.25). Do the devs listen to feedback and suggestions regarding functionality?

Yeah. So uh I fixed the jittering; I had to change how TLOAD and TOFS handled coordinates a little bit. But the BG still disappears after a certain distance. Like if the resolution is 1080 wide then it'll disappear at 388, and if it's 720 it'll disappear at 208. From what I've observed, it seems to disappear when the text reaches the edge of the screen, and that could be why it's different between multiple resolutions. I'm not sure what's happening, though.

I'm not having any issues like that, so it's hard to tell what's going on without seeing the code.

Ok sorry for low quality And just so you know what all of the variables are: CX and CY are the camera position in the middle of the screen where the player is. If you move right, CX increases, and if you move down, CY increases. XW and XH are the screen sizes used in XSCREEN. I incorporated them so you can freely change the screen size and the player would still be in the middle of the screen and stuff. But they don't really contribute to the bug, because it was happening before I added this. MAP% and BGMAP% is the map data. They should be filled with the correct tiles. Also a thought just occured to me: it could be changing the color of the tiles. It shouldn't, but who knows? EDIT: No it's not the colors EDIT2: It seems like it may have to do with the TLOAD coordinates. I just found that the screen seems to disappear >=-1. This seems like it's related. EDIT3: Yeah. It seems like it uses screen coordinates for TLOAD, instead of tile coordinates within the array. And so it freaks out when that reaches -1. EDIT4: Oh crap now that I've confirmed that this is the issue, I need to find a way to fix it. Also, sorry for all of the edits.

Use TCOORD to convert from display coordinates to text screen coordinates?

Use TCOORD to convert from display coordinates to text screen coordinates?

I’ll have to see what that command does.

Actually, I think I know what's going on. You use CLS to clear the text-screen prior to TLOAD, yes? Here's the thing. TLOAD does not like negative X/Y parameters. It will not write to the text-screen if it gets that. Considering that one can use TLOAD to write to a spot where the X+W or Y+H combination can exceed the W or H of the text-screen, I think this might have been an oversight, as they could easily compensate for this.

Actually, I think I know what's going on. You use CLS to clear the text-screen prior to TLOAD, yes? Here's the thing. TLOAD does not like negative X/Y parameters. It will not write to the text-screen if it gets that. Considering that one can use TLOAD to write to a spot where the X+W or Y+H combination can exceed the W or H of the text-screen, I think this might have been an oversight, as they could easily compensate for this.

I don't think I understand everything you're saying. If I were to use TLOAD and add to the screen, part of the screen will disappear, and that part will increase I'm pretty sure. EDIT: Also, another strange thing seems to be happening. As I keep moving, my coordinates change as if there's terrain on screen. I even tested this by making a huge chasm after where the screen disappears, and it's true. But the text needs to be onscreen for it to detect collision and do that. Any ideas?

Actually, I think I know what's going on. You use CLS to clear the text-screen prior to TLOAD, yes? Here's the thing. TLOAD does not like negative X/Y parameters. It will not write to the text-screen if it gets that. Considering that one can use TLOAD to write to a spot where the X+W or Y+H combination can exceed the W or H of the text-screen, I think this might have been an oversight, as they could easily compensate for this.

I don't think I understand everything you're saying. If I were to use TLOAD and add to the screen, part of the screen will disappear, and that part will increase I'm pretty sure.

What I'm saying is this. Imagine loading your map to a text-screen. If the X/Y are (0,0), then it begins copying to the top-left of the text-screen. Increase X to 1, and it offsets the loading one entry to the right, making it look like you're scrolling to the left (everything shifts to the right). But, if you instead offset it to -1, one might think it would just truncate what's outside of the text-screen (to make everything look like it shifts to the left), but it exits the command entirely, and no writing is done. Because you use CLS to clear the text-screen prior, the entire text-screen is blank before TLOAD, and remains blank afterwards due to an invalid X/Y parameter. If you go back into the positive values for X/Y, it'll write again, and you'll see the background.