Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news


  

Author Topic: About daily use of frame_delay & vsync_offset controls (a knobs vs auto thread)  (Read 242 times)

0 Members and 1 Guest are viewing this topic.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 199
  • I want a large cream coffee
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

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6149
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.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 199
  • I want a large cream coffee
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 573
  • Arcade Otaku sysadmin...
    • Arcade Otaku
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)
Please don't PM me with support questions. Ask in public so everyone can learn!

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6149
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.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 199
  • I want a large cream coffee
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 573
  • Arcade Otaku sysadmin...
    • Arcade Otaku
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.
Please don't PM me with support questions. Ask in public so everyone can learn!

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6149
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.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Online Online
  • Posts: 573
  • Arcade Otaku sysadmin...
    • Arcade Otaku
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 :)
Please don't PM me with support questions. Ask in public so everyone can learn!

  
 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31