Improve Multi Monitor support

[mbalfour]

A couple of improvements to the MultiMon plugin:

1. Added x/y/width/height controls for the artwork. Useful if you're trying to place artwork at the top of a monitor instead of centered. (For example, for a dedicated marquee monitor)
2. Force cross-fades to complete when launching a game.

[mbalfour]

Note: The one potentially controversial change here is the removal of win->clear() in fe_window.cpp. Please let me know if that needs to become configurable in some way, or if there's a better way to handle this. Basically, the problem is that I would like the marquee artwork to remain on-screen for my second monitor even while the emulator is running. Since AttractMode is effectively paused during launch, I don't see a way to keep updating the display list. So instead, by removing the clear from the wait callback (which only executes while the emulator is launched), the existing display continues to be drawn until we return. I don't know if this has any negative ramifications in any other use cases or platforms, but it works fine for me on Windows.

[mbalfour]

Just discovered/fixed a crash when Generating Romlist with .nes files. A pointer was getting changed which caused a bad delete [] call.

[mickelson]

Thanks for this! A couple of comments/requests:

• in the change to src/fe_window.cpp, did you try removing the call to win->display() as well? I think the call to win->display() should be removed as well, if it still works for you without it.

• please amend the pull request to remove the attract.exe and *.ipch binary files and the vs.json files completely. I'd rather not have a bunch of binary files polluting the git history.

cheers

[mbalfour]

Good point, removed win->display(), it still works without it. The other files were completely accidental, I've removed them, sorry about that.

[mickelson]

Ok merged, thanks!

[smashthehack]

hi mickelson , i use win 10 and msys2 mingw to compile attract.exe, but encounter an error "fatal error: FML/Config.hpp: No such file or directory #include <SFML/Config.hpp>"

what is the solution? i have identic problem of mbalfour. do you want to compile the program for me?

[mbalfour]

If it's the same problem, the fix was released in 2.3. You shouldn't need to compile it yourself unless you're trying to pick up other fixes.

[oomek]

I've managed to identify the cause of backbuffer blinking while launchig mame. It does not happen on every setup that's why is difficult to debug. It does not happen on Nvidia cards, but it does on Radeon with Freesync monitor for example.

Removal of the lines below from fe_window.cpp is the culprit:

        win->clear(); 
        win->display(); 

The window modes affected are Fullscreen and Borderless. I’m not using Fillscreen as it has a terrible performance(layouts are unable to maintaon 60fps on artwork loading)

Is there any particular reason you have decided that in needs to be deleted?
Update: I read your post from above and I understand and I’m offering a solution below.

[oomek]

If it only applies to the multimonitor configuration I would suggest to skip those lines only if the window mode is set to fill screen

[oomek]

I could add it back with some conditionals to my pull request with recent fixes. I would like to close this chapter already, as I’ve been trying to figure out how to fix those stale frames leaking through on emu launch/exit for the last month or so. Today I’ve noticed that 2.3.0 does not have that issue, so I started disecting all the commits since 2.3.0 release and I found your crime :)

[oomek]

Fixed in: 804d0c1

[mbalfour]

Heh, conditionals seems fair, at least that should keep my use case working. The way I saw it, there are a few use cases to consider: 1. Non-primary monitor, want to keep it displaying something (like a marquee) while the emu runs on the main screen. (My use case) 2. Non-primary monitor, want to blank it. You can always write a Nut script to do that. Could potentially be a configuration option of some type though. 3. Primary monitor, emu runs full screen, I didn’t think it mattered what Attract Mode tried to display since it would be overwritten. 4. Primary monitor, emu runs windowed. Not sure if this is a real use case or not, but thought there might be a chance people wanted this to display something too. Basically, it didn’t seem like there was any harm in not blanking it, but if it’s causing problems in some cases it seems reasonable to ignore case 4 above until someone says they need it (if ever). Can you describe the exact repro steps and problem you’re seeing? It would be good to document it here in case anyone ever fiddles with this again. (sent from an iPhone, which encourages brevity)

…

On May 10, 2018, at 8:14 AM, Radek Dutkiewicz ***@***.***> wrote: I could add it back with some conditionals to my pull request with recent fixes. I would like to close this chapter already, as I’ve been trying to figure out how to fix those stale frames leaking through on emu launch/exit for the last month or so. Today I’ve noticed that 2.3.0 does not have that issue, so I started going through all the commits since 2.3.0 release and I found your crime :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[oomek]

My commit disables clearing the screen buffer only when Multi monitor option is set to on and the screen mode is set to Fill Screen which is the only properly working set of modes to have Multimonitor working properly. If you have any other suggestion, feel free to post.