5? to 60hz source modification in 0.146

[Stormrider]

Hi. With MAME 0.135 I could change all games to 60hz with these modifications:

-----

In src\emu\video.h change

MDRV_DEVICE_CONFIG_DATA64(screen_config, refresh, HZ_TO_ATTOSECONDS(_pixclock) * (_htotal) * (_vtotal)) \

with

MDRV_DEVICE_CONFIG_DATA64(screen_config, refresh, HZ_TO_ATTOSECONDS((((HZ_TO_ATTOSECONDS(_pixclock)) * (_htotal) * (_vtotal))>= 50) ? 60 : ((HZ_TO_ATTOSECONDS(_pixclock)) * (_htotal) * (_vtotal)))) \

and

MDRV_DEVICE_CONFIG_DATA64(screen_config, refresh, HZ_TO_ATTOSECONDS(_rate))

with

MDRV_DEVICE_CONFIG_DATA64(screen_config, refresh, HZ_TO_ATTOSECONDS(((_rate)>= 50) ? 60 : (_rate)))

-----

Now I've noticed that MAME 0.146's source is different. I've tried this change:

-----

In screen.c change

screen.m_refresh = HZ_TO_ATTOSECONDS(pixclock) * htotal * vtotal;

with

screen.m_refresh = HZ_TO_ATTOSECONDS(60);

-----

However, suprisingly this only affects some games, while others are still working at their original refresh rates. For instance, Hammering Harry goes to 60hz, but not Mortal Kombat or ESPRADE.

Can you help me modify the source correctly so as to have ALL games running at 60hz with MAME 0.146. Thankyou.

[Gray_Area]

You may get a response here, but you'll undoubtedly get a response, and quickly, at MAMEWorld.

[Haze]

FWIW this is about the most dangerous patch you can apply globally to MAME.  Anything relying on exact timing will break, anything pushing the emulated CPU will end up with exagerated slowdowns because you're asking the CPU to do 60 updates per second instead of 50 (or whatever) CPU sync details will change because your interleave levels end up different (due to different amounts being done per frame)  Sound sync will also break as timed music won't last the same length as the scenes it was designed to be played against, furthermore if games have their own independent timer systems the game logic can end up at the wrong speed, which can result in AI not behaving properly etc. etc.  Games which are uber sensitive / badly coded might even just end up crashing at random points.

Making such changes is basically screaming 'please break everything and leave me wondering why'

The problems might be subtle and non-obvious but messing with exact and measured timings (which are usually the ones which AREN'T 60) is just asking for trouble, big trouble.

If people insist on doing this all the time I'm going to start coding all my drivers to just error out instantly if they detect the rate has been tampered with, to avoid more serious potential issues later.

[Howard_Casto]

I don't understand why people want to do this anyway. 

It reminds me of those vga boxes they used to sell for game consoles a few years ago....  yeah it outputs vga... of your 480i optimized game with a low poly count and textures the size of a postage stamp.  But no more jaggies so it was totally worth it right?  Right?

[Stormrider]

I don't care about any problems that might arise from doing this. I've been compiling my MAME with all games at 60hz since years now. It's for my own use, of course.

[Haze]

I don't care about any problems that might arise from doing this. I've been compiling my MAME with all games at 60hz since years now. It's for my own use, of course.

Well it's still a _very_ stupid thing to do.  People shouldn't be doing this, let alone posting code mods to do so which some people might unwittingly see as improvements.

As newer MAMEs become more dependant on exact screen timings (the very reason it becomes harder to do this) then it becomes even *more* important, as they're likely to be running all sorts of other logic based on an assumed original refresh rate you're hacking.

It's like driving your brand new car into a tree on purpose and claiming you do it because you like the damage and it fits in your garage more easily.

[Calamity]

Hi Stormrider,

You could use the option -speed to achieve the same thing without hacking MAME itself:

mame romname -speed factor

where factor is  60 / original_speed, with two decimal figures.

However, you'd need to code some sort of script to efficiently generate the inis for this using MAME's XML info.

[Stormrider]

Wow, Calamity I had never heard of that option before. Has it been implemented lately? I've tried it and it works. Moreover, it looks like the sound doesn't get distorted. Have you noticed any drawbacks in using it? I think I can figure out how to do the scripts for my inis.

Y ahora en cristiano, que supongo que eres el de estos lares, no? Bueno, vamos a investigar el tema, que tengo al pobre MAME abandonado y hay que dejarlo como debe ser. Gracias, amigo.

[abispac]

I hate when someones asking for something in particular, and instead of helping, some moron comes and tell the guys its a stupid idea, then after the guy whos seeking for help  left clear his been doing the same for years, the moron comes back again stating the same, "stupid idea" 
if you dont have somenthing nice to say, just leave'it like that... please 

[Haze]

I hate when someones asking for something in particular, and instead of helping, some moron comes and tell the guys its a stupid idea, then after the guy whos seeking for help  left clear his been doing the same for years, the moron comes back again stating the same, "stupid idea" 
if you dont have somenthing nice to say, just leave'it like that... please 

Except it's not 'some moron' saying it's a stupid idea, it's the dev(s) of the project he's talking about, who know exactly how it works, who are absolutely horrified at what a bad idea it is and are sick of people applying it and then reporting that things are broken failing to mention they applied this braindead STUPID patch.  Just because he's being doing it for years doesn't make it any better.

to paraphrase, if you don't have safe hacks to apply to the project, please just leave it like it is, thanks.

Believe it or not we put a lot of time and effort into making sure things work properly, and are correctly measured / balanced, so to have one sweeping critical core level hack destroy *ALL* of that for *ALL* drivers, is terrible.

[Calamity]

Wow, Calamity I had never heard of that option before. Has it been implemented lately? I've tried it and it works. Moreover, it looks like the sound doesn't get distorted. Have you noticed any drawbacks in using it? I think I can figure out how to do the scripts for my inis.

Y ahora en cristiano, que supongo que eres el de estos lares, no? Bueno, vamos a investigar el tema, que tengo al pobre MAME abandonado y hay que dejarlo como debe ser. Gracias, amigo.

No drawbacks that I know of. This option has been in MAME for some years at least. GroovyMame benefits from this mechanism internally to keep the audio synced by adjusting emulation speed to the achieved refresh rate, although usually just one tenth of Hz up or down is required.

Saludos