Horizontal double-screen games are very small on 4:3 displays (iPad screen)

[MilanPolle]

Version (or build number)

0.1.0

Platform (Pocket or MiSTer)

MiSTer

Steps to reproduce

Use a 4:3 display, like the very popular iPad display (I'm using full resolution 2048 x 1536).
Start a horizontal dual-screen game, like Mario Bros. or Life Boat. Also test with a single display game, like Donkey Kong Jr.

Expected Behavior

I'm expecting horizontal dual-screen games and single-display games to take up most of the width of a 4:3 aspect ratio display.

Actual Behavior

The resulting image is really small on the already small iPad display, displaying large borders left and right. It looks like this is meant to compensate for 16:9 displays. Still acceptable for single-screen games, but horizontal dual-screen games become very small.

Vertical dual-screen games look fine on my 4:3 display.

Additional Context

Only tested on my 4:3 iPad display.

[agg23]

This core's resolution is 720x720, so it is limited to be 720 pixels wide (which of course can get scaled based on your screen). This is a hard limitation; MiSTer cannot sustain data transfer rates faster than this, and thus the ROMs are designed for 720x720.

If you could share a picture of what it looks like, that would be nice, but I believe this is not an addressable issue.

[MilanPolle]

Thanks for the fast response!

I wanted to mention I'm very impressed by this core, the graphics look super sharp. And there's already support for a lot of games. Maybe at some point it might be possible to sync to MiSTer's clock. And hopefully to add some subtle shadows to the LCD graphics.

I've been thinking this over for a bit and it makes sense. MiSTer's scaler will scale it up to 1536 vertically on my screen. With the single screen and horizontal double-screen games that leaves a lot of black area.

I was wondering if it would be possible to switch the resolution to 720 x 540 for the single screen and horizontal double-screen games. That would scale it up perfectly and would help for 1080p (2x integer scale) and 1440p displays as well. For the vertical double-screen games, the current 720 x 720 is perfect.

[agg23]

That's certainly doable (and wouldn't even need ROM changes). However that requires a PLL reconfiguration to change the pixel clock which is always fun. This isn't something I will be able to do soon, but I'll keep it in mind.

[agg23]

Maybe at some point it might be possible to sync to MiSTer's clock

This is something the other GnW core attempted to do but couldn't figure out. Most likely the clock data is stored in a different RAM position for every game, so we would need some way of knowing that, and bake that into the ROM.

And hopefully to add some subtle shadows to the LCD graphics

This is not possible, unless you mean shadows only to the right (not up or down). The MiSTer SDRAM is running at close to full speed to load out 2x 720x720 full color images (one for the LCD mask, one for the background), and a shadow would require a third read on the LCD mask again, just offset. Could be done on Pocket, but I'm not going to do that

[MilanPolle]

That's certainly doable (and wouldn't even need ROM changes). However that requires a PLL reconfiguration to change the pixel clock which is always fun. This isn't something I will be able to do soon, but I'll keep it in mind.

Understandable, I don't know the technical details, but I know a PLL is tricky to adjust. Thanks for considering it!

[MilanPolle]

Maybe at some point it might be possible to sync to MiSTer's clock

This is something the other GnW core attempted to do but couldn't figure out. Most likely the clock data is stored in a different RAM position for every game, so we would need some way of knowing that, and bake that into the ROM.

That makes sense. I don't know if MAME supports this already or if you'd have to dive into the sourcecode of the games themselves to find the address.

And hopefully to add some subtle shadows to the LCD graphics

This is not possible, unless you mean shadows only to the right (not up or down). The MiSTer SDRAM is running at close to full speed to load out 2x 720x720 full color images (one for the LCD mask, one for the background), and a shadow would require a third read on the LCD mask again, just offset. Could be done on Pocket, but I'm not going to do that

I see, I didn't know the memory bandwidth was that limited. Is the LCD mask using anti-aliasing? Then maybe shadows could be built into it.

[agg23]

I see, I didn't know the memory bandwidth was that limited. Is the LCD mask using anti-aliasing? Then maybe shadows could be built into it.

True, I hadn't considered that. If made part of the ROM, you would have to have different ROM sets. The GnW games all have shadowed artwork by default, which I ignore since the LCD doesn't have a shadow, but potentially you could choose to use that as well. But again, you'd been generating a whole new ROM set, so your gnw_dkjr ROM won't necessarily match up with someone elses.

I was trying really hard to keep them consistent, and match capabilities between MiSTer and Pocket as much as possible (Pocket could run at a higher 800x720 res, that dynamic shadow feature discussed above would work with its RAM, etc).

[MilanPolle]

I see, I didn't know the memory bandwidth was that limited. Is the LCD mask using anti-aliasing? Then maybe shadows could be built into it.

True, I hadn't considered that. If made part of the ROM, you would have to have different ROM sets. The GnW games all have shadowed artwork by default, which I ignore since the LCD doesn't have a shadow, but potentially you could choose to use that as well. But again, you'd been generating a whole new ROM set, so your gnw_dkjr ROM won't necessarily match up with someone elses.

I was trying really hard to keep them consistent, and match capabilities between MiSTer and Pocket as much as possible (Pocket could run at a higher 800x720 res, that dynamic shadow feature discussed above would work with its RAM, etc).

Good to know that it might be possible this way.

Is the memory bandwidth used by the core related to the 1000 fps refresh rate?

[agg23]

Is the memory bandwidth used by the core related to the 1000 fps refresh rate?

No. That functionality is not a framerate thing. The LCD segments are sampled at 1000Hz (rather than the CPU default of 64Hz; this is why there's a setting in the core) and deflickered, which helps ensure that we get consistent segment activations and don't deal with aliasing from ~60fps to 64Hz.

The memory bandwidth is due to how high res this core is, and the fact it has to do it twice. Every single pixel loads a full 24-bit RGB pixel for both the background and the mask/LCD layer. This means it takes: 720 x 720 x 2 x 3 = 3.1MB of data per frame, and this needs to happen 60 times a second, so we're loading 3.1MB * 60 = 186.6MB of data per second from the SDRAM. This is pretty close to absolutely maxing out what the MiSTer is capable of (I actually had to shave 6 cycles off each line; that's how close it was to fitting/not fitting).

[MilanPolle]

Thanks for the detailed explanation! Too bad that the SDRAM is a limiting factor to the graphics performance of the MiSTer like this, but the 720 resolution looks perfectly fine for the G&W core.