Screenshots without Miiverse

Well, I'm definitely not updating. 0.5 seconds is a very long time... I was expecting something like 10 frames, but half a second to end a program is not ok.

You're being sarcastic, right?

no I don't understand why they decided to fix a nonexistant problem. If anything they should've made it an option or only delayed the start button outside of the editor. I might update my old 3ds just to see how bad it is, but for now it's definitely not worth it.

Perhaps it's addressed elsewhere but 12me has neglected to mention the reason for his disapproval: Delaying the program halt makes testing harder (with small programs) Often you can have a scenario like this: - Make small change - run - non-breaking issue - halt - go to step 1 And a delay makes that a lot more annoying. Now either you use the touch screen (STOP) or build an alternative button check to END into every loop.

Perhaps it's addressed elsewhere but 12me has neglected to mention the reason for his disapproval: Delaying the program halt makes testing harder (with small programs) And a delay makes that a lot more annoying. Now either you use the touch screen (STOP) or build an alternative button check to END into every loop.

but on the other hand we get to use the start button in our games, right?

Perhaps it's addressed elsewhere but 12me has neglected to mention the reason for his disapproval: Delaying the program halt makes testing harder (with small programs) And a delay makes that a lot more annoying. Now either you use the touch screen (STOP) or build an alternative button check to END into every loop.

but on the other hand we get to use the start button in our games, right?

nope. You *can* detect select, but that takes a screenshot so it's not ok (Basically, you can find out when people take screenshots, if you want to do that for some reason...). I'm guessing this is just a bug. They probably blocked out the BUTTON code for START, but not SELECT (before, START/SELECT were treated as the same button so it didn't matter)

Actually 250ms is a quarter of a second. If you want to know what this actually feels like instead of complaining you can run this. Background turns red once you've held the button for 250ms. If your priority is that you can't stand holding a button down for a quarter second longer then idk what to tell you lol IMO the screenshot action and bugfixes are too important to not update for.

I've already done tests using 0.5 and 0.25 seconds. The results are that anything over 0.1 seconds is too much. Remember that a second is actually quite a long time, compared to what you'd think You can do a lot of things in 1 second. Also nice fingers

Now it's my mission to make a game where every input is delayed by 250ms

Now it's my mission to make a game where every input is delayed by 250ms

It has to ignore the first 0.25 seconds of every button press, not just delay them.

Do not fret! The Start buttton may have an option in the menu! ...but I don’t hold much faith in that, now that I’m typing this...

The new screenshots are actually lower quality than miiverse (still better than nothing, of course). old, new

I looked in the Estore for SmileBASIC but saw no update.... im U.S btw.

They don't come out in all regions at the same time. Japan always comes first.

figures

figures

Well the heart of Nintendo is in Japan so verification must start there then it probably "expands" to the next nearest countries and so on.

figures

Well the heart of Nintendo is in Japan so verification must start there then it probably "expands" to the next nearest countries and so on.

Actually, the reason is because SmileBoom is a small Japanese company. Your game has to be authorized by whatever Nintendo branch operates in your region (in order to conform to local regulation) before it's released there. Games coming to market in America first only need to be authorized by NoA and the ESRB; each Nintendo branch is pretty autonomous in this regard. Furthermore, if your game is authorized in American first and is releasing in Japan you still have to go to NoJ to get it approved because Japanese law is different from American law.

One easy way to do this without homebrew is to simply create an external library that, when called, will output the contents of the screen to a file. You could then transfer the file to your computer to edit. This could even be done without homebrew if you used something like PetitModem to transfer the file over. Here's a few examples. The first program is done completely on the graph screen, and the second program is done completely on the console screen. I did it by making a "SCREEN" library so whenever I called "SCREEN SOME_FILE_NAME$" it would save a screenshot to that file (in PPM format). It can capture both the graph screen and the console screen (by first copying the console screen into the graph screen). Not sure how you'd capture the sprite screen as I never use it. No lossy compression either. 👌

One easy way to do this without homebrew is to simply create an external library that, when called, will output the contents of the screen to a file. You could then transfer the file to your computer to edit. This could even be done without homebrew if you used something like PetitModem to transfer the file over. Here's a few examples. The first program is done completely on the graph screen, and the second program is done completely on the console screen. I did it by making a "SCREEN" library so whenever I called "SCREEN SOME_FILE_NAME$" it would save a screenshot to that file (in PPM format). It can capture both the graph screen and the console screen (by first copying the console screen into the graph screen). Not sure how you'd capture the sprite screen as I never use it. No lossy compression either. 👌

I've done this before, and unfortunately depending on the program there is some unrecoverable information that makes it impossible to reproduce the image. Stuff like display mode and console text color are impossible to check at runtime, so you cannot make a "on size fits all" library for this, unfortunately. I added the GRP screencap function to Cave Platformer in case you wanted to see what all I did. It's very game-specific, but that's because the game itself provides me with that extra info I needed to redraw the screen, and as a result I can reproduce it perfectly.

If you replace commands like XSCREEN, COLOR, BGSCREEN, etc. it's much easier. I made a system to save the location of all the sprites/whatever into a JSON file. It's a much smaller file, but you also have to send the sprite sheets. (If you just include a copy of the graphics in the screenshot decoder, you don't have to do this, though.) This way you don't have to worry about handling sprite rotation/scaling in SB, which would be slow and difficult.

Yeah you could just make copies of the problematic commands that store state but that kinda defeats the purpose of a drop-in-anywhere library, and you have to give them weird names. Since 3.6 is coming out we really don't have to worry about screenshot-aware programs anymore (I hope.)