4027 replies to this topic

[SmedleyB]

Would it make sense to consider or is it possible for the Display resolution and refresh rate selection to become a table-level option? We are in a state where there are many resource-intensive tables running alongside lower-resource tables and mid-tier hardware has some trouble keeping up.
Personally, I find the smoothest movement w/ gsync enabled in my driver settings and vsync enabled via VPX with FPS Limiter set to 1. I have a 165hz gsync monitor and there are plenty of tables that I can run at 165hz with smooth ball movement with no tearing or stutters. But more and more new tables are getting stutters at 165hz, however they run great at 120hz. I'd love the option to set my graphics driver / Windows at 165hz system-wide and then and be able to tell VPX to lower that refresh rate for certain tables.

[wiesshund]

Would it make sense to consider or is it possible for the Display resolution and refresh rate selection to become a table-level option? We are in a state where there are many resource-intensive tables running alongside lower-resource tables and mid-tier hardware has some trouble keeping up.
Personally, I find the smoothest movement w/ gsync enabled in my driver settings and vsync enabled via VPX with FPS Limiter set to 1. I have a 165hz gsync monitor and there are plenty of tables that I can run at 165hz with smooth ball movement with no tearing or stutters. But more and more new tables are getting stutters at 165hz, however they run great at 120hz. I'd love the option to set my graphics driver / Windows at 165hz system-wide and then and be able to tell VPX to lower that refresh rate for certain tables.

 

I would suggest syncing monitor at 120Hz if that is the lowest common denominator
as gsync slides back and forth, it changes flipper latency/timining

Personally i doubt i would know the difference, but people who are actually good at pinball will notice it.

 

No idea if the table script can presently ask vpx to change it's resolution choice, though i suppose it could.

[SmedleyB]

 

Would it make sense to consider or is it possible for the Display resolution and refresh rate selection to become a table-level option? We are in a state where there are many resource-intensive tables running alongside lower-resource tables and mid-tier hardware has some trouble keeping up.
Personally, I find the smoothest movement w/ gsync enabled in my driver settings and vsync enabled via VPX with FPS Limiter set to 1. I have a 165hz gsync monitor and there are plenty of tables that I can run at 165hz with smooth ball movement with no tearing or stutters. But more and more new tables are getting stutters at 165hz, however they run great at 120hz. I'd love the option to set my graphics driver / Windows at 165hz system-wide and then and be able to tell VPX to lower that refresh rate for certain tables.

 

I would suggest syncing monitor at 120Hz if that is the lowest common denominator
as gsync slides back and forth, it changes flipper latency/timining

Personally i doubt i would know the difference, but people who are actually good at pinball will notice it.

 

No idea if the table script can presently ask vpx to change it's resolution choice, though i suppose it could.

 

 

Yup, I do generally run w/ nvidia/windows set to 120 and VPX Display resolution set to 120. I'm ok with latency changes if FPS dips and gsync does its thing. Add that to the list of differences across tables like physics and the ways different authors do things. I'm starting to play more so only a few tables are focused on each week, so it's not like I'm hopping from table to table and getting my shots all screwed up due to latency differences. They were already screwed up to begin with  

[wiesshund]

 

 

Would it make sense to consider or is it possible for the Display resolution and refresh rate selection to become a table-level option? We are in a state where there are many resource-intensive tables running alongside lower-resource tables and mid-tier hardware has some trouble keeping up.
Personally, I find the smoothest movement w/ gsync enabled in my driver settings and vsync enabled via VPX with FPS Limiter set to 1. I have a 165hz gsync monitor and there are plenty of tables that I can run at 165hz with smooth ball movement with no tearing or stutters. But more and more new tables are getting stutters at 165hz, however they run great at 120hz. I'd love the option to set my graphics driver / Windows at 165hz system-wide and then and be able to tell VPX to lower that refresh rate for certain tables.

 

I would suggest syncing monitor at 120Hz if that is the lowest common denominator
as gsync slides back and forth, it changes flipper latency/timining

Personally i doubt i would know the difference, but people who are actually good at pinball will notice it.

 

No idea if the table script can presently ask vpx to change it's resolution choice, though i suppose it could.

 

 

Yup, I do generally run w/ nvidia/windows set to 120 and VPX Display resolution set to 120. I'm ok with latency changes if FPS dips and gsync does its thing. Add that to the list of differences across tables like physics and the ways different authors do things. I'm starting to play more so only a few tables are focused on each week, so it's not like I'm hopping from table to table and getting my shots all screwed up due to latency differences. They were already screwed up to begin with

 

 

Changing from table A to Table B is ok (unless table B is really fubar)

its when table A changes to table B to table C to wtf is this and back in mid game on table A                     

 

Now me personally?
I dont play well enough to know unless it delves into the range of WTF is this????
But some of these guys would not only notice, they'd drag you outside and saw off your tweeter

[SmedleyB]

But by lowering my refresh rate for a given table, aren't I preventing gsync from having to do anything (outside the odd fps dip)? I have done many tests and changing the refresh rate via vpx produces much more consistently smooth motion than capping FPS via VPX on my machine.

[wiesshund]

But by lowering my refresh rate for a given table, aren't I preventing gsync from having to do anything (outside the odd fps dip)? I have done many tests and changing the refresh rate via vpx produces much more consistently smooth motion than capping FPS via VPX on my machine.

 

Correct
gsync wont need to do anything (better to let the odd frame dip just happen)
and using vsync instead of a hard fps cap ensures that it draws frames exactly when the monitor is ready to draw a frame
an fps cap is not necessarily synced, vpx either hard caps or syncs but not both

[SmedleyB]

Actually I'm seeing a fair number of tables that don't respect the Vpx refresh rate override. The table switches to the Vpx refresh setting for a second when the table loads, or at least it looks like it's trying because the screen goes black, but then black screen again and back to windows/Nvidia defined refresh. I don't see what the common denominator is on these tables, though.

[Rawd]

Hi Toxie...

 

Would it be possible to add the ability for VPX to 'remember' the collection that an object belongs to on copy/paste from table to table?   This would be very helpful with room transplants where things are coded for collections. (I'm sure helpful in other scenarios also)

Edited by Rawd, 12 January 2023 - 06:38 PM.

[Mike DA Spike]

@toxie

 

Sorry to put this in this thread, but didn't know how to get the right words and made an issue on github.

I was still on 10.8.0 rev 603 and upgraded to rev 712 for Vpinballx_GL

 

I noticed that some tables (like T"ee'd Off (Gottlieb 1993) 2.0.3.vpx" and "VR ROOM Fish Tales (Williams 1992) VR v1.2.3.vpx") has some weird light effects in the latest release , that I didn't experience with rev 603

 

 

I hope you understand what I try to say and that this can be fixed 

[wiesshund]

@toxie

 

Sorry to put this in this thread, but didn't know how to get the right words and made an issue on github.

I was still on 10.8.0 rev 603 and upgraded to rev 712 for Vpinballx_GL

 

I noticed that some tables (like T"ee'd Off (Gottlieb 1993) 2.0.3.vpx" and "VR ROOM Fish Tales (Williams 1992) VR v1.2.3.vpx") has some weird light effects in the latest release , that I didn't experience with rev 603

 

 

 

 

I hope you understand what I try to say and that this can be fixed 

 

cant really tell what your showing in the pics?
post pics in the 2 diff versions maybe, showing same thing?

 

have you tried build 713?

 

You are better off posting to github
10.8 is not in official beta yet, so vbousquet is probably not going to monitor the 10.7 beta thread
but he will see it posted on github

 

schrijf op deze manier, lees dat we kunnen?

[Rawd]

@toxie

 

Sorry to put this in this thread, but didn't know how to get the right words and made an issue on github.

I was still on 10.8.0 rev 603 and upgraded to rev 712 for Vpinballx_GL

 

I noticed that some tables (like T"ee'd Off (Gottlieb 1993) 2.0.3.vpx" and "VR ROOM Fish Tales (Williams 1992) VR v1.2.3.vpx") has some weird light effects in the latest release , that I didn't experience with rev 603

 

 

 

I am also seeing this in GLBeta v712 on this table.  I haven't seen it on other tables yet.  As mentioned above, the best place for 10.8GL beta bug reports is probably at Github.

[Mike DA Spike]

I will make an issue on github and will check other tables as well. I know Fish tales has the same issue.
Didn't check rev 713 yet as 712 was the latest at that moment.

Not sure what you mean with the last sentence @Wiesshund. It must be something in my language, but don't get it ..

[steelballz]

EDIT: moved original post to the flexdmd thread as it seems better suited there.

 

https://www.vpforums...=41#entry512776

 

one issue i'm having with 10.8 is the VR keybinds always reset to blank when i restart vpx

Edited by steelballz, 19 January 2023 - 06:04 PM.

[xenonph]

I am getting alot of people reporting an error that should not be happening with my tables.

Here is the error message.

 

Runtime error
-------------
Line: 1
Object doesn't support this property or method: 'Controller.ROMName'

 

The problem is, there is no ROMName script command in these tables.

(My NFL Mods and Christmas Pinball are the only ones that use the ROMName command.)

All of the rest of my mods do not use the ROMName command, but they do use NVOffset command.

 

Is the NVOffset command tied to this ROMName command?

Because that is the error they all seem to be getting, even with no ROMName command in the table script.

And to get rid of the error, they either have to update their Backglass Server Program, or Delete the NVOffset command that I have added to all my mods.

 

Seems kind of strange that they can delete the NVOffset command in script, and the ROMName error goes away.

 

Thanks for all the work put into this program!

It is appreciated!

[wiesshund]

they are using an outdated version of B2S Server with an updated VpinMAME

that is the issue

 

see change log regarding ROM aliasing

[xenonph]

So for the people who were getting this error on the NFL mods when I first updated them to VPX6, (Which does have the ROMName command in script) when the core.vbs was updated to use ROMName command, they had to update to newest B2S Server, as it was found the ROMName function needed to be added to the Backglass Server Program.

This is what I was told by a Dev, and what I passed on to anyone getting this error on my NFL mods.

 

I remember you mentioning this before Weisshund, and I remember thinking this is not what I was told by Dev.

Then I got to thinking after receiving message this morning that someone was getting ROMname error, that Hey I never used the ROMName command on these other mods, so why are they getting a ROMName error?

Which is why I just posted the question here today,

 

So now it is the updated PinMAME used without the newest B2S server program that causes this error with tables just using the NVOffset command?

Good to know!

The one thing I have told everyone consistantly that experienced this error now and back then, is to update to newest Backglass Server.

But I also explained it was from having an updated core.vbs without the new Backglass Server program.

Now I know to tell them it is the updated PinMAME without newest Backglass Server program that causes this error.

And knowing is half the battle!!

 

Thanks again my friends!!

Carry on.

[allknowing2012]

What determines the order of the results in the Layers window? I filter on Bumper and it returns

Bumper02

Bumper03

Bumper01

 

All from the same layer.  10.7.3

[Violins77]

When using VR in 10.8.0, I noticed the image is slightly blurrier than when using 10.6. I don't know if it is currently known or worked on, I saw a post back in October about it. Should I report it on Github?

[Mike DA Spike]

When using VR in 10.8.0, I noticed the image is slightly blurrier than when using 10.6. I don't know if it is currently known or worked on, I saw a post back in October about it. Should I report it on Github?

Yes please, as I understand from Toxie, all issues should be reported on Github

[RYSr]

When using VR in 10.8.0, I noticed the image is slightly blurrier than when using 10.6. I don't know if it is currently known or worked on, I saw a post back in October about it. Should I report it on Github?

Gear323 on Github reported - Suspect that there is an issue with Supersampling in later revisions of VPXVR #199, back in Nov 29,2022. I have been suspicious of the lower quality for some time now. I though it was my aging eyes or possibly my headset. But I found that as he suggests, if you use Steam to control the Super Sampling and leave VPVR set at 100% there is an noticeable improvement in quality. I added a comment to his post. Perhaps if you do the same or even create an new bug report it would help. I havn't ran nersion 10.6 in some time I will have to go back an try it and see if I get the same result as you. This may have been broken for some time now!