SwitchRes running in a browser

[yo1dog]

I thought this was kind of cool. I pulled all the SwitchRes C++ code for calculating the best video mode out of GroovyMAME 0.210, compiled it into WebAssembly with Emscripten, and got it running in a browser. Emscripten actually also allows you to transpile C++ into straight JavaScript but I assume WebAssembly is faster and the interface layers between the code is pretty much the same.

Here's a quick demo: https://yo1.dog/groovymame_0210_switchres/groovymame_0210_switchres.html

I was originally trying to rewrite the code in JavaScript but there are so many nuances like type concretion and integer division.

I am working on an opinionated tool to help newbies who care about native controls and video. Figuring out which kinds of CRTs and LCDs support native resolutions/refresh rates for which games, what compromises are available, and what the consequences are can be a daunting task (basically figuring out what will look and play "good"). I figured the work has already been done by the GroovyMAME team and using the exact same code would guarantee accuracy.

[Calamity]

This is simply AWESOME!!

Wow!

If instead of hardcoding a modelist you pass a dummy 1x1@1 mode it'll create the perfect mode right away, this is the way it works in Linux, you can do an online modeline generator this way.

[krick]

GroovyMAME 0.210, compiled it into WebAssembly with Emscripten

You probably already know this but baseline MAME has a Emscripten build target.  It's what the Internet Archive uses for their online emulation...
https://blog.archive.org/2018/09/21/over-1100-new-arcade-machines-added-to-the-internet-arcade/

[yo1dog]

This is simply AWESOME!!

Wow!

If instead of hardcoding a modelist you pass a dummy 1x1@1 mode it'll create the perfect mode right away, this is the way it works in Linux, you can do an online modeline generator this way.

Thanks! Good call. I found were that happens in switchres_sdl.cpp and replaced the hardcoded modelist with the the following:

Code: [Select]

modeline *mode = &machine.switchres.user_mode;
mode->width = mode->height = 1;
mode->refresh = 60;
mode->vfreq = mode->refresh;
mode->hactive = mode->vactive = 1;
mode->type = XYV_EDITABLE | XRANDR_TIMING | (machine.switchres.cs.desktop_rotated? MODE_ROTATED : MODE_OK);

I also updated the demo to allow you specify monitor attributes. https://yo1.dog/groovymame_0210_switchres/groovymame_0210_switchres.html

You probably already know this but baseline MAME has a Emscripten build target.  It's what the Internet Archive uses for their online emulation...
https://blog.archive.org/2018/09/21/over-1100-new-arcade-machines-added-to-the-internet-arcade/

I did not know that. Though, I figured someone had probably got MAME running in a browser given the existence of those tools.

[yo1dog]

Got a very early version of the tool running using the GroovyMAME SwitchRes modeline generator. Shows the emulation status as reported by MAME and an opinionated result for how well your monitor setup can display each game. Try changing the preset to something restrictive like ntsc, hit refresh, and notice how the results change.

https://yo1.dog/mameGenius/

Repo: https://github.com/yo1dog/mame-genius
I'm sure my C++ is terrible. First time touching it in 10 years or so.

Opinions are as follows and I'm sure they will need to be tweaked (can see in code form here):

• if game is out of range: unsupported
• if fractional stretching is required (R_RES_STRETCH): bad support
• if interlacing is required: bad support
• if vfreq is greater than default threashold of 2.0 (R_V_FREQ_OFF): ok support
• if xdiff, ydiff, and vdiff are all 0: native support
• otherwise: good support

There is a known bug regarding machines for which MAME does not output certain required display properties such as pixel clock, hstart, hend, etc. This results in the video status being "Unknown". I assume there is some way for me to calculate these values from known values like width, refresh, etc. but I have not looked into it much yet.

[Substring]

Using the "monitors database" here, this could mean the tool could show at which res/frequency the monitor would run specified games without people testing it ? Can be handy

edit : indeed what yo1dog did ^^

[yo1dog]

Just in case anyone is watching this, I fixed this bug:

There is a known bug regarding machines for which MAME does not output certain required display properties such as pixel clock, hstart, hend, etc. This results in the video status being "Unknown". I assume there is some way for me to calculate these values from known values like width, refresh, etc. but I have not looked into it much yet.

I was relying on the old style (oldstyle_vblank_supplied) which causes pixclock, hstart, hend, etc. being output by -listxml. The new style outputs width, height, and refresh, which is all we need for calculating modelines.

https://github.com/yo1dog/mame-genius/commit/63fc0738925fecb69e50bc06f866de0f861d463f#diff-7fe8aeacbab8c031ac3e6edd0579e0c5R65

[yo1dog]

A few more updates:

• UI tweaks
• Added the ability to specify multiple monitor configurations for comparing compatibility side-by-side
• Added state to the URL so configurations can easily be shared

Here's an example that compares the compatibility of a 31khz and 70khz PC monitor with a few games.
Example Link

It's probably time to create an actual thread for this project.

[Substring]

Would there eventually be a way to query your tool and get that useful json as a return ? This would be just great for any user tool.

[yo1dog]

Could certainly get a server and API up. Though it may be better to package the code as a library which can be included directly into apps/tools.

[Substring]

That's indeed what I said to myself too