LoginLogin
Might make SBS readonly: thread

SmileBASIC 4 Discussion「プチコン4」

Root / General / [.]

📌
MZ952Created:
Because this thread doesn't seem to exist yet, SB4 is soon to be out (in Japan)! And there's a lot to discuss...

SB4 supports multitouch? https://twitter.com/notohoho/status/1129515354181386241?s=09 TOUCH [touch ID [, coordinate system conversion flag]] OUT touch time, X, Y [, touch area] The reference gives this for touch, so I'm confused how multitouch would work. I probably read the tweet wrong...?

I guess touch ID is which touch point you want to check

I guess touch ID is which touch point you want to check
Huh. That opens a new can of questions. If I put one finger down and then another, then I imagine that the first finger registers as TID 0 and the second TID 1. But what if I lift the first finger? Does 1 become 0, or does it remain 1?

Something of interest is that the definition of a constant expression has been expanded, but it's a bit unclear. translated help page It seems like the functions CHR$ DEG RAD RGB are treated as constant expressions as long as their inputs are also constant expressions. So it's likely they are included in constant folding and are extremely efficient to use.

It's weird how they only mention that in CONST, (as well as CHR$ in DATA) Maybe they did some weird hack and constant functions aren't actually optimized...

It's weird how they only mention that in CONST, (as well as CHR$ in DATA) Maybe they did some weird hack and constant functions aren't actually optimized...
They mention RGB in ENUM since that's the only constant function that is an int and only ints are allowed in ENUM.

HSV() is int too. So is INT(). I wonder if they're just listing examples, though

HSV() is int too. So is INT(). I wonder if they're just listing examples, though
I doubt every function is constant folded so it's probably just the ones included.

wonder if we can have smaller pixels? That would be cool, better graphics.

Yep, you can have anywhere from a 128x128 resolution to a 1280x720 resolution. The width and height have to be a multiple of 4 though.

There's really no reason why they would precompute some functions but not others it's not really any harder than precomputing operators, you just need a list of which functions produce a constant output without any side effects.

How does scaling different resolutions work? Does it just scale upwards with hard edges? Can we also expect significant performance variation between different resolutions?

How does scaling different resolutions work? Does it just scale upwards with hard edges? Can we also expect significant performance variation between different resolutions?
I go into some detail about screen scaling with XSCREEN and other aspects of SmileBASIC 4 in this guide, but basically:
  • You can choose between bilinear filtering, nearest neighbor, or "smart nearest neighbor" which is apparently somewhere between the two, according to the reference.
  • Probably the only real difference in performance would be graphics commands, since you'd naturally be drawing over a larger area of the GRP with larger resolutions. As for how big of a difference it actually is, we'll have to wait for the release to find out.

Do we know if SB4 can take in-game screenshots like SB3? I'm curious because Nintendo seems to have low-balled the crap out of the Switch's screenshot game.

Do we know if SB4 can take in-game screenshots like SB3? I'm curious because Nintendo seems to have low-balled the crap out of the Switch's screenshot game.
The Switch capture button is basically the same thing but substantially better quality.

It cannot. The reason that was added to SB3 is because Miiverse went down and there was no longer any way to take screenshots. That's not the case on the Switch, which has a dedicated screenshot button. Either way, the SB3 screenshot function was pretty bad too in terms of JPEG compression, so it's not like we've lost anything.

I don't actually own a Switch yet, so I can't confirm, but I heard and read that the screenshots it produces are low quality and highly compressed. It's hard to capture pixel art type stuff with, well, any compression. I think it would be a little neat if SB4 had its own in-built function that could maybe snapshot the screen or whole GRPs or something. It would eat memory, which is probably why Nintendo chose to compress their system's screenshots so much, but that can't really be too big a hassle.

Well, there's always the option of capturing video though the HDMI output

SmileBOOM just uploaded 4 videos on SB4. Now watch me try to analyze these. I probably missed a lot of stuff. The first video was https://www.youtube.com/watch?v=ayNsaxF5Kb4 it shows a Pi starter Mk II which seems to run SmileBASIC 4 based on the title of the video. The second video was https://www.youtube.com/watch?v=3ywNYBBqjN4 It's a simple autorunner but here's the thing, IT DOESN'T USE RETRO GRAPHICS! this means SB4 will have an option to use higher quality graphics! The third video was https://www.youtube.com/watch?v=hYqX0d2TsrM It's a version of solid gunner that plays with the switch turned 90 degrees. It also has 2P co-op and 3D CUBES. The background also seems to use multiple layers. The fourth and final video was https://www.youtube.com/watch?v=eTwqNyE1c54 It shows a part of the editor. According to the title of the video, it's an encoder. EDIT:They launched a 5th video. https://www.youtube.com/watch?v=HHDIQbS6CRw It shows the speed test in SB4. Not sure why they released it by itself but okay