Finally read/skimmed through this entire thread, and now I'm ready to start asking questions. My first question is with regards to sharing via server. No, this isn't about copyright content, but more about user-made content. See, my plan is to port MM2 PTC and remove all references to Mega Man, but keep the general functionality and features of it. One of the features was a level editor where folks can make their own levels and share them. With PTC, sharing was done by GRP saved/loaded from the SD card. Obviously this isn't something that can be done on the Switch with Nintendo restricting such save data to internal storage. I know we can upload our projects to the servers (given we have a ticket to do so, right?), but would one be able to share data made from a project in this same manner? And just in case we can only upload projects, could one technically make a "user-content" project that purely holds content made with other projects? Can we copy files created in one project to another project? Second is with regards to USB Keyboards and Mice. It has been noted that many wireless mice do not work (but no mention of wireless keyboards afaik). My plan was to buy a Logitech multi-device BT wireless keyboard/mouse combo, and use the USB receiver on the Switch dock since we can't use BT Keyboards/Mice directly. Has anyone tested what works?An upload slot can contain either a single file or a single project. You have ten upload slots per ticket you own and this never expires. As rando mentioned you can freely copy files between projects. When you download a key that contains a single file and not a project you're asked for which project on the local system to save it into, which makes this kind of thing very easy. To clarify, a "project" is just a folder with files in it. SmileBASIC doesn't care what is in it, everything is just files. From what I've seen, all KB/Mouse combo devices only support the keyboard part. My Logi Unifying set uses two separate devices on one receiver, and even that doesn't let me use the mouse.
SmileBASIC 4 Discussion「プチコン4」
An upload slot can contain either a single file or a single project. You have ten upload slots per ticket you own and this never expires. As rando mentioned you can freely copy files between projects. When you download a key that contains a single file and not a project you're asked for which project on the local system to save it into, which makes this kind of thing very easy. From what I've seen, all KB/Mouse combo devices only support the keyboard part. My Logi Unifying set uses two separate devices on one receiver, and even that doesn't let me use the mouse.Ah, so each ticket counts for 10 slots. Is there a limit to how big a project/file is allowed per slot? Figure that if I made my project, I could do the same thing as I did in PTC, and allow people to take multiple levels created and compile them into a single file. That way, they can just keep adding to the same file, and keep using the same slot to hold their works. Sad to hear about how it's not likely these unifying sets will work fully.
Well, SB4's GRPs are upwards of 2048x2048 pixels, and being 32bit, that would be roughly 16MB uncompressed. But because the data is compressed when put into files, that final size should be pretty low. How well does it compress if an entire GRP is filled with random data? Now, this 20MB is the limit for an upload slot? What about a local project? Just wondering if we can have a bigger project locally, but then split it up into multiple upload slots to then check when executing the program to see if the necessary files exist. Or does SB4 identify this when wanting to upload a project larger than 20MB and utilize additional slots automatically?I think the size limit is 20MB total per upload slot.Whoa that's so much better than the 4 MB limit on SB3. I bet it's because of bigger GRPs.
There is no per project storage limit locally, but the SB filesystem has a global maximum of 256MB (starts as 64 and can be increased to 256 in settings.) Uploading does not auto-split if the project is too large, I don't think. I belive the compression is just gzip.Well, SB4's GRPs are upwards of 2048x2048 pixels, and being 32bit, that would be roughly 16MB uncompressed. But because the data is compressed when put into files, that final size should be pretty low. How well does it compress if an entire GRP is filled with random data? Now, this 20MB is the limit for an upload slot? What about a local project? Just wondering if we can have a bigger project locally, but then split it up into multiple upload slots to then check when executing the program to see if the necessary files exist. Or does SB4 identify this when wanting to upload a project larger than 20MB and utilize additional slots automatically?I think the size limit is 20MB total per upload slot.Whoa that's so much better than the 4 MB limit on SB3. I bet it's because of bigger GRPs.
There is no per project storage limit locally, but the SB filesystem has a global maximum of 256MB (starts as 64 and can be increased to 256 in settings.) Uploading does not auto-split if the project is too large, I don't think. I belive the compression is just gzip.Well, if it doesn't auto-split, then we can technically manage the files ourselves by compiling our data into fewer larger files, assign those larger files to separate slots, and have our programs use CHKFILE to make sure they have all the necessary files before continuing. Man, all this thinking is really getting me in the mood to program. Just made a 2048x2048 32bit bitmap filled with high noise, and used 7-zip to do normal gzip compression on it (assuming this is the same compression). It reduced the file size from 16MB to roughly 5.54MB. This is with intense noise, which is unlikely to be used for normal graphical data, so a full graphic sheet with plenty of color patterns and transparent sections is going to be even smaller.
RE wireless mouse.
I, too, have a Logitech combo, and the trackpad doesn't work on that, either. But I don't think the Switch hardware is set up to recognise two devices from one USB dongle.
If you have two dongles, eg the mouse has its own, then it ... "should" work. I think.. maybe.. but I haven't tested it.
Honestly, you don't need a mouse. I've written everything I've written without needing a mouse.
Most, if not all tools, have been designed with dpad use in mind. The image editor can get a little finicky, but you always have the option to use the right thumbstick to move a cursor.
For my sprinting purposes, I ended up writing a quick and easy little dpad-based sprite editor of my own. It's not powerful by any means, but it's fit for the purposes that I need it for, and there's no faffing about with a mouse.
Coding is coding. You don't need a mouse for that!!
Having said all that, I'm exclusively using it in Handheld mode. If I weren't, and didn't have occasional "tap the touchscreen" access, that might not have been so easy in places.
Last night I spent over an hour trying to figure out how to get the new text screen stuff working... I finally realized that I have to use hex values with TPUT. I thought I could just use numbers but I guess not. Still some stuff I'm confused about but I think I've pretty much got the hang of it now. I'm going to get my platformer system from SB3 ported over and then maybe I'll actually make a game with it.
I finally realized that I have to use hex values with TPUT. I thought I could just use numbers but I guess not.You don't have to. For example, both of these will put a house on the screen.
TPUT 0,5,5,&HE9D1 TPUT 0,5,5,59857You may have been converting between hex and decimal incorrectly. Either that, or you're trying to use values from SB3 as is. Keep in mind that you have to add the number &HE800 (which is 59392). In other words, tile 10 in SB3 is tile 59392+10 in SB4, which is 59402.
I have a question about text screens:
Can I rotate a single tile and not the rest of the screen without dedicating an entire tile to the rotation of another tile? In other words, can I write the word "other" and rotate the "e" 90 degrees while not rotating anything else, while keeping it all on one screen?
I think so. Isn't ATTR still a thing? Also, I recall reading something in the manual about being able to retrieve ATTR data, so yeah, I'm inclined to believe it's possible.Hmm. iirc, I'm pretty sure ATTR affects the whole screen in SB3, but I could be wrong. I'll go figure that out now. EDIT: Guess I'm wrong. ATTR only affects text printed after it's used.
Oh okay, yeah that was my issue. I was using 1 thinking that it would put *something* on the screen. It didn't help that SmileTOOL only seems to show the characters for one TPAGE, and it's not the one I was trying to use. I have to wonder though, is there a reason for them to make tiles primarily use hex, and start at such a high value? I don't understand why they wouldn't just start at 0.I finally realized that I have to use hex values with TPUT. I thought I could just use numbers but I guess not.You don't have to. For example, both of these will put a house on the screen.TPUT 0,5,5,&HE9D1 TPUT 0,5,5,59857You may have been converting between hex and decimal incorrectly. Either that, or you're trying to use values from SB3 as is. Keep in mind that you have to add the number &HE800 (which is 59392). In other words, tile 10 in SB3 is tile 59392+10 in SB4, which is 59402.
I thought the same for like years actually. I think it might've at one point??? Or maybe that was it's function on PTC. Anyway, I know better now because I built a text-based tile system thing for a platform game using ATTR. If you don't like the look of repeating tiles, randomly rotate and vertically/horizontally invert their textures.I think so. Isn't ATTR still a thing? Also, I recall reading something in the manual about being able to retrieve ATTR data, so yeah, I'm inclined to believe it's possible.Hmm. iirc, I'm pretty sure ATTR affects the whole screen in SB3, but I could be wrong. I'll go figure that out now. EDIT: Guess I'm wrong. ATTR only affects text printed after it's used.