SmileBASIC 4 Discussion「プチコン4」

CTCaer is working on adding USB mass storage device support to Hekate, so it may be possible to edit saves without loading a CFW in the future. I was thinking of writing a homebrew to download from SBAPI using a key and inject the downloaded contents into the savedata. It seems that wslay is in devkitPro package repository, so I can use that for websocket support.

Providing support for USB mass storage devices is different from accessing encrypted NAND though (where the saves are kept).

I'm talking about accessing the SD card and NAND as a USB storage device on a PC.

CTCaer is working on adding USB mass storage device support to Hekate, so it may be possible to edit saves without loading a CFW in the future. I was thinking of writing a homebrew to download from SBAPI using a key and inject the downloaded contents into the savedata. It seems that wslay is in devkitPro package repository, so I can use that for websocket support.

Providing support for USB mass storage devices is different from accessing encrypted NAND though (where the saves are kept).

I'm talking about accessing the SD card and NAND as a USB storage device on a PC.

Oh, I see. Not using a USB mass storage device on the Switch, but making the Switch act like one. My mistake.

So, I have a question regarding "source code operations". https://sup4.smilebasic.com/en/doku.php?id=reference:Source_Code_Operation Is this something that would allow us to expand out programs during run-time without saving it? Like, if I have my base program, but I also have a TXT file that contains additional code that gets loaded, then inserted at the end of my program. I'd imagine that with PRGEDIT throwing an error if the program slot specified is one that is executing, so this may be more of a subprogram feature? I began getting some ideas if user-made code additions could be done.

You can manipulate and reload program slots that aren't running/on the callstack (which includes your own). If you say, insert some code into slot 1 and call EXEC 1 from slot 0, the changes will take effect.

Say you inject code into slot 1 and execute it coming from slot 0. I think you can still access the content of the variables from slot 0 via VAR("0:VarName"), but I might be wrong about that.

You can manipulate and reload program slots that aren't running/on the callstack (which includes your own). If you say, insert some code into slot 1 and call EXEC 1 from slot 0, the changes will take effect.

Hmm, looking at EXEC, it says "The variables of the specified slot, SPFUNC, TFUNC setting contents will be cleared." The wording with regards to SPFUNC and TFUNC doesn't seem very clear, as if it could mean those contents in general rather than the specified slot. Maybe it's just how the documentation was translated. Now, if I use EXEC on another slot, that would technically suspend the slot the command was called on, right? That wouldn't allow me to edit the main slot, would it (since it's technically still on the callstack)?

Say you inject code into slot 1 and execute it coming from slot 0. I think you can still access the content of the variables from slot 0 via VAR("0:VarName"), but I might be wrong about that.

If so, then that could help if I can't edit my main program as mentioned just before, as what I could do is make the "interface" of my game in slot 0, and have my main game loop in slot 1 (where such custom code could be utilized), and still be able to read data from slot 0. Would that also allow assigning back to those variables?

You can manipulate and reload program slots that aren't running/on the callstack (which includes your own). If you say, insert some code into slot 1 and call EXEC 1 from slot 0, the changes will take effect.

Hmm, looking at EXEC, it says "The variables of the specified slot, SPFUNC, TFUNC setting contents will be cleared." The wording with regards to SPFUNC and TFUNC doesn't seem very clear, as if it could mean those contents in general rather than the specified slot. Maybe it's just how the documentation was translated.

It should be "The variables and SPFUNC,TFUNC setting contents of the specified slot will be cleared."

Say you inject code into slot 1 and execute it coming from slot 0. I think you can still access the content of the variables from slot 0 via VAR("0:VarName"), but I might be wrong about that.

If so, then that could help if I can't edit my main program as mentioned just before, as what I could do is make the "interface" of my game in slot 0, and have my main game loop in slot 1 (where such custom code could be utilized), and still be able to read data from slot 0. Would that also allow assigning back to those variables?

Yes.

VAR("0:VarName")=1

It should be "The variables and SPFUNC,TFUNC setting contents of the specified slot will be cleared." Yes.

VAR("0:VarName")=1

Good to know on both accounts. I guess now, I should start working on something. Actually, I do have one more thing to ask. It's with regards to text screens. Now, as I understand it, we set up a text screen, like making a background filled with tiles. We then assign the text screen to a layer, and we adjust the positioning, rotation, etc of the text screen while being able to make other adjustments on the layer itself that it is linked to, to handle the rendering. My question is with regards to the edge of the text screens. What is done if a text screen's viewport is on the edge where a text screen ends? Does it not show anything outside the text screen range, or does it wrap around? I know of the "Repeat" parameter with LFILTER, but not necessarily if it's with regards to this specific scenario. Is that how we would provide that functionality, even if we don't do any actual horizontal/vertical deformations? It's just in case I were to make something that technically would require wrap around, such as needing more space than the 32768 character limit that text screens have. Even with a Mode7-like effect using LMATRIX, I'd imagine we'd need some means of wrap around.

Actually, I do have one more thing to ask. It's with regards to text screens. Now, as I understand it, we set up a text screen, like making a background filled with tiles. We then assign the text screen to a layer, and we adjust the positioning, rotation, etc of the text screen while being able to make other adjustments on the layer itself that it is linked to, to handle the rendering. My question is with regards to the edge of the text screens. What is done if a text screen's viewport is on the edge where a text screen ends? Does it not show anything outside the text screen range, or does it wrap around? I know of the "Repeat" parameter with LFILTER, but not necessarily if it's with regards to this specific scenario. Is that how we would provide that functionality, even if we don't do any actual horizontal/vertical deformations? It's just in case I were to make something that technically would require wrap around, such as needing more space than the 32768 character limit that text screens have. Even with a Mode7-like effect using LMATRIX, I'd imagine we'd need some means of wrap around.

Text screens don't have wrapping. They're just blank beyond the edge of it. The repeat parameter to LFILTER relates to H/V scaling; should the layer contents be repeated if you scale < 1x?

Text screens don't have wrapping. They're just blank beyond the edge of it. The repeat parameter to LFILTER relates to H/V scaling; should the layer contents be repeated if you scale < 1x?

Perhaps in that case, the SCROLL command could be something to consider, and then adjust positioning of the text screen to stick to a certain area to wrap around on while updating new tiles on the edges. Still, zooming out enough would just show that it would be cropped, like it was one big sprite.

Text screens don't have wrapping. They're just blank beyond the edge of it. The repeat parameter to LFILTER relates to H/V scaling; should the layer contents be repeated if you scale < 1x?

Perhaps in that case, the SCROLL command could be something to consider, and then adjust positioning of the text screen to stick to a certain area to wrap around on while updating new tiles on the edges. Still, zooming out enough would just show that it would be cropped, like it was one big sprite.

You just have to choose how much you want loaded onto one text screen at once if you're allowing zooming. For a game the zooming would probably be fixed so you can just decide how much to keep loaded and where to load in new maps.

After thinking about it, it's really only an issue with Mode7-like perspective views and setting an angle where one could likely see the edge and the void it leaves, but with some thought, I guess that could be alleviated, whether by using larger character sizes, clever positioning of the "camera", etc. I still wish we had a bit more control. Having a simple Mode7-like perspective plane is nice, but I wish I could make it a bit more "rolling" where it's not so flat, if you know what I mean. Unless that's where LFILTER can come into play.

So I was doing some testing with LFILTER's deformation options to try out the Castlevania IV tunnel effect, and while I have got the effect working, I'm also finding out just how limited it is. Here's a little demonstration. https://twitter.com/DiscostewMC/status/1255043364845547520 The whole problem with the deformations is that it's based on the layer's dimensions, not the text-screen dimensions, GRP, etc. It's range is from 0.0 to 1.0 on both the X/Y axis. When you set a text-screen to a layer, the system renders the visible area of the text-screen to the layer as-is, then manipulates rendering of the layer/buffer to the main draw target with LFILTER. It gets no additional information to work with from outside the layer. This means that when you scale the inner section to be smaller, it repeats what's on the layer already, which while my demonstration doesn't actually show the problem, if you have a large text-screen that can't fully be seen on-screen, it definitely will show as the scaled down parts will repeat over themselves rather than show more of the text-screen. Now, perhaps this can be remedied, but it will takes some thinking and assumptions (and some sleep as it's late for me).

We believe layers are render-to-texture after LMATRIX but before LFILTER and final compositing, since that's the only way the system makes sense. SmileBoom is probably just playing it conservative and rendering only the on-screen contents of the layer to texture.

For Smilebasic 4, is there a way to tell how much free space there is on the save file? I had to expand it once. I find some memory free functions but not sure about the storage. I didn't see an amount with the file commands. Maybe I missed it.

I think the FILES command also prints the amount of bytes free in direct mode, unless they changed that in SB4. Have you expanded your save file to the maximum amount (512 MB)?

I did expand my save file, but the FILES command only was putting the count of files, then the names, then OK in direct mode.

We believe layers are render-to-texture after LMATRIX but before LFILTER and final compositing, since that's the only way the system makes sense. SmileBoom is probably just playing it conservative and rendering only the on-screen contents of the layer to texture.

Figured as much. Anyways, I think I've figured out about how to deal with the issue I tried to explain, but it will take some time. I will upload my results when they are rdy. I will say though, that I currently have it set to where you assign LFILTER deformations once, and simply scroll via TOFS, so the program is not spending execution time filling in data for it. Speaking of save files, is there no way to prevent the confirmation dialog from popping up when saving data to a file, and have it simple write/overwrite the file? It was annoying when it would pop up back when I used PTC.

Speaking of save files, is there no way to prevent the confirmation dialog from popping up when saving data to a file, and have it simple write/overwrite the file? It was annoying when it would pop up back when I used PTC.

No, sorry. I guess they made it mandatory for security reasons. Loading files doesn't make a prompt show up, though.

Speaking of save files, is there no way to prevent the confirmation dialog from popping up when saving data to a file, and have it simple write/overwrite the file? It was annoying when it would pop up back when I used PTC.

No, sorry. I guess they made it mandatory for security reasons. Loading files doesn't make a prompt show up, though.

You mean like accidental overwriting of an important file in the project? Sure, but I'd imagine that in most cases, the person making a project won't go overwriting their own programs and data. Perhaps what they should have done is made 2 file directories within each project. One where your important files go, like your base code, graphics, etc get stored which only need non-interrupted loading, and then another that is completely uninterrupted with reads/writes. The first could still be written to, but the confirmation dialog will show up. Or assign an attribute to the file being written, so that when a file is being overwritten, the existing file's attribute is checked to see if overwriting requires confirmation.