emu4crt Mednafen mod - update 1.26.1

[silmalik]

Hi,

I've put online a Mednafen mod: emu4crt, which support native resolutions for a "perfect" rendering.

Supported Mednafen's modules :
   Sega Saturn (win64 build only)
   Sega Megadrive/Genesis
   Sega Master System
   Sony Playstation
   NEC PC Engine / CD / superGrafx
   NEC PC-FX
   Nintendo Snes and Snes Faust
   Nintendo Nes

Builds provided for Windows 32 & 64bits
Download binaries & patches: https://github.com/emu4crt/files
Sources: https://github.com/emu4crt/mednafen

For usage, please have a look to the README displayed on the download page.
Basic knowledge of CRT Emudriver/VMMaker is required as video modes are not generated by the emulator.

Feel free to report any comment or issue.

Revision History:
1.26.0 A13 - Update to Mednafen 1.26.1
1.26.0 A13 - Update to Mednafen 1.26.0 UNSTABLE
1.24.3 A13 - Update to Mednafen 1.24.3 and minor fix
1.24.2 A13 - Update and Megadrive/Genesis interlaced mode fix
1.24.1 A12 - Fix super resolution switch & PCFX scaling
1.24.1 A11 - Add pce_fast, sms, md and pcfx modules
1.24.0 A10 - Update mod to A10 - Improve resolution switch delay and fix PSX horizontal centering
1.24.0 A09 - Update to Mednafen 1.24.0 UNSTABLE
1.23.0 A09 - Update to Mednafen 1.23.0 UNSTABLE
1.22.1 A09 - Update to Mednafen 1.22.1 - Add snes_faust module.
1.21.0 A08 - Update to Mednafen 1.21.0 UNSTABLE *** Changes in settings and configuration files, refer to official site: https://mednafen.github.io ***
          Add Hotdog932al PSX core centering/cropping fix
 0.9.48 A07 - Support Super Resolution
 0.9.48 A06 - OSD improvement and PSX "post bios" bug fix.
 0.9.48 A05 - Fix fullscreen mode switch
 0.9.48 A04 - Update to Mednafen sources 0.9.48, fix video options, preliminary OSD adaptations.
 0.9.47 A02 - Added support for NEC PC Engine
 0.9.47 A01 - Initial release

[Guilt]

This is very exciting. I played around with it and I'm not certain I understand how to use it.
I read through the rtf and here's what I can figure:
Unzip to the same directory as the mednafen executable
Copy the lifelines from the txt file and append them into the user_modes or _super .ini files and install the lifelines
C:\mednafen> emu4crt [romname]
And after doing that I'm certainly playing the game but definitely not at native resolution. It's also windowed, and as mentioned in the RTF I should not alt+enter for full screen (and doing so gives me a 31khz signal) but I'm not really sure what else to do if I want full screen games. So... What exactly does one need to do that I haven't done?

[silmalik]

You are doing well... maybe you have same issue I used to have, here some precisions:

Unzip to the same directory as the mednafen executable:
  Yes, you can just unzip the emu4crt.exe file to your existing mednafen directory.
  At first launch, emu4crt.exe will add a new option to the mednafen-09x.cfg: video.UseNativeResolution (should be at 1 by default).

Mednafen save the fullscreen/window mode, so quit mednafen with ESC key while in desired mode, or have a look to the .cfg file. 

If mednafen or emu4crt switches to a 31kHz mode, you can try this fix:
  1 - Stop and Disable service: AMD External events utility
  2 - Ensure that the Windows advanced display option is enable: "hide modes that is monitor cannot display"

This service often resets the "hide modes", so standard 31kHz video modes are exposed to applications, not good for our usage.

Switching emu4crt from Fullscreen to window is not dangerous, It doesn't create video modes on the fly as Groovymame, it can only use resolutions provided by Windows.

 Just that the image will not be scaled correctly to 1:1 pixel but to a smaller or greater size. In such case you can wait that the game decide to change resolution.

[Calamity]

Hi silmalik,

Great job with your Mednafen mod, I'm eager to test it.

This service often resets the "hide modes", so standard 31kHz video modes are exposed to applications, not good for our usage.

How in the world did you figure this out? I've seen this issue but didn't have a clue about the cause.

[silmalik]

Hi Calamity,

Oh, my job is really nothing compares to what you provide to all of us. Thanks to You. 

Well, some little work with Sysinternals Procmon has designated me the culprit: identify the reg key which stores the parameter, then identify the process who overwrites it.

This service is known to be the Catalyst hotkey poller, it was a surprise to see it messing up the configuration! 

I hope you will enjoy the mod.

[burn_654]

Great find Silmalik! I had to revert to the crt_emudriver built on the older Catalyst version for my card (5830) because I was seeing that problem (the 'hide modes' tickbox unticking itself) with way too many things. I thought maybe the driver just didn't like my card.

I'm looking forward to trying your Mednafen build soon here! I had really good experiences with Mednafen for pc engine/turbografx a while back...curious to see how well it works on the other consoles. Does real-time res switching during the game work as well? (I recall Military Madness for turbografx is a game that does this between battle animations)

[Guilt]

I got it working and I must say I'm very impressed! That startup logo looks so good now!
If I may be so bold as to field a request, I would ask for a config line that allows the resolution changes to go from superx240p to superx480i. That way minor changes (like pausing in SOTN) wouldn't cause any hiccup.
To muse further, I think that the hangtime during switches wouldn't bother me if there was some way of making sure the entire screen is black during transitions, instead of black and partially white.

I'm loving this.

[silmalik]

Thank you burn_654.
No res switching support for PCE/Supergrafx module for now, but it's on the plan.
I'm interested if you know other games that use different resolutions.

Guilt,
You are right about super resolutions. In the first, I wanted perfect rendering... on the easy way!    I will study their usage on later time.
I use Rocketlauncher, which has options to hide Windows elements, cursor, desktop and taskbar. The result is very clean, no visible graphic glitches.

I fact, switching resolution means destroy the Opengl rendering object and create a new one.
My understanding is that this process generates a short period during which nothing is displayed by the emulator, so, some parts of Windows shell appears.

Groovymame seems to have the same behavior. Not a problem because arcade games mostly use only one resolution.

In result, I'm not convinced that a clean solution can be integrated in the emulator rendering process. 
For now, a workaround would be using an external tool that do same job as Rocketlauncher to hide Windows . If exists.

Thank you all for the feedbacks.

[Recapnation]

For PCE games using high res modes, try Aoi Blink or Ys I - II. The latter does indeed use 256 x 224 for the cutscenes but switches to 336? x 224 for the actual game.

Even more useful -- run Burning Angels or 1943 Kai. You can change yourself the display mode in the option screen although the active area will be the same (black bars in the high res mode for mimicking a vertical arcade display). There are many other PCE shooting games that do this, but they'll require a code normally.

As I understand, any Mednafen GUI will do for your fork?

[Calamity]

Well, some little work with Sysinternals Procmon has designated me the culprit: identify the reg key which stores the parameter, then identify the process who overwrites it.

Very smart. I'll see if I can modify the drivers so this service is disabled by default, in case there's no side effect to it.

I fact, switching resolution means destroy the Opengl rendering object and create a new one.
My understanding is that this process generates a short period during which nothing is displayed by the emulator, so, some parts of Windows shell appears.

Groovymame seems to have the same behavior. Not a problem because arcade games mostly use only one resolution.

That's not true for Direct3D9Ex and up, where you can switch the full screen resolution without releasing the resources. Anyone has tested e.g. Megadrive's Sonic 2 in recent versions of GM? The progressive/interlaced mode change is absolutely seamless, at least on my machine, you only notice a slight warp on the background music (hopefully I'll figure out a way to avoid this too at some point). As far as I know OpenGL doesn't allow this, and wrapper APIs conceived to target both Direct3D and OpenGL implement a lower common denominator solution, making mode changes unnecesarily expensive.

[Guilt]

I've put online a Mednafen mod: emu4crt, which support native resolutions for a "perfect" rendering.
It supports, for now, Saturn, Psx, Snes and Nes cores, on Windows 64bits

I believe I have found a glitch! If I launch "emu4crt.exe ffviii\game.m3u" I get native resolutions, but if I launch "emu4crt.exe -which_medium 1 ffviii\game.m3u" I get the emulator putting out native resolution while my screen is set to the super wide resolution dictated in my mednafen config (2560x240). In other words, I get the top half of the ps1 boot screen smashed down into the left fifth of my screen! There seems not to be a way around this; the resolution changes don't effect my modeline changes if I use which_medium. I wonder if other unusual commands have any effect!

[silmalik]

Thank you Recapnation, those games seems perfect for test purpose.

As I understand, any Mednafen GUI will do for your fork?

Yes, it should work, keeping in mind that the fork has:
 - restricted module list (PSX, SS, SNES and NES)
 - limited video options (no shaders)
 - has a new option native_resolution that no GUI is able to manage

That's not true for Direct3D9Ex and up, where you can switch the full screen resolution without releasing the resources. Anyone has tested e.g. Megadrive's Sonic 2 in recent versions of GM? The progressive/interlaced mode change is absolutely seamless, at least on my machine, you only notice a slight warp on the background music (hopefully I'll figure out a way to avoid this too at some point). As far as I know OpenGL doesn't allow this, and wrapper APIs conceived to target both Direct3D and OpenGL implement a lower common denominator solution, making mode changes unnecesarily expensive.

Ok, good informations, thank you.
But I'm not, strictly speaking, a developper, and integrate a Direct3D9Ex rendering process in Mednafen is far beyond my competence.

[silmalik]

I believe I have found a glitch! If I launch "emu4crt.exe ffviii\game.m3u" I get native resolutions, but if I launch "emu4crt.exe -which_medium 1 ffviii\game.m3u" I get the emulator putting out native resolution while my screen is set to the super wide resolution dictated in my mednafen config (2560x240). In other words, I get the top half of the ps1 boot screen smashed down into the left fifth of my screen! There seems not to be a way around this; the resolution changes don't effect my modeline changes if I use which_medium. I wonder if other unusual commands have any effect!

The mod is very minimalistic, there is no reason why other options than videos should have been altered.

I don't reproduce the issue. I've tested the -which_medium option with different games and the resolution switched correctly.
Symptoms are like mednafen.exe is used instead of emu4crt.exe, if you are using a frontend, have a look to the settings.
I guess you are trying to launch FF8, which version in particular ? Could you attach the stdout.txt ?

[Guilt]

Inexplicably, its not happening anymore. Never mind I guess?

EDIT: Got RocketLauncher working and suddenly life is even better. Like you said, no graphical glitches anymore (save the transition from BIOS to game on PSX). This is so close to perfect. I envy you.

[silmalik]

Inexplicably, its not happening anymore. Never mind I guess?

EDIT: Got RocketLauncher working and suddenly life is even better. Like you said, no graphical glitches anymore (save the transition from BIOS to game on PSX). This is so close to perfect. I envy you.

RocketLauncher needs too much work to just use it as a workaround. It is based on Autohotkey scripts and maybe the interesting functionnalities can be exported to make a lighter solution.

Yes, PSX bios transition is faulty, it will be better in the next build.

[Guilt]

I wonder how receptive the mednafen devs would be if you asked them about including this in the main branch! That way we would never need to choose between compatibility updates and your fine work!

[silmalik]

I wonder how receptive the mednafen devs would be if you asked them about including this in the main branch! That way we would never need to choose between compatibility updates and your fine work!

This feature has already been asked to the Mednafen team, they didn't show interest to add it. I understand their choice, our usage is not very common.
About adding the mod to the official source... well, it works but it is done by an amateur. The overall thing should be improved by an experimented dev before showing it to the Mednafen team.

It won't be very difficult for anyone to integrate the modifications to futur source releases. The most difficult part is to get a working compilation environment.
By the way, I'm eager to test new Mednafen releases too, so, emu4crt mod will come shortly after. 

[silmalik]

Hi,

New revision of Mednafen mod emu4crt: https://github.com/emu4crt/files

PC engine support and PSX boot improvement.

[funkycochise]

Hi,
I did a quick test yesterday :
But what I get is a small picture (original famicom 256x240 resolution inside my desktop resolution (640x480i)



In black, of course, here's a recomposed picture for explanation purpose.

If I switch first my desktop to 256x240 using changeScreenResolution.exe tool, here's what I get :



Fullscreen 256x240 : What I what to achieve, great. But I thought that it would be done automatically, like groovymame.
So : do I need to do something to make emu4crt.exe to make the resolution switch.
I've provided the log file produced.

Thank you.

[silmalik]

Hi,

Thank you for the pictures and the (empty) log file.

I confirm that resolution should automatically be set to 254x240.

I have some questions:

- Did you test new version (A02) ?
- Is it the same with other modules,:snes, pc-engine ?
- Can you confirm that the setting is activated in mednafen-09x.cfg:
video.native_resolution 1

Thank you.

[funkycochise]

I don’t know what happened with the log file. I’ll fix that shortly.
I did the test with the earlier version. A01 ?
I only did test with famicom games.
How to specify whitch cfg file to use ?

[silmalik]

Like official builds, emu4crt use "mednafen-09x.cfg".
If it not exists, it will be created at first launch.

Notepad does not handle correctly the default file format, you can use notepad++ for example.

[funkycochise]

 video.native_resolution 1
did the trick

I need to remap key now, and will test your second build.
thanks a lot.

FKY

[funkycochise]

I did test A1 version for key remap.
I had to switch off the native résolution because
the text goes beyond the 256x240 limit. So it’s unreadable.
but I finally coule remap the nes/famicom to suit the jammasd.

I also test the A2 version for pce emulation.
It wirked well but had some problem for switching off native resolutions.
I had to copy the cfg from A1 version. I don’t know really why.
And then I could map keys for pce emulation.

Thanks for your help by the way.

[silmalik]

You're welcome, thank you for your feedback.

Yes, the currently mod has some side effects that impact standard display mode and OSD. I'm working on those points.
For now, an easy way is to use the official mednafen.exe for configuration.

[funkycochise]

Even if setting was the trickiest, once in 640x480,
GUI was readable. Configuration of mednafen is a bit strange,
as it repeat same input several times.

I’ll go ahead with testing.

[yuuyuubaishu]

I test the last A4 version and can not switch to Fullscreen mode，but the A2 is all right even with auto switch modeline（pretty good）。I wonder if   it’s the bug in A4……

[silmalik]

Hi,

You are right, it's a bad bug.

Version A05 fixes that: https://github.com/emu4crt/files/blob/master/mednafen-0.9.48-emu4crt-A05-win64.zip

[yuuyuubaishu]

Thanks for your great job! I have test A5 and  succeed.

in the meantime I did find some image get stuck extremely shortly ，I am sure the Vertical Refresh Rate generated by crt_emudriver cannot exactly match.

vmmaker generate 240P with 60hz,but groovymame can automatically adjust it to be suit for different consoles such as SS Refresh Rate 59.764793hz and NES 60.098800hz,you can get smooth image without any tear.

But when you run a NES game using emu4crt with 240P ,you have trouble updating the default  240P Vertical Refresh Rate, slight graphic intermission will occur throughout the whole process

And SNES Faust is not available

I am  sorry for my poor english.

[silmalik]

As explained in documentation, this mod does not generate specific modelines for emulated system, it uses video modes available, with no consideration about refresh rate.

To get "perfect" sync with emu4crt, you can configure VMMaker to generate accurate video modes for one system, emu4crt will use them.
But, you'll have to reset VMMaker when changing emulated system.

What are the benefits of the Faust SNES core ? I may have a look to it.

[retrorepair]

As explained in documentation, this mod does not generate specific modelines for emulated system, it uses video modes available, with no consideration about refresh rate.

To get "perfect" sync with emu4crt, you can configure VMMaker to generate accurate video modes for one system, emu4crt will use them.
But, you'll have to reset VMMaker when changing emulated system.

But doesn't VMMaker generate modelines with correct refresh rates for these systems already? Genuinely asking as it's been so long since I understood how it all worked!

It would be great if there was an alternative to mame for consoles with accurate video modes (and refreshes) because as good as it is for arcade systems even the most popular systems have major issues in MAME.

[silmalik]

Yes, VMMaker can generate all required resolution at every refresh rates, but Mednafen/emu4crt is not able to select a specific refresh rate.

Mednafen relies on the SDL library which does not expose method to do this, so it is not trivial to add such feature.

[Dacasks]

Whaaaaaa this is awesome.

Mednafen is the best all around console emu, imho (and I like to stay away from retroarch)

But maybe I'm missing something... I still get screen tearing. Doesn't it get rid of it? I manually created resolution with the exact refresh rate take from mame as reference for some consoles, but I still get some tearing... and yeah, the input lag is really noticeable. I don't wanna use Vsync because that ruins the purpose I guess...

[silmalik]

Well, I'm pretty sure that vsync will prevent any tearing.

About input lag, emu4crt should not be worse than the official build, and, just in case, the Mednafen Team gives some recommendations: https://mednafen.github.io/documentation/#Section_lag

[AstroFan]

Is it possible to build a Windows 32bit version?

[silmalik]

It should work, yes, without Saturn engine that is designed for win64.

I'll have a look to this on some days.

[keropi]

Is there a good GUI program to setup mednafen options like controls and paths ?

[alex2005]

Just playing around a bit with it,  im really happy that i can now play snes games at their original resolution.

I have been trying and seems like pal games switch to 31khz mode (or at least my screen is flickering).
i tried to replace the roms with the usa versions and most work fine then,  however there are some like dragon ball z, z2,z3 or illusion of time (spanish)  that do not have an equivalent Usa romset.

i imported the modes into vmmaker for pal and ntsc (for all systems allowed)  but still pal games seem to resist

is there any workaround i could use?  i was thinking of patching the roms,  but not sure all them are compatible with 60hz mode.

amd service is disabled and "hide desktop resolutions" marked

Thanks a lot!

[silmalik]

Is there a good GUI program to setup mednafen options like controls and paths ?

Yes, there are some UI, MedLaunch for example, that can help to define paths and some controls.
Controls can also be set up in-game (Shift+Alt+1 for player 1).

Just playing around a bit with it,  im really happy that i can now play snes games at their original resolution.

I have been trying and seems like pal games switch to 31khz mode (or at least my screen is flickering).
i tried to replace the roms with the usa versions and most work fine then,  however there are some like dragon ball z, z2,z3 or illusion of time (spanish)  that do not have an equivalent Usa romset.

i imported the modes into vmmaker for pal and ntsc (for all systems allowed)  but still pal games seem to resist

is there any workaround i could use?  i was thinking of patching the roms,  but not sure all them are compatible with 60hz mode.

amd service is disabled and "hide desktop resolutions" marked

Thanks a lot!

Could you launch a PAL game and post the generated stdout.txt log file, please ?

[alex2005]

Yes, here it is