Previous Thread
Next Thread
Print Thread
Page 1 of 2 1 2
Joined: May 2006
Posts: 130
F
Senior Member
OP Offline
Senior Member
F
Joined: May 2006
Posts: 130
This is as much for keeping track of what I'm finding as it is getting outside input.

There's definitely something weird going on with INI handling. -verbose doesn't actually trigger immediately from the command line like it should. If you actually disable the check in osdcore's osd_printf_verbose, you'll see that a large chunk of what's being sent is getting lost.

I've been developing a headache trying to track exactly how and why this is happening, so I decided to try backtracking to where I was previously and work on the tracking of INI/CFG parsing.

That, too, found some oddities.

I've added osd_printf_info lines next to each ini parse or controller parse just for proof of concept, and here's what I see:

C:\buildtools\src\mame>mame64.exe -seconds_to_run 10 sf2ceua
[Config] Parsing horizont.ini
[Config] Parsing arcade.ini
[Config] Parsing cps1.ini
[Config] Parsing sf2ceua.ini
[Config] Parsing horizont.ini
[Config] Parsing arcade.ini
[Config] Parsing cps1.ini
[Config] Parsing sf2ceua.ini
[Config] Parsing horizont.ini
[Config] Parsing arcade.ini
[Config] Parsing cps1.ini
[Config] Parsing sf2ceua.ini
[Controller] Parsing default.cfg
[Controller] Parsing sf2ceua.cfg
Average speed: 100.00% (9 seconds)

The process seems to be re-parsing through the entire set of INIs *twice*. From a quick glance, I _think_ it's parsing once through the CLI UI initialization, then a second time in the MAME emulation initialization. I don't know where the third would be coming from.

The deeper I get into the initialization and UI, the more convinced I get that I'm approaching the lair of the Old Ones and that I may have to abandon sanity.

Joined: Jul 2015
Posts: 97
Member
Offline
Member
Joined: Jul 2015
Posts: 97
Ok, i hope i dont hijack your thread Firehawke, if you think so, Admins feel free to move my reply to a own topic or delete it. Maybe its even better to post on MT, but i think it could belong to here.

I have some serious issues with the .cfg files, because they save info that is also stored in a .ini file. For example if you start Asteroids for the first time and you configure a brightness of lets say 1.3 in the core_screen_options of the .ini file and alter this brightness in game via the sliders, then the slider setting is saved in a .cfg file on exit. If you start Asteroids again, this .cfg file will overwrite your .ini setting for the brightness. IMHO this creates a conflict and should not be handled this way.

This brings me to my next point. MAME should save either all screen/HLSL/GLSL settings in .cfg file or none of these at all. From a users POV, individual created .ini settings on a per game basis are considered sacred. That is the main reason why many users dont want to update to newer MAME cores, as they would be losing those settings and they are not easy to re-create currently with MAME, as long as changes are involved. This is especially true for cases where you cant use global settings, that would cover most of the games (i.e. vector games, games that are demanding huge resources etc.).

I know that this is not a problem from a devs POV, but it would be fair, if we could do something at least to help 3rd party devs to create tools, that update those settings, if the MAME core is updated. IMHO the .ini files are missing important things to make such a tool possible, like i.e. a version info that could be read out by the tool, to adjust the settings properly to the version that a user wants to use.

A suggestion from Jezze, while we discussed it yesterday, was to make the .ini settings a .xml file, so that a xslt (Extensible Stylesheet Language Transformation) could be used, to "transform" the settings with the changes that come from a update, right out of the box. Also Haze came up with some nice ideas, like the one to keep screen settings, that also include shader settings, seperate from the .ini files to create screen-presets that would be choosed in a .ini setting. So we could cleanup the screen/shader parameters in a .ini file. which currently cover more than a half in a .ini setting. As the shaders are constantly improving at present, it is likely that the .ini will only have more parameters and not less.

Anyway, the intention of my post is, to involve as many as possible good ideas, how we could approach these "problems" that will occur in the future and to improve the handling of settings/configurations for the users. As this topic could be become very picky, especially for users and FE-devs, we should find a good solution for everyone that is also future-proof.


I live... I die... I live again.
Joined: May 2009
Posts: 1,890
Likes: 1
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,890
Likes: 1
Originally Posted By u-man
A suggestion from Jezze, while we discussed it yesterday, was to make the .ini settings a .xml file


Hahaha, that's literally never going to happen. That's an absolutely terrible idea. INI files are used specifically because they're plain text and can be edited by any random idiot user, and you want to make them XML? You're fucking joking, right?

Joined: Mar 2001
Posts: 16,655
Likes: 2
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,655
Likes: 2
Yeah, the specific point of ini files is that they're in the classic INI format.

If Jezze's code is saving settings to multiple files, he should fix it already.

Joined: Oct 2015
Posts: 26
J
Member
Offline
Member
J
Joined: Oct 2015
Posts: 26
My code isn't causing any problem with loading or saving settings from .ini or .cfg. I said I will take a look at the problem that is resetting the HLSL option when switching between windowed mode and fullscreen; which is also not my fault.

And I didn't made the suggestion to change the settings from .ini to .xml. We discussed the problematic of changes to the file format over several versions of MAME, and that it would be quite ease to create a transformation out-of-the-box with XML/XSLT.

Joined: Mar 2001
Posts: 16,655
Likes: 2
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,655
Likes: 2
Ok. We clearly need you to speak for yourself more often, because playing telephone with u-man doesn't work smile

Joined: Jul 2015
Posts: 97
Member
Offline
Member
Joined: Jul 2015
Posts: 97
First... the brightness, contrast, gamma are core_screen_options and therefore have nothing to do with HLSL or Jezze´s changes. Its a conflict created by the .cfg file which shouldnt save this stuff.

Second... the alt+enter fullscreen or window resize that resets the sliders, existed way before Jezze even started to look into HLSL. It is his good will, as he said he will look into this thing frown .

so neither of the two bugs, are a result of Jezze´s work.

... and the last thing is.. Its just a idea with the xml... if its bad for obvious reasons, lets find another one. The .ini files are still a thing, that is not update-able, except you do it manually, which is a pain in the ass, if you have about hundred files.


I live... I die... I live again.
Joined: Oct 2015
Posts: 26
J
Member
Offline
Member
J
Joined: Oct 2015
Posts: 26
It seem the history of the shout box is too short.

Joined: Mar 2001
Posts: 16,655
Likes: 2
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,655
Likes: 2
shoutbox is explicitly not for long-term planning, just short-term conversations smile

Joined: May 2006
Posts: 130
F
Senior Member
OP Offline
Senior Member
F
Joined: May 2006
Posts: 130
Wow, okay, apparently there's been a small explosion in here while I was looking in a completely different direction.

I don't mind the 'hijacking', it's vaguely related and I don't have any standing to complain (as opposed to RB and JD here, who are welcome to complain all they'd like)

I will return this to its' original course for JUST a moment, though, to say this:

I've given up on any core code hacking _for the moment_ on this particular line. This is going to require a deeper understanding of the systems than I currently have (and apparently most people are afraid to look into that particular abyss..) HOWEVER, my goals can still be achieved at the moment by working on documentation. To that end, I'm going to be emailing Micko shortly to ask a few questions on how he'd prefer I proceed therein.

Page 1 of 2 1 2

Link Copied to Clipboard
Who's Online Now
3 members (R. Belmont, Stick, Vas Crabb), 19 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,855
Posts116,550
Members4,934
Most Online890
Jan 17th, 2020
Forum hosted by www.retrogamesformac.com