4027 replies to this topic

[jpsalas]

Totally off the current subjects, but here's a request for VPX: an additional key/preference for Manual Ball lift and use "ManualBallLift" in the scripting to reference. Us old timer EM authors have plenty of tables with a manual ball lift and folks have different configurations and/or lack of buttons on their cabs so being able to set a key would be helpful for them.

 

Just a thought, I won't die if you don't include this

I used the Magna Save buttons. All cabs should have one Magna Save on each side. They also should have a buy in button, the one that's normally the "2" key.

[Segovia11]

Posted Today, 09:15 AM

 

loserman76, on 23 Jun 2020 - 4:26 PM, said:

Totally off the current subjects, but here's a request for VPX: an additional key/preference for Manual Ball lift and use "ManualBallLift" in the scripting to reference. Us old timer EM authors have plenty of tables with a manual ball lift and folks have different configurations and/or lack of buttons on their cabs so being able to set a key would be helpful for them.

 

Just a thought, I won't die if you don't include this 

 

Wish List 

 

It would be a great contribution if all button assignments were accessible through the script Editor, all button assignment conflicts could then be avoided. This would give the script writer a greater scope whilst scripting.

 

Thank You

Joseph Gofton       

[LynnInDenver]

One can see the image sizes (in memory) clearly in the image manager already. And i think if somebody downloads a 4k or 8k table MOD then that someone knows that this is not a lightweight table. 

I can (un)happily report that the latest UncleWilly build of Big Bang Bar crashes my VPX 10.6. Windows 10, AMD Ryzen 7 3700X 8-Core with 32GB of RAM, NVidia RTX2060, which should be absolutely no slouch especially given this system was built not six months ago, and it crashes out regardless of how I load it unless I tell VPX to treat me like I have a low end machine, at which point I can export and reimport his 27 plastics textures (21 are for one mirror animation in a very small area of the texture!) to reduce them down and get it to load properly without me having to tell VPX to treat my system as low end.

 

As much as we can see the file sizes in the image manager, there is a point where one needs to point it out, even if it's coloring the text red and making a note "these images may induce crashing on lower memory systems". Surely we've got some clue what the effective maximum size is before memory issues start breaking things.

[jpsalas]

 

One can see the image sizes (in memory) clearly in the image manager already. And i think if somebody downloads a 4k or 8k table MOD then that someone knows that this is not a lightweight table. 

I can (un)happily report that the latest UncleWilly build of Big Bang Bar crashes my VPX 10.6. Windows 10, AMD Ryzen 7 3700X 8-Core with 32GB of RAM, NVidia RTX2060, which should be absolutely no slouch especially given this system was built not six months ago, and it crashes out regardless of how I load it unless I tell VPX to treat me like I have a low end machine, at which point I can export and reimport his 27 plastics textures (21 are for one mirror animation in a very small area of the texture!) to reduce them down and get it to load properly without me having to tell VPX to treat my system as low end.

 

As much as we can see the file sizes in the image manager, there is a point where one needs to point it out, even if it's coloring the text red and making a note "these images may induce crashing on lower memory systems". Surely we've got some clue what the effective maximum size is before memory issues start breaking things.

 

 

But I don't think this is a VPX fault, but a table's fault (or the author's fault) to include so many big images which I mean it is quite pointless just now.

[LynnInDenver]

 

 

One can see the image sizes (in memory) clearly in the image manager already. And i think if somebody downloads a 4k or 8k table MOD then that someone knows that this is not a lightweight table. 

I can (un)happily report that the latest UncleWilly build of Big Bang Bar crashes my VPX 10.6. Windows 10, AMD Ryzen 7 3700X 8-Core with 32GB of RAM, NVidia RTX2060, which should be absolutely no slouch especially given this system was built not six months ago, and it crashes out regardless of how I load it unless I tell VPX to treat me like I have a low end machine, at which point I can export and reimport his 27 plastics textures (21 are for one mirror animation in a very small area of the texture!) to reduce them down and get it to load properly without me having to tell VPX to treat my system as low end.

 

As much as we can see the file sizes in the image manager, there is a point where one needs to point it out, even if it's coloring the text red and making a note "these images may induce crashing on lower memory systems". Surely we've got some clue what the effective maximum size is before memory issues start breaking things.

 

 

But I don't think this is a VPX fault, but a table's fault (or the author's fault) to include so many big images which I mean it is quite pointless just now.

 

Yeah, it's not the specific fault of VPX.

 

I'll probably just start keeping notes of who out there is designing only for their incredibly expensive top of the line system (add it to my horrible human being list that I keep for around here), and download and handle tables appropriately based on that information.

[Segovia11]

Dear VPX10.7 upgrade force,

                                                   Bug report :  VPX_7_rev4171 file.

                                                    

                                                   Copy Ctrl+C,Past Ctrl+V and Paste At Ctrl+Shift+V inoperative

                                                   Copy,paste and paste at function only available with mouse.

                                                 

                                                   Copy Ctrl+C,Past Ctrl+V and Paste At Ctrl+Shift+V worked in the previous revision (VPX_7_rev4154)

 

 

Thank you for dedicating your time to VPX10.7 Upgrade

 

ThankYou

Joseph Gofton      

[fuzzel]

Dear VPX10.7 upgrade force,
                                                   Bug report :  VPX_7_rev4171 file.
                                                    
                                                   Copy Ctrl+C,Past Ctrl+V and Paste At Ctrl+Shift+V inoperative
                                                   Copy,paste and paste at function only available with mouse.
                                                 
                                                   Copy Ctrl+C,Past Ctrl+V and Paste At Ctrl+Shift+V worked in the previous revision (VPX_7_rev4154)
 
 
Thank you for dedicating your time to VPX10.7 Upgrade
 
ThankYou
Joseph Gofton      

Known issue and already fixed with the next update.

[Robsoie]

About the image manager.

As i guess several people are doing to optimise the tables for their own convenience on their computer, i very often resize images to allow for vpx to load the tables faster without noticing visual big differences (as on my monitor current resolution there 's just no visual difference  betwee a 4096 texture for a bumper instead and a 1024 or 512 one by example, but it makes a noticable load time difference).

 

But there's always a problem, VP save the original texture path and every table developers has their own working texture directory path (or even drive letter) from which they imported, so after having reworked all the textures to what i want them to be, i am unable to use the "reimport" all of them at once as obviously i don't have the exact same working texture directory /drive letter as the table developers (vpx will then tell me it can't find the texture), and will then be forced to use the "Reimport From" that will only work for 1 texture at a time, and when there's a lots of them it takes time (without mentionning how easy it can be to reimport the wrong texture when their names are close )

 

Could there be a way to allow the user to batch replace all the "import path" section to the Image Manager into your own custom texture path, so you can make the "Reimport" function always work ?

Edited by Robsoie, 24 June 2020 - 02:37 PM.

[Segovia11]

Dear VPX10.7 upgrade force,

                                                   Bug report :  VPX_7_rev4171 file.

                                                    

                                                   1. Undo Function not working

                                                   

Thank you for dedicating your time to the VPX10.7 Upgrade

 

ThankYou

Joseph Gofton         

[The Loafer]

 

 

 

One can see the image sizes (in memory) clearly in the image manager already. And i think if somebody downloads a 4k or 8k table MOD then that someone knows that this is not a lightweight table. 

I can (un)happily report that the latest UncleWilly build of Big Bang Bar crashes my VPX 10.6. Windows 10, AMD Ryzen 7 3700X 8-Core with 32GB of RAM, NVidia RTX2060, which should be absolutely no slouch especially given this system was built not six months ago, and it crashes out regardless of how I load it unless I tell VPX to treat me like I have a low end machine, at which point I can export and reimport his 27 plastics textures (21 are for one mirror animation in a very small area of the texture!) to reduce them down and get it to load properly without me having to tell VPX to treat my system as low end.

 

As much as we can see the file sizes in the image manager, there is a point where one needs to point it out, even if it's coloring the text red and making a note "these images may induce crashing on lower memory systems". Surely we've got some clue what the effective maximum size is before memory issues start breaking things.

 

 

But I don't think this is a VPX fault, but a table's fault (or the author's fault) to include so many big images which I mean it is quite pointless just now.

 

Yeah, it's not the specific fault of VPX.

 

I'll probably just start keeping notes of who out there is designing only for their incredibly expensive top of the line system (add it to my horrible human being list that I keep for around here), and download and handle tables appropriately based on that information.

 

 

I get what you are saying but I think this is an unfair conclusion to what we are seeing with, for example, BBB.  I mean, a lot of these tables being developed aren't being tested on thousands of different devices like some AAA games.

 

How I personally judge authors as good human beings is by looking at their consistent contributions to our community, how they take constructive criticism and their willingness to make changes when it makes sense and finally their overall personality (are they consistently destructive and irresponsible with their comments?).  I think it's also wise to consider that the intent of releasing a table with ginormous textures isn't to make it playable to only a select few but rather to build tables with no compromises, basically future proofing the table.  Don't know if that's the case here but I could certainly see some authors doing that.

Edited by The Loafer, 24 June 2020 - 08:21 PM.

[LynnInDenver]

Yeah, talking with UncleWilly over on Vpinball, he's actually got a much weaker system than my desktop on all counts, so now I'm not sure what's up that's causing this issue. Clearly there's something else other than overall resources available going on, and it's a good question of where the problem is actually occurring, about the only thing we can point to is the animation texture for that mirror near the back, but that may be a need for optimization elsewhere. That said, we at least have the fix on it, so it's no longer a problem table.

 

Was anyone else trying to run other software at the time they tried the crashing version of the table, like Firefox or Thunderbird?

[Robsoie]

As i have been recently editing a lot of tables to my own convenience, i started to notice that in the File menu there is no limit to the "last opened tables" , so it can end with ridiculously long menu list

 

Can you implement a limit somehow (either only the 5 or 10 last opened tables) to solve this too long File menu display ?

[Rawnei]

Not VPX 10.7 specifically but stumbled upon a VPVR problem that is also related to VPX and the use of Visual Basic / COM so the problem should exist in both.

 

I've managed to push GPU frametime down quite a bit in VPVR which is now causing the rendering pipeline to fire off even more IDispatch invokes in EventProxy that Windows Defender is interfering with and thus causing a very high CPU frametime instead, an easy test is to disable Windows Defender Real-Time Protection and it's like night and day in frametime and performance but absolutely not a good permanent solution to disable antivirus.

 

So I'm trying to find workarounds for it, google is not helping and I am not too familiar with everything we do in Visual Basic so if you guys have any bright ideas they are all welcome.

 

Maybe some way of firing events without locking the rendering pipeline or somesuch?

[Robsoie]

On VPX i recently ran into a table ( the Stern 24 hours on Vpinball.com )  on which VPX had a 1 second long heavy stutter (freezing VPX visuals for 1 second) on a specific section right when the ball exit the launch ramp and goes to hit the 3 bumpers near the exit, a problem that strangely happened only once during a game , the first time the ball enter that section.

 

It was very odd because no setting change would fix that, i even reduced all the textures of the table by 50%  and optimised their png compression, but still it didn't changed anything (out of the table loading much faster obviously).

 

Then looking carefully at what could happen, i noticed that when the ball enter that section a very lot of lights are flashing all around the table at the same time, but as said the sutter only happen once during a game when the ball trigger this the first time.

To test if the problem was caused by the light show, i then edited the table script and started to remove a few lamps from the Sub UpdateLamps() section of the script, then played the table and noticed the stutter was a lot shorter, i removed more of those lamps in the script and managed to make the sttuter unnoticable.

 

A bit more curious, i decided to try the original VP9 version of the table (as from my understanding the VPX one is ported from it and adapted to VPX) and noticed that despite the same intense light show all around when the ball hit the 3 bumpers for the first time, the table never stutter.

I understand that the rendering engine of VPX is different from VP9 as VP9 using pictures for the lighting change.

 

So i am wondering if there's a problem of light/shadow map caching in VPX.

Something i suspect more after having played too a bunch of the recent SLAMT1LT tables on Future Pinball (and BAM), those tables have much more intense and busy light shows than any VPX tables i played, and they have 0 stuttering.

But the first time (happens only the first time as it's saved for future replay) Future Pinball (BAM) load a table it will takes a long time (much longer than Visual Pinball) to cache all the various shadow/light maps , resulting in the gameplay never stuttering when there's tons of lights flashing all around the table while the ball moves.

 

Could it be possible to code this kind of caching in VPX to fix the stutter situation on some very busy tables ?

Edited by Robsoie, 28 June 2020 - 10:59 AM.

[fuzzel]

We already did that in VPX. The render engine is completely different to VP9 or even FP (FP is using OpenGL). A lot of these caching logic is already done by the gfx driver.
The only chance to optimize that is to check if you have the latest driver or if a driver update made something worse lately. You didn't mentioned your gfx card but if that isn't a current version with a good amount of vram you should think about upgrading you system.

[Rawnei]

A lot of stutter can be caused by anti-virus since lights trigger eventproxy COM events thus triggering Microsoft AMSI which is stalling the whole pipeline. Microsoft AMSI is relatively new thing and it affects all anti virus software.

[ClarkKent]

Please add a hight value for the spinner to set the mounting height. And a better size control of the spinner plate.

[toxie]

As i have been recently editing a lot of tables to my own convenience, i started to notice that in the File menu there is no limit to the "last opened tables" , so it can end with ridiculously long menu list

 

Can you implement a limit somehow (either only the 5 or 10 last opened tables) to solve this too long File menu display ?

As i never experienced that (i.e. cannot repro/test): Hopefully the next version fixes this again.. Please let us know..

@Rawnei: Nice find, but no clue so far..

[fuzzel]

rev4194 is up:

 

- lots of internal cleanups

- fix recent table selection in the File-menu

- fix resource leak when quitting the table that can crash on some systems.

Edited by fuzzel, 05 July 2020 - 09:56 AM.

[kiwi]

rev4194 is up:

 

- fix recent table selection in the File-menu

To me, the list of recent ones gets longer every time I open a new table, going beyond the limit of 8 tables.

 

Thanks

Edited by kiwi, 05 July 2020 - 10:58 AM.