Album directory output, game name output, accidental screenshots from Ultrahand

[monstrosities]

It's a minor thing but the output location for PNGShot feels a bit odd when there's no homebrew there, it means that you get an empty folder taking up space when browsing homebrew menu. bitmap-printer uses Nintendo/Album/Bitmaps/ in the correct Album directory per sysmmc/emummc.

I wondered if you would consider using Nintendo/Album/PNGs/? I think it works a little better from an organizational perspective, then original Nintendo jpeg screenshots, bitmaps and pngs can all be grabbed and viewed from the same place.

Thanks!

[monstrosities]

Also one other question, is there some way it could perhaps output screenshots to subfolders with the game name? There are ways to view official screenshots like that so it would be cool if it would be possible here. I understand you may not want to do much more work on this one though.

[J-D-K]

The first is really simple, so I can get that done quickly. I know I had a way to detect games being launched for JKSysV that I can probably reuse to at least categorize by title ID. Doing what JKSV does in straight C with titles and safe strings doesn't sound like a fun time.

[monstrosities]

Cool! Even title id would be awesome if that works.

[J-D-K]

Just an update: So, doing this is going to be more involved than I thought. PNGShot currently uses standard C stdio functions to write files. I'm going to have to write functions to write the files using libnx's file functions to get this to work the correct way with libpng. It's not difficult, just time consuming because libpng's documentation is a giant text file...

[monstrosities]

Thank you for the update and the release!

I have a question, I thought I would just ask here rather than start a new issue. I noticed whenever I open the following Tesla-Menu replacement it takes a PNG screenshot when using PNGShot: https://github.com/ppkantorski/Ultrahand-Overlay

Do you have any idea on why that would happen? I don't know where the issue really lies, it might be nothing to do with PNGShot.

Other things I tried:

• bitmap-printer instead of PNGShot: opening Ultrahand-Overlay does NOT create a BMP screenshot
• Tesla-Menu instead of Ultrahand-Overlay: opening Tesla-Menu does NOT create a PNG screenshot

[impeeza]

It's weird, please let @ppkantorski to know about this on https://gbatemp.net/threads/ultrahand-overlay-the-fully-craft-able-overlay-executor.633560/post-10491095 and https://github.com/ppkantorski/Ultrahand-Overlay/

[monstrosities]

Eh I know where to open issues, the same link is in my post. I just asked here first because the issue presents itself in PNGShot.

[impeeza]

ppkantorski told Ultrahand overlay trigger the captureButtonPressEvent

https://gbatemp.net/threads/ultrahand-overlay-the-fully-craft-able-overlay-executor.633560/post-10497995
:

has something to do with how they handle captureButtonPressEvent. I know this issue isnt present in BMPPrinter, so it comes down to how they implemented it. Ultrahand utilized captureButtonPressEvent to make screenshots opaque. i cant auite figure out the exact way to prevent issues with PNGShot on my end, so something may have to change in PNGShot's code.

[monstrosities]

ppkantorski told Ultrahand overlay trigger the captureButtonPressEvent

https://gbatemp.net/threads/ultrahand-overlay-the-fully-craft-able-overlay-executor.633560/post-10497995 :

has something to do with how they handle captureButtonPressEvent. I know this issue isnt present in BMPPrinter, so it comes down to how they implemented it. Ultrahand utilized captureButtonPressEvent to make screenshots opaque. i cant auite figure out the exact way to prevent issues with PNGShot on my end, so something may have to change in PNGShot's code.

Thanks for the info, hopefully someone can work out a fix.

[ppkantorski]

Here's more details. For some reason when using following code

            // For handling screenshots color alpha
            Event captureButtonPressEvent = {};
            hidsysAcquireCaptureButtonEventHandle(&captureButtonPressEvent, false);
            eventClear(&captureButtonPressEvent);
            hlp::ScopeGuard captureButtonEventGuard([&] { eventClose(&captureButtonPressEvent); });

in any other project, it triggers an extremely brief capture event (different from an actual screen capture) which in your code has no distinguishability to tell if the event was indeed a capture button click and release or not. My guess is that you need to use some click and release timings to handle detecting if it was indeed a button click and not just an extremely brief event like the one in the code being called in other programs. That from what I can tell is how BMPPrinter does it differently than this project. A long hold and release should also not take any pictures (which has not been quite accounted for in this project).

As for why that code is triggering a capture button event, I am not sure either. One would assume it wouldn't, but for some reason it does just to get a hold of the button event. Simply running hidsysAcquireCaptureButtonEventHandle with true or false appears to trigger an event every time.

[ppkantorski]

More details from libnx.
Gets an Event which is signaled when HidCaptureButtonState is updated.

So from what I can tell it never actually returns to you direct information on when the button is clicked, just when the state is modified in some manor (which for the majority of the time is when the button is clicked). So introducing a small minimum window of time for the event to be held then released might help filter the events for the exact moment when a real click is realized.

[ppkantorski]

I actually fixed the problem within your code. I can submit a pull request.

Update:
Pull request fixing this issue for you has been submitted. Feel free to review the implementation.

[impeeza]

Yes please.

[monstrosities]

I actually fixed the problem within your code. I can submit a pull request.

Update: Pull request fixing this issue for you has been submitted. Feel free to review the implementation.

From what I tested with these new commits the issue can still occur.

[J-D-K]

I'll try to run some tests and see what I can figure out soonish. That code @ppkantorski added is almost identical to bitmapprinters way of handling it. Does anyone know if it does the same thing?

[ppkantorski]

I actually fixed the problem within your code. I can submit a pull request.
Update: Pull request fixing this issue for you has been submitted. Feel free to review the implementation.

From what I tested with these new commits the issue can still occur.

Threshelds probably needs adjusting. i too noticed it occur when entering overlays back to back really quickly that use captureButtonPressEvent after building more overlays with libultrahand.

I'll try to run some tests and see what I can figure out soonish. That code @ppkantorski added is almost identical to bitmapprinters way of handling it. Does anyone know if it does the same thing?

its similar (but not exactly the same). BMPPrinter may also have this issue. i think that how the event is filtered may need some slight tweaking to prevent more random screenshots.

[ppkantorski]

ok i thought of a better way to address this. the way it works right now is it looks for 2 events, click and release. but when opening overlays sometimes it will trigger just 1 event which can be misinterpreted as a click.

To get around this, we can make overlays like Ultrahand and other overlays built with libultrahand trigger 2 extremely quick back to back events when accessing the button state (instead of 1) so PNGShot does not get confused. I also tweaked the filter slightly, but i am still looking over my changes.

Update:
I've reset the max thresholds back to 500ms. Not much is different now in my PR except for if (R_SUCCEEDED(eventWait(&captureButtonEvent, 100000000))).

I'll have to update Ultrahand again soon with this fix, as well as libultrahand compiled overlays. No more random screenshots. However now BMPPrinter will take a screenshot every time you open Ultrahand. (because of no minimum threshold implemented in their code) So I may need to submit a PR to them fixing their filter.

[monstrosities]

The accidental screenshot issue seems to be fixed now with the latest updates from @ppkantorski to pngshot and ultrahand and if I'm not mistaken all the experimental features even work without taking up the extra memory now!

This issue strayed quite a lot from the original post so I'll change the title. The only thing remaining was the query about outputting the png screenshots into game name folders.