2087 replies to this topic

[htamas]

Oops forgot one:   Hook playfield still goes black with the game is started.

 

I'm using a version that's one prior to the latest and reduced textures to just full HD plus made sure sizes are a power of 2 and then I don't have this issue anymore, so this problem is related to this one specific table.

Unfortunately even with DX9, I still have some slight micro-stutter so I pretty much gave up on this table to play well on my hardware until at some point in time, perhaps a newly built version will surface.

This is the only table so far where I still see this micro-stutter with DX9...

[gtxjoe]

I created a simple form entry for the VP DX9 Compatibility tracking using Google docs.   The intention is to use this to track DX9 issues but also track Tables that are DX9 compatible (no table update required).  Lastly - the form also has a link to the overall tracking spreadsheet so you can view the results.  

 

Here is the link: https://docs.google....EPwri8/viewform

 

1) Please test the entry form.  Submit real issues or just do a test (Add Test to the table name) entry

2) See if you can edit your entry.  Intention is that you can modify it after re-testing with new SW release

3) View the tracking sheet.  You should be able to view it, but not modify it directly

 

 

Feedback welcome.  

[bent98]

I created a simple form entry for the VP DX9 Compatibility tracking using Google docs.   The intention is to use this to track DX9 issues but also track Tables that are DX9 compatible (no table update required).  Lastly - the form also has a link to the overall tracking spreadsheet so you can view the results.  

 

Here is the link: https://docs.google....EPwri8/viewform

 

1) Please test the entry form.  Submit real issues or just do a test (Add Test to the table name) entry

2) See if you can edit your entry.  Intention is that you can modify it after re-testing with new SW release

3) View the tracking sheet.  You should be able to view it, but not modify it directly

 

 

Feedback welcome.  

 

This is great. Can you please add fields for OS/Graphics card and driver version/pinmame dll/resolution played at ?

Edited by bent98, 26 February 2014 - 07:59 PM.

[bent98]

Thanks I see you added those fields.

[mukuste]

 

I still don't get then why the examples above are fine then.  Whether it's internal / tranparent to the table author or not, the net effect - in the examples above at least - are that there is no issue with that light object / image at table surface 0.  Does it work in some cases and not others for some reason or when there are more objects on the table?  Even if that's the case, it can't be a global / general / all the time thing in at least the test table above shows no issues regardless of lights at 0 with the playfield surface.

 

 

 

The Z-buffer is a finicky beast,  it behaves in a very nonlinear way (precision is much higher close to the camera) and it's often difficult to predict what exactly it will do. If you load up Seawitch in that older build, you will see that it has blacked out lights due to this issue. To be honest I don't exactly understand why, I thought 16 bits should be easily sufficient.

[toxie]

sidenote: i just brought the changes made by the unity pinball team to VPM into the VPM trunk, next will be the cabinet related changes made by destruk. after that we can 'officially' use the extensions made by them in VP, too (soundcard selection and fast DMD/solenoids/lamps grab).

 

cabinet branch was also created. same goes for PinDMD.

 

expect a combined .dll (which allows for all of that to be en/disabled via menu) soon for you guys to test.

[DJRobX]

I created a simple form entry for the VP DX9 Compatibility tracking using Google docs.   The intention is to use this to track DX9 issues but also track Tables that are DX9 compatible (no table update required).  Lastly - the form also has a link to the overall tracking spreadsheet so you can view the results.  

 

Here is the link: https://docs.google....EPwri8/viewform

 

1) Please test the entry form.  Submit real issues or just do a test (Add Test to the table name) entry

2) See if you can edit your entry.  Intention is that you can modify it after re-testing with new SW release

3) View the tracking sheet.  You should be able to view it, but not modify it directly

 

 

Feedback welcome.  

 

You have choices for "Needs to be solved by table author" "Solved by table author".    I'm wondering if these can be worded a little differently.   If the solution is as simple as changing the transparent color setting on an image, I'd rather just see something like "Solvable with the following changes", with instructions in the comments.   Then the table author can hopefully implement it in a future revision, but your repository holds the solutions for anybody who wants to fix it (making it easier for table authors, as they don't have to re-invent the wheel!)

Edited by DJRobX, 26 February 2014 - 11:12 PM.

[mukuste]

With some further tweaking I managed to find a set of depth bias values which seems to work well on the few problematic tables I tested, including JF's new test. I'm still kind of unhappy because I don't quite understand the reasons for these troubles, but at least it's a fix for now.

[LoadedWeapon]

Sounds great! One question.. On STTNG table the latest flasher mod everything looks perfect except when the ball goes up the ramps and thru the wire gate it makes a black square. Any clue what i need to change to fix it? posted a photo of where it happens but cant get a pic of it cause it happens so fast  Thanks for all the great work! it's so close now

 00StarTrek_NGNM.png   1.46MB   20 downloads

Well not sure what it is but if i put in a clear image for the back image of the spinner it fixes it... there is no image atm

Edited by LoadedWeapon, 27 February 2014 - 12:50 AM.

[gtxjoe]

DX9 table compatibility form updated based on comments so far. Thanks for input.

 

- I will see if there is if the google docs publish feature allows you to present the database nicely, rather than the raw spreadsheet.

- It looks like google restricts the ability to allow submitters to modify their entries, so I will manually update as needed. PM me if you are interested in moderating it also.  (I will investigate further)

 

Also, if someone wants to develop something more sophisticated we can migrate to that tool instead.  I can always find something VP related to work on - Right now I am using this thread as a way to avoid working in Photoshop on my next table

 

Hopefully, there will be little need for this database

Edited by gtxjoe, 27 February 2014 - 12:36 AM.

[jimmyfingers]

With some further tweaking I managed to find a set of depth bias values which seems to work well on the few problematic tables I tested, including JF's new test. I'm still kind of unhappy because I don't quite understand the reasons for these troubles, but at least it's a fix for now.

I found the core issue with the two tables that apparently predicated the changes with this depth bias aspect in the first place (between version test5a and test6) that has lead to all the new issues with near table level walls, ramps, and lights residing on either of them (.1-1.2 range).  Both Seawitch and Blackout FS versions were about 4 years old and had no FOV / layback settings.  I could resolve the inserts / lights issues on both in just a matter of seconds using the previous build (test5a), in which the errors were initially reported, by opening the table and simply entering a value for the FOV moving it from zero to something non-zero.  A value of .2 fixed the issues with both tables and yielded no change in it's appearance otherwise.  

 

This is an extremely simple fix that instead has lead to changes in the code, from only two tables with reported issues that are 4 years old, now affecting dozens if not hundreds of more current tables.  With all due respect, I strongly suggest that the previous method / depth bias levels from test5a be re-instated with these new findings and extremely simple work-arounds available plus the shere math of 2 tables vs. possibly 200 or more with issues just outweighs the latest problematic changes.  This 0 level FOV field is probably a key culprit in the varying results and peculiarities you were experiencing.  However, FS views vs. desktop views do still differ in the nuances for the issues arising but that's also likely because of the differing FOV values from desktop vs. FS at least / especially with older tables that never even used the FOV field and had a 0 value.  Even with whatever depth bias settings / changes you have found now / tonight, they should not need to be used as the old issues do not need to be compensated for any more with such a basic table level fix for these two isolated / old tables and the fully working / no uncertainty aspects of test5a's depth bias system would seem better to be used at this point.

 

Furthermore and for added benefit both tables in question have no layback settings / view being so old and can look a lot better as well as also still resolving the issue if a complete layback style view is configured.  For Seawitch my quick configuration of fix + layback was as seen in this screen shot yielding the table view below it (note the light inserts are working / visible and screen shot was made in verion test5a):

 Capture of Seawitch FS View Settings with Layback and VP9_DX9_test5a Inserts (Table Lights) Fix.PNG   4.6KB   15 downloads

 Capture of Seawitch Fixed with Layback Settings.PNG   1.34MB   15 downloads

 

For Blackout my quick configuration of fix + layback was as seen in this screen shot yielding the table view below it  (note the light inserts are working / visible and screen shot was made in verion test5a):

 Capture of Blackout FS View Settings with Layback and VP9_DX9_test5a Inserts (Table Lights) Fix.PNG   4.59KB   15 downloads

 Capture of Blackout Fixed with Layback Settings.PNG   1.44MB   15 downloads

 

Also, whether this depth bias aspect was changed or not to accommodate the Barrocora table, that also had a totally simple fix.  If one selects the decal for the text of the inserts that was missing and changes the  "surface" field from blank (not defined) to that of 1h (1 unit high already defined in the table), they all re-appear and nothing else needs to be done (in both versions of test5a and test6 this issue was visible and fixed with this quick change).

 

I think we have to be careful of cases where simple table fixes are being missed in lieu of first / early reports of "bugs" and "issues" resulting in changes to the code affecting possibly many more tables and in ways where any type of table level fix for these new / resultant issues may not exist at all.  I wouldn't be putting this much energy into this development thread / specific topics I raise if any of the issues I experienced could have been fixed as easily as the 3 above.

 

Also, the attempt to fix the issues with those two old table via source code changes has not only lead to many more not working (any FS table with wall based roll-over animations at less than about .8 or so - most - will not animate any more) but the Blackout FS table itself that now has the inserts working in test6 due to the depth bias changes, now also suffers from the failing .1 height wall roll-over animations (even within the same table some new stuff is broken and not even with any table level GI / light objects present above the walls in question - indicates a large number of other tables would be affected as well with this simpler scenario).  

 

You can easily test the roll-over animations on these or any table that may experience the issue since this change to test6 by using the debug mode, right clicking on the sw / trigger for the roll-over (typically right around the roll-over / metal graphic), selecting the "hit" event for the appropriate trigger / switch and observing  - you'll hear a sound typically associated with the hit event but no animation (also repeating the process by choosing "unhit" to reset and try again).  Doing this same process in test5a or other VP92x builds will yield the animation as expected.

 

I really hope this can just be reverted in light of this new information and we can close the book on this particular issue of compatibility and continue to move forward.

Edited by jimmyfingers, 27 February 2014 - 07:30 AM.

[ClarkKent]

I wonder why there is still much stutter in AFM beta 4, especially when the big saucer is hit. FPS is not under 150 but still massive stutter then. Has this something to do with the primitives?

 

Exiting via HyperPin still does not work correctly. I wonder why it worked perfectly in test 1 but not anymore. The fix from toxie helped a little bit because sometimes it works now but most times not. I'm using AutoHotKey a lot but I've never encountered a game that prevents AutoHotKey from recognizing the defined keys...

[toxie]

I guess that this has to do with the various components of Hyperpin (fplaunch maybe?) which are all trying to grab the keys.

As a way out we could still switch back to the old pininput, but i would want to investigate more first.

[arngrim]

Excellent jimmy

[kiwi]

Me too, I have trouble capturing the screen, sometimes it works.
I have noticed that there are darker areas, the sides of the hole seems there are some oil stains,
something similar happens also on target.
When I can capture the right screen , every time that I start rendering the result changes, I will post some pictures.

 

Thanks

 

Max

[BananaBoat]

Side question, does anyone know why the sound on medival madness and AFM sometimes crackle?

Sent from my HTC_PN071 using Tapatalk

[toxie]

Try setting the sampling rate in VPinMAME to 48000. And use the VPinMAME build that arngrim provided somewhere in this thread.

 

@ClarkKent: I finally also could reproduce the key issue and it definetly seems like a focus issue caused by Hyperpin/fplaunch. Cause if you f.e. press the key to display a flyer, then afterwards it works as normal. But i might be able to also fix this from VP side, lets see.

[Swisslizard]

Hmmm, I feel kind of stupid

Tried to get the test6 version running (didn't try the earlier versions), but all I get is a message complaining about a missing directx dll.

In the meantime I have installed DirectX 9c as found on Microsofts website several times, restarted the cab a few times, but I still get that error message. My cab is running in XP.

Haven't got a clue what I'm doing wrong. Any hints?

By the way, the DX9 version is running fine on my Win7 64bit laptop.

Edited by Swisslizard, 27 February 2014 - 08:56 AM.

[mukuste]

What dll exactly is missing? Installing DX 9.0c and rebooting should definitely fix that, weird it doesn't work for you.

[BananaBoat]

Try setting the sampling rate in VPinMAME to 48000. And use the VPinMAME build that arngrim provided somewhere in this thread.
 
@ClarkKent: I finally also could reproduce the key issue and it definetly seems like a focus issue caused by Hyperpin/fplaunch. Cause if you f.e. press the key to display a flyer, then afterwards it works as normal. But i might be able to also fix this from VP side, lets see.

Ok sampling rate and .dll made no difference.

 

Do you guys run sound via a sound card or onboard sound?

Sent from my HTC_PN071 using Tapatalk
 

Edited by BananaBoat, 27 February 2014 - 09:39 AM.