Analogue Duo Support

[joshcampbell191]

Fix #18

Here's a quick summary of the changes:

• Added a new scaling option for Titles.
• Added logic to retrieve CRC for games that contain multiple ROMs.
• Refactored the logic to apply the scaling first (to make the scaling less confusing - inverting the width / height).
• Fixed a bug when writing the headers for the image size (they were inverted).

Another thing we noticed during the testing was that the images don't appear to be rotated. I don't know if this is new for the upcoming OS 2.0 or if it was simply missed.

Prior to implementing the changes to the rotation logic, I wanted to check with you. How do you feel about adding a flag for the rotation? Another option would be to apply it based on the console, however, this doesn't feel great.

Either way, let me know what you think.

[codewario]

Sorry for the delay, I will have a chance to review this later today.

[codewario]

Alright, I have a few observations. Keep in mind I don't own a Duo so I'm assuming your PR outputs suitable images that display correctly on it.

1. What exactly is the Titles scaling mode intended for? Both Snaps and Titles are technically gameplay images, and on the Pocket, they shouldn't need to be adjusted to fit as both the GBA and GB/C screens fit the space (I am unsure exactly how GG games or HuCards look since I don't have those adapters or games but haven't seen any complaints about them).

   If this is something needed for the Duo specifically, I would suggest instead to replace the "Titles" scaling mode you added with a "DuoOriginal" or "DuoScaled" mode.

2. I don't really think the logic needed to be reworked, but it shouldn't really matter which order we scale/rotate in so as long as it works its fine.

3. Image rotation was already occurring in the original code, so not sure why you said it wasn't.

4. The main change that I see which affects the output image is the order in which the horizontal and vertical bytes are being written in Convert-ImageToAnalogueBmp. The Pocket expects the width to be written first, then the height. If this change results in the images being correct on the Duo without distortion that tells me the following:

   • The distortion was due to the stride being incorrect before your changes (your changes corrected the stride calculation for Duo). An incorrect stride will result in distorted images.
   • The Duo instead expects the reverse order.

   There needs to be a "Duo" mode when creating an image library where these changes in format are done when creating images in the Duo format, and a "Pocket" mode so they are correct for the Pocket. Assuming that PCE libraries are destined for the Duo is not an ideal solution since there is (or will be) a HuCard adapter for the Pocket, and so the "mode" needs to be chosen explicitly by the user creating the image library.

---

Lastly, have you tried generating any Pocket image libraries with your branch? If not, I can create an image library from it to test how they look but if you've already done this it will save me some investigative work. If the images still display correctly on the Pocket with the changes in this PR then really only the first concern should apply, as it's not ideal to scale images if when unnecessary.

[joshcampbell191]

Sorry for the delay in response. I've been a little pre-occupied as of late.

1. The titles scaling mode is intended for generating scaled down images of the title screens for the Analogue Duo based on the images provided by libretro-thumbnails which are scaled to 256x232. I haven't checked against the screenshots provided by the OS.

2. I only re-ordered the logic so that it would be closer to the example provided in the documentation: https://www.analogue.co/developer/docs/library#image-format. Although now that I look at it, it should be the following: Scale > Convert to BGRA > Rotate > Write Binary Data

3. The documentation specifies that the image should be rotated 90 degrees counter-clockwise, this doesn't appear to be the case with the Analogue Duo. I'm wondering if this is an oversight with the 1.1b firmware and will be fixed in a later revision. When the rotation is applied, all of the images are turned on their side.

4. As per my change, I re-ordered the headers for the width and height to match the documentation (width first and height second). You can see that this was incorrect in the original code. I suspect this is because the logic for the BoxArts applies the same scale to both the width and height resulting in a square image in which case the ordering wouldn't matter.

I haven't yet tested this against images for the Analogue pocket but can do so when time permits.

[btrzupek]

I have a Pocket and a Duo, both with the latest firmwares as of today.

I see the image shearing problem with the library images on BOTH devices now.

If I can figure out how to test this commit, I will take a look at it today and see if it resolves the issues.

UPDATE: I tested this on Pocket and it seems to work fine. Duo, however, seems to show the proper image in the Library once the game has been played, but shows the shifted pixel mess in the game load screen still.

The default python script from Analogue has the same behavior as well, as I checked that too