SmileBASIC 4 Discussion「プチコン4」

I swear we mentioned this when it was added last update.

You probably did, I just missed that post. Glad to know it wasn't here the whole time, I was frantically trying to figure out how to keep Buffalo's music synchronized when you dock/undock. (MML keeps playing, but the program briefly halts.)

You should just use BGMVAR for that

You should just use BGMVAR for that

I'm using BGMVAR like crazy, and that's the problem actually. When you change dock status, the music will keep playing for about half a second before the program itself will continue. It's easy to detect when that happens, but not easy to prevent it.

Unfortunately it seems like the characters widths for GPUTCHRP are hardcoded. Making a custom font work with it would be impossible unless you followed the bounding boxes of the default fonts exactly.

Started working on a spreadsheet to show which functions are supported in what environments (direct/main/sub/UI.) Some of the information might be wrong right now and UI is basically nonexistent (it's undocumented and only just became accessible.) Link is comment-only but if you can test and contribute maybe send me a message. We especially need to figure out how the UI environment works. In Data>Filter Views there's some filters that can make reading it easier.

I wonder why they called it SmileBASIC 4 internationally, I mean that's what we called it but it would make more sense for it to be called SmileBASIC 3 or SmileBASIC 2 because it's the 3rd entry in the PTC series to be released outside Japan (2nd in Europe) and the 2nd to be called SmileBASIC.

Because that would be a nightmare to deal with, especially if you want to talk about both the English and Japanese releases. Final Fantasy did that for a while and it's still a pain in the ass to talk about that series to this day.

"I wonder why the fourth smilebasic iteration is called SmileBASIC 4"

Unfortunately it seems like the characters widths for GPUTCHRP are hardcoded. Making a custom font work with it would be impossible unless you followed the bounding boxes of the default fonts exactly.

Yeah that's a bit of a let down. Thankfully it's not too hard to write an automatic-kern function that compares pixels on letters and spaces them appropraitely. Once I tweak it further I can open the source on mine

Unfortunately it seems like the characters widths for GPUTCHRP are hardcoded. Making a custom font work with it would be impossible unless you followed the bounding boxes of the default fonts exactly.

Yeah that's a bit of a let down. Thankfully it's not too hard to write an automatic-kern function that compares pixels on letters and spaces them appropraitely. Once I tweak it further I can open the source on mine

Yeah it's easy, but features should work. Maybe if someone reports it it'll get fixed.

Meh.. I tend not to use much text, in the first place. Seeing walls of Japanese text all over the place soon makes you realise just how important it is for games to be just about the games, and not about all the text you need to translate. If you can do it without text, then do it without text. I try to stick to the basics. Start, game over, level n, player y, 1up, bonus! I've played enough none-English games to know they're "safe" to use..

Yeah it's easy, but features should work. Maybe if someone reports it it'll get fixed.

Couldn't hurt. At least this time it's something we actually can write a replacement for... I think the only way to solve the MML sync issue is if they add another option.

Experimenting very slowly with UI environment. It's very weird. It's interesting the things you can learn by just reading the softkey and help menu source code very carefully. If you aren't aware in the latest update they added UIRUN and UISTOP to direct mode so we can run our own programs in the UI environment, which is where the on screen keyboard and help viewer run (they're SB programs stored in #SYS/.) It's similar to the sub environment in that it's completely parallel and mostly isolated, but it behaves very differently. In weird ways. Nothing about it is formally documented (yet?) but you can learn some things from the code for the UI programs and by experimenting. There's even a few special UI functions that do specific UI related things that we still have to figure stuff about. Maybe we'll get to the point where we can make completely custom keyboards and things. ACLS is broken in some way, or doesn't behave properly when used in the UI environment. It behaves as it does when you use it in the main and sub environments, but these defaults aren't sensible for the UI environment; the UI environment seems to start with a completely different set of display defaults (720p by default etc.) It might also be the source of a weird issue I have trouble reproducing where I can't UIRUN the softkey anymore, which means if I'm using SB4 in handheld mode I have to completely reload the app. Sometimes the top menu breaks as well. SmileBoom is clearly aware of this since they completely avoid using ACLS in the UI programs and clear the screen in other ways. There's even this comment:

ACLS禁止（対応していない機能で誤動作） ACLS prohibited (malfunction with unsupported function)

I don't know if this is a bug that will be fixed, or a design issue that they just have to work around, but either way if you're trying to write UI programs you can't use ACLS or something will be broken. XSCREEN seems to be either broken or just generally not useful in the way that it behaves in the UI environment as well, so just avoid them. Some other weird things include the UI environment only having 384 sprite IDs (compared to 4096 in main and sub) and not having a #GSPRITE set up by default.

Handy functionality to have, but I can't think of a good use for it, off the top of my head. Maybe a little monster in the corner of the screen that gobbles up anything you delete?!

I'm so jealous that I have to wait

How long?

At least 4 months for my Switch And at most 4 years for SmileBoom to bring SB4 to the european eShop

Handy functionality to have, but I can't think of a good use for it, off the top of my head. Maybe a little monster in the corner of the screen that gobbles up anything you delete?!

The default onscreen keyboard is usable but not great. One of those horizontal split in half keyboards would probably be way better for portable use since you could use two thumbs.

Really? 'Cos if you're portable you'd also need to stretch your thumb over the joycon, too. *tries it* Nah, that's not comfortable!!! I think finger prodding would likely work best, preferably on your knee, so big chunky keys filling up the bottom half would likely work better. A USB wireless keyboard&dongle works well enough, and if you get a nice tiny one, you're sorted.. I use a Logitech K400+ and it works well enough, but is slightly bulky with the trackpad on the side. ... annoyingly the trackpad doesn't work. Grrr!!!

Really? 'Cos if you're portable you'd also need to stretch your thumb over the joycon, too. *tries it*

Remove the joycon

Really? 'Cos if you're portable you'd also need to stretch your thumb over the joycon, too. *tries it*

Remove the joycon

I could be wrong about this, But I'm pretty sure you can't use the touch controls if the joycons are detached.

Really? 'Cos if you're portable you'd also need to stretch your thumb over the joycon, too. *tries it*

Remove the joycon

I could be wrong about this, But I'm pretty sure you can't use the touch controls if the joycons are detached.

I think you can. I can't check right now, but I remember some other games that worked with touch controls without the joycons.