Software Support > GroovyMAME

emu4crt Mednafen mod - update 1.26.1

<< < (2/76) > >>

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:

--- Quote from: silmalik ---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.

--- End quote ---

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.



--- Quote from: silmalik ---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.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version