ArcadeItalia.NET

Calamity ha scritto:

Kernel ha scritto: There are differences between "Switchres arcade monitor modeline generator and mame wrapper" and this method: http://postback.geedorah.com/foros/viewtopic.php?id=1424 ?

Both methods use similar modeline generation routines. But with VMMaker a static mode list is used, so a carefully selected mode list is needed to cover most situations, and mantaining a heavy ini folder so that each rom is assigned to the right video mode. You can modify VMMaker setup to get a different mode list + inis, but in order to see the results you need to reboot. That's why we say it's static. In a way it's the same method used by Soft-15Khz, in fact it's inspired on that program and Winmodelines, but with a built-in modeline generator that allows the automatization of the process. So with Soft-15Khz you would mantain a custom resolution list in a text file to feed the program with it, with VMMaker the list would be done for you extracting the needed info from Mame.xml. Another important feature is that VMMaker is intended to be used with my hacked Catalyst drivers (CRT_Emudriver), that allow more than a hundred video modes simultaneously, while normal Catalyst only admits 60. On the other hand VMMaker was still (is) on an experimental stage when I joined this thread, so it was limited to fixed-sync arcade monitors. And the dynamic modelines method I was testing would never be added to VMMaker, but to Switchres instead, as it is a much more ambitious project.

Switchres, under Windows, uses a dynamic mode list. That means that modelines can be recalculated on the fly right before launching Mame. So in way, you can see Switchres as the return of AdvanceMame. The method has its own limitations and we are working to get the best of it, but in practice it means you can have infinite modelines under Windows XP. Consider the variety of video modes derived from the resolution, i.e. 320x240. You have it in 50, 60, 57.55 Hz, etc. etc. Normally, you would have to store each of those video modes as a separate modeline. Now, you only have to store an instance of each resolution, say 320x240. All variety of needed vertical refreshes will be calculated out of 320x240 dummy resolution by Switchres.

Calamity ha scritto:

Kernel ha scritto: In the past I've used Triple buffer with no throttle (and soundsync). Smooth scorlling, no stuttering at any resolution/Hz, but It caused heavy input lag.
Now I use only throttle+sync to monitor refresh (and always audiosync). All is fine and I have no input lag but I have to use a resolution with less Hz than the game (e.g. on 60Hz game I have to use 59.7 Hz), otherwise I get some spot accelerations.
What can I get with that new feature?

The input lag issue is a tricky subject. Many people are reporting input lag with triplebuffer, however I have never noticed it myself. I honestly can't see any difference even when using Shmupmame, but that could be because I'm not such a hardcore gamer and my eye is not trained on that. The joysticks on my cab are not the best ones for shmups either. I tended to believe people were having input lag because of choppyness introduced by their lousy setups when enabling triplebuffer with video modes far from correct. But this indeed deserves a deeper study.

What the new patch does is to enable vsync without page flipping (syncfresh vs triplebuffer), and still be able to turn throttle off. So you won't need to use a video mode with less Hz any more to avoid hiccups, by only enabling syncrefresh without triplebuffer/throttle. I would appreciate you tested this and tell us if you still have input lag or not, as I'm not the best one for determining that for the reasons I explained above.

Kernel ha scritto:Confermo:
E' un'evoluzione del sistema già citato. SwitchRes consente di generare le modelines in automatico, un po' come accadeva con AdvanceMame.
Questo è quanto mi ha detto Calamity nell'altro forum:

Come avrai notato ne stiamo discutendo proprio con Calmity nell'altro thread.