[Issue] Screenshots Upscaled When Using Hardware Scaler

[JCollins2048]

Issue

What version is this report for?

• 3DS model and firmware: Old 2DS 11.17.0-50U
• open_agb_firm version: Beta build 2024-07-30
• Custom firmware version: boot9strap 1.4
• Loader version: Luma3DS 13.1.2

How do we reproduce the problem?

0. Note: This setup assumes that scaler is unchanged in either config.ini or the game configuration. (The default value is 2 for "hardware".)
1. Open any Game Boy Advance game.
2. Press and Hold Y and Select in any order.
3. Turn off the 3DS, remove the SD Card.
4. Navigate to the 3ds\open_agb_firm\screenshots folder.
5. Look at the new .bmp file in there.

What do you expect to happen?

The screenshot(s) should be at the default Game Boy Advance resolution of 240 x 160 pixels with no filtering, no matter what video scaling method is used.

What actually happens?

The screenshot(s) is/are upscaled to 320 x 240 pixels with some filtering.

Is there anything else you'd like to mention?

When the scaler value is set to 0 or 1, oddly, screenshots are saved at 240 x 160 pixels with no filtering. It's only when hardware filtering is invoked (scaler=2) that the screenshots become upscaled and ugly. I'm not sure why this, but I guess it's because bilinear filtering (scaler=1) is done after the video is created, but overlain atop it? Not sure. I don't notice any impact to performance even on my Old 2DS. So, that's kind of my temporary solution: leave the video filter on bilinear, since a better upscaler is currently unavailable.

I appreciate that bilinear is available, though, since I think hardware upscaling looks kind of ugly, too.

Relevant media

Final Fantasy V Advance menu with different scaler options: 0 (none), 1 (bilinear), and 2 (hardware)
Please note: Modes 0 and 1 both result in native resolution screenshots while 2 does not.

[profi200]

The problem is that hardware scaling scales before the video data is available for making a screenshot. I can change the setting temporarily at the cost of delaying the screenshot but it's kind of a pain to do since it involves a number of changes like stopping DMA and changing the DMA bytecode. I also have not explored what happens if i restart video capture in the middle of a frame.

Scaling modes 0 and 1 use the native resolution without scaling. In mode 1 the GPU does the bilinear scaling. Are you looking for hardware accurate screenshots specifically? If yes you have to be careful because some programs incorrectly convert the bmp files to 8-bit (not proper nearest rounding). GIMP i found does it correctly.

I will take a look if this is worth the trouble.

edit: I almost forgot but the hardware scaler is configurable. oaf will look for "gba_scaler_matrix.bin" in the oaf folder. This file has the same format as what Luma3DS can load from the SD. Also see: https://github.com/profi200/open_agb_firm/blob/master/source/arm11/oaf_video.c#L352 And here are a few older variants i used to keep in the code. The pixel duplication one is really ugly. https://github.com/profi200/open_agb_firm/blob/b7441659ca1a265e0048fbc175d9297ae94bf59f/source/arm11/hardware/lgyfb.c#L147-L170

[JCollins2048]

I did notice that the screenshots couldn't be opened in NeoPaint (now "PixelNEO") v4.6c, but they open fine in Windows Image Preview and Paint.NET. I might have to experiment with games that have more than 256 color on-screen and see how compatible the screens actually are…

That aside, I kinda figured those full-size screenshots were because hardware scaling happens before anything else. It also sounds like a headache to implement 1:1 screenshots while using hardware scaling. That, I wasn't aware of. Luckily, Interpolation suits my needs for now, but more filter types wouldn't hurt. I'm sure those are in the pipeline, though. (:

Thank you for your reply!

I should look into custom hardware scaling a little. It looks reasonable to work with…

[profi200]

A few BMP parsers don't seem to like the format i save them in. It uses a special bitfield mode that allows me to reorder the color channels and also discard the unneeded alpha bit. But every parser that implements the BMP format standard correctly should be able to handle it. Advantage is that i can directly write the raw pixels to the file (100% lossless). All the pixel data is at offset 0x80 in each BMP file.

Also see this for how the BMP files are constructed. https://github.com/profi200/open_agb_firm/blob/master/source/arm11/oaf_video.c#L228

[profi200]

Screenshots should always be in native resolution as of commit edd43a6fcc7b8ffdd32516f250cc576603f8ec43.

See https://github.com/profi200/open_agb_firm/actions for the newest build.

[JCollins2048]

I hope it wasn't too much trouble. Thank you very much!