About daily use of frame_delay & vsync_offset controls (a knobs vs auto thread)

[schmerzkaufen]

This is a question of course that has more to do with my particular case (flat panel user) but concerns the general use of frame_delay and vsync_offset, I think.

You've mentioned a few times the eventuality of making those adjust automatically, which sounds crazy complicated to me considering the variables.
I mean I use both every day and doing that manually for me it comes down to three things;

- adjusting frame_delay 1~9 (I use the slider)
- adjusting vsync_offset (I do that from specific INIs)
- turning the whole feature on/off because sometimes a rather heavy game can't take it and sticking to d3d9ex to minimize lag is the better choice

Thing is I also use various forms of scaling, smoothing, png effects, and HLSL depending on the game and what my computer's CPU+GPU can deal with.
Every time I change something I need to readjust frame_delay and vsync_offset, of course.

The good thing is I can always find correct settings, only vsync_offset is still a bit of a chore because I have to exit the emulator to edit and try different values in the ini.
An additional slider in the menu would make things much easier and faster, a live on/off switch as well although less essential would be convenient. The question of those settings then saving in CFGs or sticking to going back to write the values in the INIs after fiddling live is a debate, also since a high granularity is important for vsync_offset a slider could potentially be a pain if it's too slow (not sure just wondering in case).

Maybe a bit annoying detail; I've noticed that adjusting sliders from the ingame menus isn't ideal either because that OSD disturbs the whole thing''s stability while it's on, so you adjust but have to exit it and watch/play the game a bit to see the actual effects of your settings.
No big deal but it's just something to remember during the process.

In any case what I think, as a heavy user of frame_delay and vsync_offset, is that manual live control is a very valid fashion of using it (despite the little menu disturbance and leaving aside saving settings question for now).

I don't know what are your plans for frame_delay nor what they imply, there's too much I don't understand at my level, but as I said imagining this all automatic sounds insanely complicated, at least from my humble layman user perspective.
The other dimension of the topic would be the BGFX question, although this might a whole greater one.
Of course I'm only speaking as a D3D9ex user here, and totally satisfied with it, but maybe MAME are rejecting that solution, dunno.

[Calamity]

Making frame_delay automatic is possible in theory because we can accurately measure how long it takes to emulate an individual frame. The main problem is that it can be very variable for a given game depending on what's on screen, etc. The solution is to set frame delay to a low enough value that gives room for both fast and slow frames. This value would need to be found while running the game, so the first time you play a game you might experience some stutters until the correct stable value is found, and it would be used from then on. The more intelligent the algorithm is, the faster it'll get to the right value. If there are too big performance differences between levels of a game, you may be running a level at a suboptimal frame delay setting so you don't have issues when on the other level, etc. But anyway that's what happens when you do it manually.

Vsync offset value might be calculated automatically too based on the time it takes to render (gpu, not cpu) a frame. This is something I learnt with my experiments on the frame slice feature. I've been wanting to port this back to the frame delay implementation.

The idea is to have both sliders in the ui, and a separate setting to make both settings automatic or manual.

The main implementation problem is that enabling/disabling frame delay can't currently be done without restarting the video renderer. This makes it problematic to integrate it in the ui.

The reason for this is that frame delay uses a special form of video synchronization that is handled directly by GM, instead of the usual vsync based implemented in the renderer. So frame delay basically starts the renderer with vsync-off, and then implements vsync directly. The problem is, if you start GM without frame delay, then it automatically starts a renderer with vsync-on, which can't be turned off after that.

One solution that's been suggested is to separate the direct vsync implementation from the actual frame delay thing (I believe that's basically RA's "hard-gpu vsync" thing). This would be the ideal to make it available to all renderers (bgfx included). This is probably what will be done, by the way (e.g., new option -direct_vsync)

Problem 1: Frame delay will be dependent of that new option, it won't work if you forget enabling -direct_vsync. People don't read documentation so it will cause lots of problems.

Problem 2: Tearing on LCDs, vsync_offset required, always, even without frame_delay.

etc.

[schmerzkaufen]

Fantastic reply much clarifying the topic and situation for me, thanks Calamity. 

The need for vsync_offset to eliminate the tearing line isn't a problem when you use fixed processing in a fixed environment like the one I'm using right now, basically setting defaults in vertical.ini : frame_delay 5, vsync_offset 50, with filter 1 and prescale 2, covers like 90% of my vertical games folder without a hint of tearing.
Then I make specific ini's for the other 10% or any game/system I wish different settings for.

Of course this is absolutely not a solution for anyone who seeks the best off MAME/GM on his system. ^^

[cools]

I reckon you make it a commandline option that can be used alongside -bench (and maybe -writeconfig ?. Shame writeconfig does a huge dump of everything)

That way we could pre-calculate the optimal frame_delay in batch, rather than have to put up with games being stuttery.

(FWIW I don't touch frame_delay or vsync_offset precisely because they're per driver specific, and I find the difference between just using basic d3d9ex and a fully optimized frame_delay & vsync_offset configuration isn't great enough to warrant the effort configuring)

[Calamity]

D3D9ex's latency is already low enough for most people to even care about frame delay, which is good. I'd say that a joystick that is somewhat loose may have more relevant effect in practice. D3D9ex is a pretty old api however and we should focus on achieving the same results through bgfx.

The idea of automatic frame_delay is to make it unnecesary to use command line. Even if it's non-automatic, if only you could enable frame delay from the ui without having to set it globally in mame.ini, then find the right value from the slider, and it just got saved on exit, it wouldn't be that bad that it's a per system setting.

Rather than inis, the right way to save settings would be to use the cfg system.

[schmerzkaufen]

As you can surely guess I've never used command line *insert Psycho shower scene violons* for finding frame_delay values, and when you introduced the slider it became easy as pie to do that only de visu.

Agreed the CFGs are the most convenient for saving. At first I believed it was alright to use mostly system or source INIs because while experimenting it seemed that most games running on a same hardware have the same fd/os requirements, but that was when I was only looking at relatively old systems (up to mid-90's)

[cools]

BGFX being sorted would be great. Saving into .cfg is also great - I was thinking of a softly softly approach using the current methods rather than doing it the right way.

If automatic calculation became a thing, being able to p(re)calculate frame_delay in batch would still be my preference over having automatic calculation permanently enabled. I can see how having it on for first run then loading the settings if present would be good, but it'd be essential to have an easy way of recalculating (non-interactively!) without simply deleting .cfg files or doing a mass find-replace on them.

[Calamity]

To make things more funny, the cfg settings are applied *after* the osd has been initialized. So anything that's stored in there, will probably be applied late. Have you ever seen that if you rotate a game from the ui, then on next boot it first starts in the default orientation, and then it switches to rotated (two video mode switches)? It's just that.

[cools]

As you can surely guess I've never used command line *insert Psycho shower scene violons* for finding frame_delay values, and when you introduced the slider it became easy as pie to do that only de visu.

Nobody would, it's maximum tedium.

To make things more funny, the cfg settings are applied *after* the osd has been initialized. So anything that's stored in there, will probably be applied late. Have you ever seen that if you rotate a game from the ui, then on next boot it first starts in the default orientation, and then it switches to rotated (two video mode switches)? It's just that.

Hah, so if Volume were saved there and the game has a loud noise with power on - it'd still play

[jimmer]

Hah, so if Volume were saved there and the game has a loud noise with power on - it'd still play

That prompts a thought....  Does anyone know how you'd go about making the Master Volume sticky?  ie get it to save in default.cfg

[cools]

I've looked into it but I don't know how to fix it yet. Volume seems to be set by:

set_attenuation(machine.options().volume());

Whereas the mixer is set up by:

machine.configuration().config_register("mixer", config_load_delegate(&sound_manager::config_load, this), config_save_delegate(&sound_manager::config_save, this));

Meaning that volume is taken only from .ini but mixer (channel) props are from .cfg - which we know.

Haven't looked further, but mixer seems to be machine specific whereas volume is overall. It might require touching every driver to add the attentuation in as a configuration option.

[Calamity]

Older versions of GM used to save the calculated modeline into the game's cfg on exit. So similar code could be used. Not sure in what exact version this was removed (it was intended to be used in the future but future never came).

[jimmer]

Thanks cools,calamity.

Thought I'd mention it on the offchance it was easy, or in case it could be done along with the  framedelay slider save (if that becomes a thing). 

I'm hoping to get into the code over Xmas for my defender project, while I'm in there I'll keep my eyes open for this stuff.

[cools]

Thanks Calamity. The code to do so is in 15a at least.

// Register for configuration
+   config_register(machine, "switchres", config_saveload_delegate(FUNC(switchres_load), &machine), config_saveload_delegate(FUNC(switchres_save), &machine));

+//============================================================
+// switchres_load
+//============================================================
+
+static void switchres_load(running_machine &machine, int config_type, xml_data_node *parentnode)
+{
+   // We don't do anything here yet.
+}
+
+//============================================================
+// switchres_save
+//============================================================
+
+static void switchres_save(running_machine &machine, int config_type, xml_data_node *parentnode)
+{
+   modeline *mode = &machine.switchres.best_mode;
+   char modeline_txt[256]={'\x00'};
+
+   // only care about game-specific data
+   if (config_type != CONFIG_TYPE_GAME)
+      return;
+
+   xml_data_node *switchresnode = xml_add_child(parentnode, "switchres", NULL);
+   if (switchresnode != NULL)
+   {
+      if (mode && mode->htotal)
+      {
+         modeline_print(mode, modeline_txt, MS_PARAMS);
+         xml_set_attribute(switchresnode, "modeline", modeline_txt);
+      }
+   }

[Calamity]

So I took the plunge and have a preliminary implementation of the "save sliders" feature. Diff attached.

This works by exporting all UI slider states to the game's .cfg on exit, and reloading them on a later run.

This does NOT work for osd sliders (e.g. HLSL, BGFX,etc.). It can potentially be extended to those too.

Current support includes frame delay, volume, overclocking, etc.

I'd like to check if this breaks anything before considering to include it in GM.

Here's a temp link to a GroovyMAME arcade-only build for testing this.

[schmerzkaufen]

Wow! that's a bold one. Ima call you Santa. 

Count on me for testing this intensively asap and return any issues I would find (I'll take the opportunity to challenge the savestates along with this)

EDIT: note on the below; I think saving settings for HLSL and CRTgeom (including in BGFX) is planned for baseline MAME anyway.

This does NOT work for osd sliders (e.g. HLSL, BGFX,etc.). It can potentially be extended to those too.

[Calamity]

EDIT: note on the below; I think saving settings for HLSL and CRTgeom (including in BGFX) is planned for baseline MAME anyway.

That's good to know, I'd rather not mess with those.

[schmerzkaufen]

Been on it for about an hour and I haven't crashed anything yet    but I need much more time of course.

• blitter delay; isn't it kind of redundant if it saves this way since there is already an option in 'machine configuration' that saves the value? I don't know just wondering if one could maybe provoke a mistake/clash because of this.
  
• autofire; noted that one is not included, but it's not useful for for many games anyway, and quickly set again

This is like the build ever, you know. *crying*

[jimmer]

Thanks Calamity,

What do you want us to do?  Just test your groovy0204 binary ?   I saw the diff and started thinking what versions could I apply it to.


edit:

I just ran some quick tests:

FDslider works (saves, reloads)   

Master Volume saves, also in the game.cfg.    BUT this wasn't what I hoped for, there is already game specific sticky volume control.  I was hoping for  Master Volume to save to eg default.cfg  so that I can adjust the master volume while playing Defender and it will still apply when I swap to Robotron.    I can understand if this is a whole new level of problem.   It's probably best to revert this, as individual Master Volumes doesn't make sense.

[schmerzkaufen]

I've only played for like two hours but for now what I'm keeping an eye on is if for instance the saved CPU% actually triggers what's expected (some time ago I was using savestates since there was nothing else, and despite the slider saving the CPU% value, the OC did not apply in pratcice until it was 'touched' again)

For frame_delay since I don't want to turn it on by default for all games I am still using specific INIs in which I just write frame_delay 1, then adjust the level ingame via the slider menu, and it seems to save alright this way.
(I need the individual INIs for vsync_offset anyway)


@ jimmer: but you know several users actually lock the default.cfg in read_only state so they don't lose their main controller inputs layout when disconnecting a controller, so that would be a bad idea.
For people who use a custom cabinet where the controls are always attached there's no issues, but for everyone else disconnecting their stick/pad from the port after they're done playing this default.cfg not saving has been a PITA for a long time. MAMEdev refuse to change that because they blame windows and want to privilege the custom cabinet scenarios over the random/non-dedicated setups. They give an alternative fix no one besides rather skilled users would understand so for the general it's unpractical.

[haynor666]

So I took the plunge and have a preliminary implementation of the "save sliders" feature. Diff attached.

This works by exporting all UI slider states to the game's .cfg on exit, and reloading them on a later run.

This does NOT work for osd sliders (e.g. HLSL, BGFX,etc.). It can potentially be extended to those too.

Current support includes frame delay, volume, overclocking, etc.

I'd like to check if this breaks anything before considering to include it in GM.

Here's a temp link to a GroovyMAME arcade-only build for testing this.

I'll test this soon. Volume save will be very helpfull, thanks Calamity )

@ jimmer: but you know several users actually lock the default.cfg in read_only state so they don't lose their main controller inputs layout when disconnecting a controller, so that would be a bad idea.
For people who use a custom cabinet where the controls are always attached there's no issues, but for everyone else disconnecting their stick/pad from the port after they're done playing this default.cfg not saving has been a PITA for a long time. MAMEdev refuse to change that because they blame windows and want to privilege the custom cabinet scenarios over the random/non-dedicated setups. They give an alternative fix no one besides rather skilled users would understand so for the general it's unpractical.

Sadly we have to do this probably for long time.

[cools]

I 100% wouldn't want main volume saving into default.cfg. Levels are so inconsistent between games, I set mame.ini volume very low and crank it up when loading each game.

[schmerzkaufen]

For 2019 we'll need a thread dedicated to researching and sharing OC settings, there's a lot to look into. 

One thing I've noticed already is that HLSL seems to get in the way of that... so for now when I'm OCing I'm only using bilinear 1 w/ prescale 2.

--

Q about the blitter delay thing again; i still don't get if it's necessary or not to turn the feature on in 'machine configuration' prior to playing with the slider.
I'll probably figure it out after playtesting some more time anyway.

[donluca]

I 100% wouldn't want main volume saving into default.cfg. Levels are so inconsistent between games, I set mame.ini volume very low and crank it up when loading each game.

I believe it is saved on a per game basis to fix this exact problem.

[Calamity]

Yes, the idea is to save the volume setting per game so you can use your system's physical volume knob for a general setting and then use the software adjustment per game to compensate for the huge difference in levels between games.

With regards to the blitter delay thing, I have no idea, sorry. This feature just grabs the sliders and exports/imports them to the cfg file. Whether that creates any conflict with the blitter delay I don't know.

[haynor666]

I 100% wouldn't want main volume saving into default.cfg. Levels are so inconsistent between games, I set mame.ini volume very low and crank it up when loading each game.

I set up main volume to 0 then I run Gunbird 2 (very low volume) and set audio on my TV to my needs. After that I lowered (mostly) audio in some games to match desired sound without touching TV constrols. Lot of work but this will save hastle with sudden high audio when I'm playing at night when naturally my kids are sleeping.

[schmerzkaufen]

It seems Garou MOTW only requires a small underclock to fix the glitched animated background in terry's stage#3

If you move the slider while playing that stage it won't immediately work, the stage has to reload if you want to see the actual effect (let it time up for the extra round, this will work only once afaik otherwise exit and redo it).
My PC has issues right now so I was interrupted before I could dig more, but CPU 90% seemed to do the trick, not sure where's the exact threshold yet.
it being a 100% slider while the actual granularity is 1000 makes adjusting precisely ingame a bit difficult (you only see exactly what you have set when reading the game's .cfg)

[Calamity]

Thanks a lot to all testers.

I took the experiment a bit further and now frame delay can be enabled and disabled directly through the slider. Here is a test build.

So by using this build, finally one can avoid having to create individual inis. The suggested setup would be setting frame_delay 0 in mame.ini, then enable frame_delay just for the desired games, directly from the ui.

The setting will then be stored in the game's cfg, and remembered by MAME from then on.

This new implementation also has an important difference with the previous one: now instead of saving all sliders, only the ones that have been modified by the user are stored (i.e. the ones that differ from their default value).

This was required in order for this new full frame delay ui support to be consistent. So, the behaviour with frame delay is as follows:

- The frame delay slider is only saved if you change it from its 'default' value.
- By 'default' value, GM takes the one from the .ini files (remind the .ini priority hierarchy)
- E.g., if frame_delay=1 in mame.ini, the slider will show "1", and won't be saved unless you change it.
- If you change the default value, it'll be stored in the game's cfg.
- The slider has always higher priority than mame.ini. So once you have a saved frame delay value, it'll override whatever you put in mame.ini.
- The slider has always a lower priority than command line or game specific .ini. So you can always override the slider by manually forcing an -fd value.

EDIT: The slider will always have higher priority than command line or any .ini. It's done it this way to be coherent with the behaviour of the rest of sliders that do save currently in baseline (brightness, gamma, etc.).

So, if you already have some game specific .ini files, you can leave them and their values will be honored. But it's recommended to leave frame delay disabled in mame.ini (as it's always been).

[schmerzkaufen]

Wow wow wow! gonna test this asap. 

EDIT: confirming it works for me. 

So by using this build, finally one can avoid having to create individual inis

Well there's still vsync_offset    (but since you have grander design plans for the future 'automatization' of it let's not rush)

[haynor666]

Anyone tested how it works with savestates ?

[schmerzkaufen]

Too few times to tell you if the feature 100% fixed/safe yet.

But I'm dealing with making my system stable first, also I want to test savestates while using Portaudio which didn't seem to work properly for me before, so I want to check all that before going into a savestating orgy.

@Calamity: btw in 0.205 seems a little something was changed for savestates, no idea if it concerns Groovy.

--

Note: I've noticed that the typical 'Capcom 74% underclock' that has been active by default in the drivers of some CPS1/2/3? games for some time, isn't for SF2HF anymore.
The corresponding CPU value as seen in the .cfg of these games is 738 (appears as 74% in the sliders menu, just move the slider in little steps after you reach 74% then check the .cfg to make sure you got the same value)

[schmerzkaufen]

Okay so for Garou MOTW it's even less than I thought

CPU slider 98%  (cfg value = 983)

I've checked that it works even when the stage is reloaded for an extra match.

[Calamity]

I've noticed that the frame delay slider is not updating break scanlines properly. This needs to be fixed.

[schmerzkaufen]

Ack!

[Recapnation]

Nice stuff. Thanks, Calamity.

For 2019 we'll need a thread dedicated to researching and sharing OC settings, there's a lot to look into. 

Please, don't wait till next year. Your post regarding Garou belongs there. (I'm not starting it since I believe it's better if the first post could be edited with the time in order to list every game which is found out to improve its perceived emulation with CPU (and blitter delay?) tweaking, and I'm more a lurker than anything else here.)

[schmerzkaufen]

Please, don't wait till next year. Your post regarding Garou belongs there. (I'm not starting it since I believe it's better if the first post could be edited with the time in order to list every game which is found out to improve its perceived emulation with CPU (and blitter delay?) tweaking, and I'm more a lurker than anything else here.)

Ok probably this w-e.

[cools]

It seems Garou MOTW only requires a small underclock to fix the glitched animated background in terry's stage#3

If you move the slider while playing that stage it won't immediately work, the stage has to reload if you want to see the actual effect (let it time up for the extra round, this will work only once afaik otherwise exit and redo it).
My PC has issues right now so I was interrupted before I could dig more, but CPU 90% seemed to do the trick, not sure where's the exact threshold yet.
it being a 100% slider while the actual granularity is 1000 makes adjusting precisely ingame a bit difficult (you only see exactly what you have set when reading the game's .cfg)

Been a long time since I've had a MOTW cart, but is this glitch specific to the emulation or are you fixing a flaw found in the original hardware?

[haynor666]

Probably emulation bug - not emulated MC68xxx wait states, that's why they underclock CPU just like some CPS2 games have underclocked CPU by default.

[Recapnation]

https://mametesters.org/view.php?id=3954

Not "probably".

[schmerzkaufen]

Yes underclocking the CPU is often used to make up for emulation issues, issues often due to missing cpu wait states emulation or audio-related problems.
It's not fixing anything since it's not emulation coding but rather tweaking/hacking, though thanks to that some games can play better, and even finally become playable where they weren't in their current state.