2087 replies to this topic

[LoadedWeapon]

Amazing! plays fantastic just a few black splotches and light blinking looks funny but i think you know about that and if you have the ball on anti-stretch it looks oval had to put it on stretch ball with table.. Thanks for the work!

 Untitled.png   1.46MB   20 downloads

Edited by LoadedWeapon, 12 February 2014 - 11:37 PM.

[The Loafer]

Fantastic! Thanks for letting us test this (and I am NOT testing AA So no misunderstanding )

[bmiki75]

Great work i confirm that wcs94 now work perfectly.

[Slydog43]

Incredible,

 

With Win7x64 and these nvidia control panel settings the flippers look gorgeous.  Really like the lighting on the both the left and right flipper.

 

 

 

[LoadedWeapon]

yea but if you turn those setting on in NV panel other tables like STTNG and CV have black lights and lines on the table so they still only work with a few..

Edited by LoadedWeapon, 13 February 2014 - 01:06 AM.

[Slydog43]

I haven't noticed that many really.  Many less than before DX7 and NVidia settings turned on.  I think I will change my daily driver to this with the improvements being so great.  Thanks

 

 

Star Trek The Next Generation (Williams)(1993)(Teppotee, JP Salas, Clarkkent, Fuzzel)(1.1 GI MOD)- A few Black spots at the top of the table

 

Circus Voltaire I think only has 1 or 2 thin black lines.

 

[LoadedWeapon]

what do you have your VP setting on? let me take a SS of mine with same NV settings... gtx 660 on windows 7 newest Driver

 1.png   37.7KB   21 downloads

 VP9_DX9_test2 2014-02-12 20-44-58-99.png   1.48MB   21 downloads

 

 

Edited by LoadedWeapon, 13 February 2014 - 01:39 AM.

[jimmyfingers]

@Slydog43 (and all) - you'll be obscuring your results for your other AA settings if you enable FXAA but more so will have no "regular" AA effect, as you appear to be attempting in your screen shot, when you only use the "Enhance the application setting" along with VP (VP is doing nothing natively AA wise for it to enhance).  Disable FXAA and leave Anti-aliasing on "Overide" with any "Antialiasing - Setting" to actually use those other modes but you will notice even more graphical anomalies (blinking areas of table and mainly ball will blink / phase in and out). 

 

It appears that, at the moment, the override setting for Antialias-mode is still necessary for VP to do anything (i.e. FXAA on with Antialiasing - Mode set to "Enhance the application setting" appears to be just the same as FXAA on by itself and just "Enhance the application setting" wihout FXAA does nothing).  FXAA on it's own is making things look smoother and is seemingly working, but it shouldn't be confused with the tradtional AA modes and switches which currently are yielding issues when forced into action using the "Override....".

 

 FXAA highlight settings Capture.PNG   126.84KB   19 downloads

 

 

 

 

[LoadedWeapon]

oh yea now I see that he dident force AA ... yea that does nothing.. mine is what it looks like if you force AA

[randr]

Monster bash models look just like i modeled them when i use slydogs settings! WOW! and i get 1300fps awesome stuff

[Slydog43]

Jimmyfingers, you are right!  All you have to turn on in hte nVidia CtrlPanel is FXAA, and I leave off all the AA stuff (Only change from default  is FXXAA)

 

Tables look awesome (Flippers are smooth).  I tested out a historically tough table Checkpoint.  It plays a nice and smooth 303 FPS with Test2 and 660ti, win7x64, DOF, B2S.Server.   I only get around 202 FPS with 9.2.1 r916.  Great job!

 

I get a 333 Avg FPS in Monster Bash PCKiller.  It plays perfectly smooth!

 

get a place on the credit screen for mukuste

Edited by Slydog43, 13 February 2014 - 02:04 AM.

[frankrizzo2]

I just want to chime in and say thanks to everyone involved in getting this AMAZING software this far!! I can't wait to see where it goes from here!

Edited by frankrizzo2, 13 February 2014 - 02:10 AM.

[jimmyfingers]

I think more glitches will be noticed if instead of playing the tables and trying to see the oddities in mid-game, that instead the DMD diagnostics be utilized to run the "flasher + lamp" test (I'm referring to WPC tables and it seems fairly consistently located under the test menu>option 10).  For those that don't know you get in their with your "coin door open / close" button and navigate with the advance buttons: 

 

These are the defaults buttons from vpmkeys.vbs (right side):

 

keyCoinDoor    = 207   '(End)  Opening/Closing Coin Door

keyCancel        = 8       '(7)    Coin Door Cancel Button (WPC)
keyDown          = 9        '(8)    Coin Door Down Button (WPC)
keyUp               = 10     '(9)    Coin Door Up Button (WPC)
keyEnter           = 11     '(0)    Coin Door Enter Button (WPC)

 

Some glitches appear to also be now with the ordering of light objects in conjunction with alpha ramps whereas before only the order of the alpha ramps had to be considered and never affected lights (I take it that's due to the new rendering and how everything - or at least more - is dynamic).  So, some current glitches can be fixed by considering the light object heights now in your alpha ramp, primitive, flipper, etc. draw in front / back ordering.  The other glitch still remains with lighting and that where there are multiple objects on top of one another, like Mukuste mentioned, they do not sequence correctly (i.e. fading lights, GI8, fading playfield / plastics GI).  But the effect is made worse looking if the light orders are not resolved (mainly for playfield level light objects, just drawing in back will resolve along with any walls or ramps they may use as a perch above table GI lights).  However, any table that uses more than one light object for a lamp or GI effect will not display the lights correctly and you'll only get off and b or a and on images depending on the draw in back / front.

 

Mukuste, a question for you, can you currently re-assign the light objects images on the fly and have it update or is that going to need more coding?  You mentioned they are already dynamic, but can we actually script image changes (i.e. is the command set even there / working for that operation?).  It would still be very much ideal for the "9.3" DX9 version to be able to work somehow with the stacked lights, not because of more complex things like GI8 or ever playfield lighting, but because fading lights (with two lights for playfield lamps) are probably used in almost all VP9 tables (a few have experimented with alpha only but the results aren't necessarily as great as drawing them, and most people who've drawn them have drawn and coded the 4 levels / 2 per light).  Point being, it would likely be somewhere up around 90% or more of all tables for VP not being compatible without a lighting overhaul if that coudn't be worked out. 

Edited by jimmyfingers, 13 February 2014 - 02:15 AM.

[randr]

I cannot believe how smooth the graphics look! un frikkin real!!! anyways only issue ive noticed is W on some flippers is transparent..and the gi lights not correct. great work!

full size picture

https://www.dropbox....df/Untitled.jpg

 

Oh and "windowed" full screen seems fine. everything loading b2s, dmd(pindmd with plasmadmd) and dof all seems fine.

Attached Files

•  Untitled.jpg   114.08KB   12 downloads

Edited by randr, 13 February 2014 - 02:19 AM.

[Slydog43]

I know its a beta table, but Attack From Mars from JP Salas for 9.2 has a little error near the flippers (1 line across the screen)

 

[DJRobX]

The vast majority of the issues I see are with playfield lights, and that's a known issue.    This looks really, really good.   Fake full screen mode causes no problems on my cab or with hyperpin. 

 

Indiana Jones has a little bit of "sharding" in the playfield.   Interestingly only one of the I N D Y bonus multiplier lights at the top fails to work, but I suspect this is just part of the general lighting problem. 

 

Two tables crash on start.   Unfortunately they're both tables we can't discuss here.  

 

One, that we'll call "T" - gets HRESULT 88760827 at RenderDevice.cpp line 311 (followed by a null pointer reference crash)

The other, that we'll call "A" - gets HRESULT error 807000e in render.cpp line 287 (followed by a null pointer reference crash)

 

A lot of the flipper decals looks strange.   Sometimes they're just circles, or are there but are rendered in the wrong color and wrong position.   

 

Every once in a great while VP is crashing on exit.   Last time it happened was after playing Elivra and the Party Monsters, although it's not consistently reproducible (the most fun kind of bug!)

Edited by DJRobX, 13 February 2014 - 03:18 AM.

[frankrizzo2]

So far most tables that I have tried have played great! Most issues are like what DJRobX has mentioned.

 

I did however try the table Taxi and I am getting a few errors. One is when you plunge the ball into the "spinout" it's almost like there is no gravity and it spins around about 20-30 seconds before it drops in the hole(most times it goes through the hole in a few seconds depending on how hard you plunge it).

 

Also I have noticed that the ball will roll as "smooth as butter" until it goes into a pocket and when it releases the ball it stutters until it is shot back into a pocket again. Could be related to the way this table is lit though too. This table also crashes quite a bit on me too. http://www.vpforums....s&showfile=8610

 

My settings so far:

Adaptive sync on for both Nvidia and for Vpinball (Its the only way Monster Bash would play smooth without microstutter)

Windows XP 32

4 GB ram

GTX460 Playfield

GTX550ti backglass and dmd monitor

Nvidia 331.82 drivers

 

Once again thanks! It made my day to try this out!

[Sir Cheddar]

One, that we'll call "T" - gets HRESULT 88760827 at RenderDevice.cpp line 311 (followed by a null pointer reference crash)

The other, that we'll call "A" - gets HRESULT error 807000e in render.cpp line 287 (followed by a null pointer reference crash)

I didn't have time to test much, but both "T" and "A" work fine for me. With DOF/dB2S running, works in fullscreen and windowed fullscreen, both tested with ddraw=0

 

I fact "T" is a table that gains a lot of playability on my system.

[mukuste]

@JF:

 

Switching light textures works completely naturally now. All you need to do is set the .OnImage property (or .OffImage, if you wish) to the proper texture name.

 

I haven't worked on the draw order yet, I should probably check that out soon.

 

I had an idea how to fix the overlapping lights for the last compatibility release. Let's say if a light has its state changed in one frame, then we move it to the end of the draw order (at least as far as lights are concerned). Then it will draw last and override the other light textures. I hope this won't cause too many troubles with other draw order issues...

 

@DJRobX:

 

What do you mean by "sharding"?

 

Shame about the T'n'A tables. The first error looks like a texture creation error. Does that table do something funky with textures, like use really huge ones? The second one: are you sure about the line number? I have no D3D call at that line.

 

Can you give me a concrete example of where flipper decals are off?

 

Crashing on exit: bleh. That will be a pain to track down.

 

@frankrizzo2:

 

That's strange, physics shouldn't be affected at all. I'll try that table and see if I can spot anything though.

[DJRobX]

I ran "A" a second time and this time I get 8007000e in RenderDevice.cpp line 298. 

 

Not really sure what makes them any different from other tables (I tried a lot of them!), but I did try setting the max texture limit to 2048 and it didn't make a difference.   Also just tried 1024, same thing.

 

What I meant by "sharding" is that the playfield looks like it has some broken shards of glass.