2087 replies to this topic

[The Loafer]

Out of respect for the site owner (Noah) could we please skip the discussions related to SAM tables? I know this makes things a little harder but it is his site after all.

Thanks

Rob

[jimmyfingers]

I believe I know why things are not looking correctly on the Airborne table and the WCS '94 table.  Both the graphic issues indeed appear to be ordering related / ordering graphic issue type problems.  I think I have found a bug in the DX9 VP builds since the new ordering by height has been added that seems to not work correctly with alpha ramps that do not have the Additive Alpha option selected (regular transparent ramps / not flasher type objects).

 

I have seen this demonstrated very clearly on my GI8 MOD of Indianapolis 500 where the top flashers were causing very obvious ordering issues since VP9_DX9_test3.exe where they would wipe-out the transparent ramp graphic next to them even though their height should have precluded them from this issue (confirmed the drawing order manually set also still matches what should have happened with the new auto-by-height style).  Interesting enough, I resolved the issue by simply selecting the Additive Alpha option for the flasher(s) involved and then the ordering of the objects around it then worked fine and the lower object (transparent / plastic ramp) now appeared successfully.  This "fix" was / would be fine for I500 as I would be updating it anyway with flashers with AA but not all ramps are going to be able to set that and some for sure do not want that enabled just like found in the two examples of Airborne and WCS '94.  

 

So, Mukuste, here is a link to the table that you can test / verify with (just load it up with the latest build and when you run it you'll immediately see the issue with the top 3 flashers when running the flasher and lamp diagnostics from the in game ROM / DMD menu method, rerun after selecting them all in the editor and changing the type to additive alpha and the ordering problem goes away):

http://www.vpforums....s&showfile=6871

 

Here are some screen shots of the one top right blue flasher (tucked under the race car toy platform) where you can see the differences:

 

Where it's working in VP9_DX9_test2:

 Caputre of I500 with flashers fine using VP9_DX9_test2.png   1.22MB   19 downloads

 

Where it's not working in VP9_DX9_test5a:

 Caputre of I500 with flasher ordering graphic issue using VP9_DX9_test5a.png   1.31MB   21 downloads

 

Where with Additive alpha set it's working in VP9_DX9_test5a:

 Caputre of I500 with flasher ordering graphic issue fixed by AA setting using VP9_DX9_test5a.png   1.32MB   21 downloads

Edited by jimmyfingers, 24 February 2014 - 01:40 AM.

[bent98]

Thanks jimmy for your detailed explanations.

[pincade]

it's a dream come true for me,

latest 5a version works like a charm!! and disabling AA activating fxaa the image is perfect

 

obviously I've got some problem but almost all the tables is perfect now, only Funhouse night mod has a Rudy paralized with closed eyes and mouth.

at the moment no "pure black" problem.but the ball doesn't reflect on the pf (even in old 9.2.1)

[DJRobX]

I played most of my tables with test 5a over the weekend.    The vast majority of them are perfect or near perfect.    It's really amazing! 

 

Aside from the layer order, a common problem I'm seeing is the ball is being cut in half when it's in a saucer.    I can see this was fixed for some tables, but it's still an issue in a lot of others.    Elvira and the Party Monsters FS is the first table that jumps to mind.

 

Rudy works just fine in the Funhouse daytime version.  I got my best score ever playing in DX9!

Edited by DJRobX, 24 February 2014 - 04:54 AM.

[koadic]

In the night mod of funhouse, Rudy is made from gates using the .visible property (as I had modified it for personal use before the .alpha property was in use and then aaron created the night mod from it). I had thought this might have been fixed though because I did Homer the same way (along with the mini dmd) on Daytime FS mod of TSPP that UW uploaded and it had been reported that issue was fixed.

Edited by koadic, 24 February 2014 - 05:40 AM.

[ClarkKent]

as for the key problems: can you guys confirm that this does -not- happen with a 9.2.1 version of VP? or with the DX9 tech beta1?

cause then it would be direct input 8 related.

It does definitely not happen with 9.2.1 and also not until rev922. It seems that it occured first with the DX9 version.

 

It does not have anything to do with dB2S as I tried tables without dB2S and they also do not exit. No single table exit here on my cabinet. But as I said - only when it's in play mode. As soon as I press the ESC key on the keyboard, all keys are working perfect. If I resume in the player the keys are not working again.

Edited by ClarkKent, 24 February 2014 - 06:47 AM.

[toxie]

so could you please retry with tech beta 1, too, please?

or did you also try that one and it already doesn't work there?

[ClarkKent]

so could you please retry with tech beta 1, too, please?

or did you also try that one and it already doesn't work there?

Just tested beta1 - exiting works perfect there! In all tables I tried and at all times. I just installed test5 after that again - and keys aren't working again...

Just tested the new The Getaway table and noticed microstutter and framedrop to 55 while multiball (vsync on). Weired. With DX9 is should be fast enough.

 

One request: Could you make the vsync option switchable by key (F-key?). This would be the fastest way to test tables with and without vsync.

[toxie]

that's odd.. so it might really be direct input 8.. :/

[ScubaMichael]

Ok so after redownloading the 5 different tests, I still can't get version 4 and 5 working at all. 

 

I get error,"d3dx9_43.dll" when loading test 4 and 5.

 

Any ideas?

[mukuste]

Download and install DirectX 9.

http://www.microsoft...ails.aspx?id=35

Edited by mukuste, 24 February 2014 - 07:36 AM.

[ScubaMichael]

Mukuste....Getting a directX "Internal system error occurred" upon install.....and it quits....

[mukuste]

Huh. That's weird. Try right-clicking the installer and "Run as administrator".

 

If that doesn't help, read http://answers.micro...bc-7d3f4cec61cf

[ScubaMichael]

Mukuste......got it.....had to run in safe mode to load.....Thanks

[mukuste]

I believe I know why things are not looking correctly on the Airborne table and the WCS '94 table.  Both the graphic issues indeed appear to be ordering related / ordering graphic issue type problems.  I think I have found a bug in the DX9 VP builds since the new ordering by height has been added that seems to not work correctly with alpha ramps that do not have the Additive Alpha option selected (regular transparent ramps / not flasher type objects).

[...]

 

Thanks JF for your detailed analysis. Here are two points to hopefully make things even clearer for you:

 

(1) Since Test4, alpha ramps which are set to additive blending do not write to the depth buffer anymore. For anyone not familiar with the concept of depth buffering, you may read up on it here. This means that, even if an additive alpha ramp is wrongly rendered before another, lower element, it still won't block out that lower element from rendering. This is why setting the ramp to additive fixed your issue.

 

(2) Also between Test3 and Test4, there was a change to the way the depth of alpha ramps is determined for the purpose of depth sorting. In Test3, it was only based on height, as you assumed. In Test4, it instead first computes a central point for the whole ramp in 3D space, and it takes into account not only height, but the actual depth in the scene with respect to the viewing direction. This improves the sorting in some cases, but can also make it worse in others. Especially for large, curvy ramps like the one in your table, having a single central point is a very rough approximation to the actual position of the ramp, so artifacts like this one can occur.

 

As I said before, the automatic depth sorting at this point is basically a band aid for some rendering issues. In particular, it is needed to prop up the crucial fix for fading lights (I explained before) since that depends on the engine having free rein over the draw order. It will stay in the VP9-DX9 version, though it's up to debate whether it will stay in VP10. With some improvements, I think it could perform very well and be a huge boon for table authors as they don't have to worry about any draw order issues themselves anymore. In addition, as I said, we do really need automatic sorting if we ever want to have a fully dynamic camera viewpoint since a fixed draw order only works for a fixed viewpoint.

Edited by mukuste, 24 February 2014 - 08:26 AM.

[toxie]

that's odd.. so it might really be direct input 8.. :/

 

i just commited a 'fix' for the keyboard issue that might help, so please try again with the next tech beta..

[frans]

Sorry but, where are the download link for test 5a?

Thanks.

[BananaBoat]

Some more testing tonight and some interesting results.

firstly, it's important to reboot your PC after you install DX9. A lot of issues my lag and screen tear issues disappeared. Exit from hyperpin using using 'e' key now works without issue also.

secondly, I noticed that VPin was crashing on random games. In VPin directly, I would load up tables at random , play them to test then quit.
I found that after testing 4 or 5 tables VP would crash upon loading the next table, no matter what it was.
error: HRESULT 8007000e at RenderDevice.cpp:448

Interestingly I noticed that VP was not closing the tables, ie 4 or 5 tables remained open in VP!!! So I then loaded and tested a table, exit, then close, then open the next table. this helped A LOT! crashes were now far and few in between, but they still occured.

to further confuse matters, I wouldn't get these errors by launching a game in hyperpin, and I think it's because HPin closes the instance of VPin altogether when you exit a table, or it doesn't use VPin directly???

Hopefully this is enough info to help you gurus out!

Finally, when I launched one of the tables that were not suppoosed to mention, the one that starts with an X, I got HRESULT 8007000e at ...cpp:263

Doesn't happen all the time, just at random. Also the other table were not supposed to talk about, the one with large blue semi-naked people crashes most of the time.

long winded but hopefully useful
thanks!

Sent from my HTC_PN071 using Tapatalk
 

Edited by BananaBoat, 24 February 2014 - 11:39 AM.

[mukuste]

Some more testing tonight and some interesting results.

firstly, it's important to reboot your PC after you install DX9. A lot of issues my lag and screen tear issues dissapeared.

secondly, I noticed that VPin was crashing on random games. In VPin directly, I would load up tables at random , play them to test then quit.
I found that after testing 4 or 5 tables VP would crash upon loading the next table, no matter what it was.
error: HRESULT 8007000e at RenderDevice.cpp:448

Interestingly I noticed that VP was not closing the tables, ie 4 or 5 tables remained open in VP!!! So I then loaded and tested a table, exit, then close, then open the next table. this helped A LOT! crashes were now far and few in between, but they still occured.

to further confuse matters, I wouldn't get these errors by launching a game in hyperpin, and I think it's because HPin closes the instance of VPin altogether when you exit a table, or it doesn't use VPin directly???
 

 

You definitely have to close the tables after opening and playing them. VP has a MDI interface, meaning that it can have several tables open in several windows, and the memory usage will definitely pile up if you keep them all open. The error 8007000e that you got means "out of memory". I do not think this is different from mainline VP9, however. Your assumption that HPin closes the vpinball.exe process after each game is true, so there it's no issue.