Arcade OSD Modeline Edit

[MrMikeZH]

Why is it when you edit modelines in arcade osd,
the horizontal px change by 8px and the vertical by 1 px?
Or, how can you change the horizontal steps to 1px?

[Calamity]

Because video cards internally work with "characters" (8 pixels wide blocks) when it comes to crtc timing. Modelines allow single pixel steps, but internally these are rounded up to 8 multiples, so you don't get accurate results.

[MrMikeZH]

Thank you for the fast answer  .
I saw that if im in the dedicated hor/vert setting, vert is 1 line and hor is 1ch.
When i edit the line manually px by px ( outside of acrade osd of course), i can get
the picture centered up to 1px compared to the 4px subjective with osd.
So how is it possible to get is to 1px centered if the card rounds it up to the upper or lower 8px

[Calamity]

How are you editing the line and how are you applying it?

[MrMikeZH]

I copy it to clipboard and edit with editor (modelines.txt)
Then i uninstall modelines and import from edited file, then install modelines again with vmm.

[Calamity]

I copy it to clipboard and edit with editor (modelines.txt)
Then i uninstall modelines and import from edited file, then install modelines again with vmm.

If 1-pixel granularity is allowed now, it's certainly something new, it wasn't allowed in the past. Which card and driver version are you using?

[MrMikeZH]

Actually i was doing that since sailorsat released her soft15khz stuff ( wonder if you started because that happening or something else advancemame or arcadevga).
Back then i was using all sorts of 4000 cards mostly 4650, now im using a 7570m and fire m4000/7700m series.
Driver is 16.2.1 non gcn.
Btw how can i insert my own edid with atom15?

[Calamity]

It's not that I inherited this belief from someone else. I did a lot of testing back in the day and the numbers showed that the adjustment only made a difference by jumps of 8 pixels. I assumed this was a legacy feature based on how the crtc worked in the old days of VGA. There's now fundamental reason why now it couldn't work on a 1-pixel basis. I need to try it.

[MrMikeZH]

I hope you can confirm that its possible with 1px basis.
Thank you so much calamity.


Edit; just tested again, manually its min 1px max 1px off center or perfect. Arcade osd its min 4px max 7px off center or perfect.

[MrMikeZH]

Im trying as good as i can to have the picture centered with the modeline generator.
Is it because everything works on 8px basis for horizontal or why does the generator change
the marked values which should not have any impact on the refresh, or do they?
Also i dont know if it has been asked already, but how is the generator setting the pxclock so exact
 and why cant we specify it as exact by hand/will?

Thanks

Edit:
When i specify the generated modeline in the ini the refresh goes a little off, i just dont get it.
Is the perfect smoothness/delay dependent on 100% exact refresh?

[Calamity]

The whole Vmmaker -> GroovyMAME stack is designed to work with 8-pixel-wide blocks. When this was a limiting factor (assuming it's not anymore, which I still need to test) it was required to do this otherwise the timing calculations would be wrong.

With regads to the dotclock, internally it's rounded to 2 decimal figures, just like in Arcade OSD. My original implementation showed the dotclock already rounded to be coherent with the underlaying reality. However Doozer insisted to leave the decimal figures in there in case the Linux implementation would take benefit of that. I doubt it was a good thing.

[Doozer]

The whole Vmmaker -> GroovyMAME stack is designed to work with 8-pixel-wide blocks. When this was a limiting factor (assuming it's not anymore, which I still need to test) it was required to do this otherwise the timing calculations would be wrong.

With regads to the dotclock, internally it's rounded to 2 decimal figures, just like in Arcade OSD. My original implementation showed the dotclock already rounded to be coherent with the underlaying reality. However Doozer insisted to leave the decimal figures in there in case the Linux implementation would take benefit of that. I doubt it was a good thing.

I am not so picky ;-) OK, I assume we can get rid of the extra digit. The 0.001% diff won't make so much difference in the final result ;-) Graphic card registers are not yet using float numbers.

[MrMikeZH]

Ok, so if the clock is rounded to 2 decimal figures anyway, the exact refresh isnt matched always right?
So the showed dotclock is just show?   

by luck since the 2 decimal figures are round i was able to install the modeline directly which is exactly the mame neo geo timing lol ,and correct centering in my case which always dont affect refresh.
"304x240_60 15.625000KHz 59.185608Hz" 6.250000 304 319 351 400 240 244 248 264 -hsync v-sync

now if i only specify the resolution in the game.ini, no specific modeline and generator off, the picture is correctly centered and with the correct refresh. (correct one installed in windows)
as soon as i enable the generator the centering (without suplied modeline in ini) or refresh goes off (with the correct modeline set in the game.ini)
its funny how switchres takes the already perfect timing and alters it to no more perfect.

so the question is now, if the decimals get rounded is it necessary to have it fake perfect for perfect expirience, smoothness/delay?

the neo geo timing is wrong anyway in mame, the correct timing is described in the neo geo dev manuals like this:
modeline 'NeoGeo' 6.0000 320 326.75 356.25 384 224 240 248 264 -hsync -vsync
Edit: sorry its the same refresh in the end so mame is correct 

so when we look at the snk data which has decimal figures and also unevan numbers if the decimals get rounded, we still get the correct refresh from the card.
so if you update switch res to support 0.25 dot steps (1dot anyway), it should not return wrong refreshes regardless from more testing, is that logical???

edit2:

ok upon that situation with the decimal figures from snk i tried 0.5 dot steps, and yes the shifting is now even finer (one horizontal shift in the tv menu instead of 2),
didnt try 0.25, should i? 
i tried 12 steps 1dot and 6 0.5dot, all were the same. new modeline then button press on tv and so on.

[MrMikeZH]

Wow, guys i hope you dont get me wrong here, just got to read whats happening in the other thread.
Im not about to criticise anything here, just wish to have a perfect tool for realtime modeline manipulation,
i wasted like years for editing txt and installing modelines instead of realtime. powerstrip was never an option aosd is way better like it is,
only the 8dot steps...

so doozer was the coder of switchres right? chris kennedy?
please guys consider to update it with 1px steps.


thanks and cheers

[Doozer]

so doozer was the coder of switchres right? chris kennedy?

I am not the coder of switchres, just a humble contributor. I did the libdrm implementation for the Linux side to remove the system("xrandr ...") calls. All the rest was already in place thanks to Calamity

[Substring]

I am not the coder of switchres, just a humble contributor. I did the libdrm implementation for the Linux side to remove the system("xrandr ...") calls. All the rest was already in place thanks to Calamity

libdrm or librandr ? could there be a way to just go straight DRM and drop X ?

[Calamity]

libdrm or librandr ? could there be a way to just go straight DRM and drop X ?

Yes, that's the next target. See why we're going to need plenty of devs?

[Doozer]

I am not the coder of switchres, just a humble contributor. I did the libdrm implementation for the Linux side to remove the system("xrandr ...") calls. All the rest was already in place thanks to Calamity

libdrm or librandr ? could there be a way to just go straight DRM and drop X ?

libxrandr uses libdrm calls (shortcut, indeed Xrenderer and the xf86 driver talk to the kernel module, but I do not want to do a conference explaining the relationship here). Today with X, libxrandr but in a new future when wayland will be here libdrm (or other) would be required.

Note: perhaps SDL2(3) will have a way to set the refresh rate and this would become an old story ;-)

[MrMikeZH]

So who started writing stwitchres? 
Calamity, many times you said that you arent a coder.

btw, i just testet to edit also the vertical figures by 0.5lines (translates to timing since there is no half line),
and it works as well  . after all these years 
it was always possible to have a perfect realtime modeline manipuation tool, but it hasnt surfaced yet.

[Calamity]

btw, i just testet to edit also the vertical figures by 0.5lines (translates to timing since there is no half line),
and it works as well  . after all these years 
it was always possible to have a perfect realtime modeline manipuation tool, but it hasnt surfaced yet.

How are you entering non integer values? All the internal structures in the driver work with integers, so I highly doubt it's working.

[Calamity]

BTW, 1-pixel granularity working here too!! This is great! 

[MrMikeZH]

How are you entering non integer values? All the internal structures in the driver work with integers, so I highly doubt it's working.

just like this "384x240_60 15.77KHz 59.72Hz" 7.93 384 402.5 442.5 504 240 243.5 251 264 -hsync -vsync

i can take a video to show the picture shifting 50% less with 243 -> 243.5  instead of 243 ->244
also these 0.5px/dot/line shifts, shift the picture exactly the same amount like the service menu does, so no need to have it any finer.

how is there a stable constant difference when giving non integer values to the driver if the driver cant accept them???

can you also maybe once more clearify whats going on with the half refresh interlace modes.
im trying to migrate everything to windows 10 finally and i cant get any interlace mode to be in in 60hz vsync,
who knows why but never had to deal with that on 7 or xp, just remember you telling to stick to xp back then because of that problem occuring with 7
and with cards before 5000 which mine isnt. I also never had the situation with pre 5000 cards on xp and 7, first time i experience this now.