Open joshcampbell191 opened 10 months ago
Sorry for the delay, I will have a chance to review this later today.
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.
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.
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.
Image rotation was already occurring in the original code, so not sure why you said it wasn't.
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:
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.
Sorry for the delay in response. I've been a little pre-occupied as of late.
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.
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
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.
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.
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
Fix #18
Here's a quick summary of the changes:
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.