2087 replies to this topic

[atarian]

From memory does that table have a post it for the highscore? Maybe it is reading a text file on the filesystem to read the high-score so you need to run the Test13 exe as admin.

Edited by atarian, 26 March 2014 - 07:37 PM.

[Sunskift]

Thanks atarian,

Running as admin eliminates the problem.
So if we should be able to get rid of the "run as administrator" for the dx9 branch, there is a fix needed !

Now, let's play ball !

[tttttwii]

This is the best release so far. I played 10 tables, no issue at all. Thank you!

[unclewilly]

I agree. It is working very nice for me as well

[Slydog43]

NBA Fastbreak (Midway)(1997)(JP Salas)(1.0) has a little messup at the flippers with test13

 

 

[striggell]

A lot of the last 40 pages have gone well over my head.

 

Massive thanks to Mukuste and all the other devs for this hard work though!!

[gigalula]

I'm not sure if this have been notified before but when I try with TEST13

 

"Time Fantasy" FS the ball disappear under bumper GFX middle up.

"The Six Million Dollar Man" FS GFX light missing

 

The same scenario have been tested and all seem to work fine with 9.2.1 EXE

 

Thanks for the progression of this project

Edited by gigalula, 27 March 2014 - 03:01 AM.

[DJRobX]

Running as admin eliminates the problem.
So if we should be able to get rid of the "run as administrator" for the dx9 branch, there is a fix needed !
 

 

Hmm, the VC project has

 

/MANIFESTUAC:"level='highestAvailable' uiAccess='false'"

 

This allegedly should cause VP to try and elevate to administrator on its own, as long as the logged in user is an administrator.    I know Mukuste is using CMake to build the project.  If he doesn't use this setting, it might explain why people are having issues with UAC in the DX9 builds, that they don't see with the official 9.2.x builds.

Edited by DJRobX, 27 March 2014 - 04:57 AM.

[jimmyfingers]

Thanks for the latest test build.  It looks like some GI8 tables work better now with the layered lights for both PF and on plastics now, so that's good.  

 

However, since this latest build test13, walls using .png images and a transparency setting of 123,123,123 now have rough / discoloured (lighter) edges.  Using .png images with an alpha / feathered edge and no set solid colour background had previously led to the smoothest edges I had ever achieved with VP on my mods and improved image quality / softened the hardness between wall images and their backgrounds.  It was working fine with all test versions up to 13 and here is a comparison of 12a vs. 13 below respectively with some sample objects from my WIP AFM GI8 mod placed in an independent test table, which I'm also attaching.  It's zoomed in on the screen shot and the view settings for the attached table and can be easily reproduced by simply running in the latest and any previous version (test12a specifically).

 

 Capture of Wall Edges Dawn Properly in Test12a.PNG   78.56KB   42 downloads

 

 Capture of Wall Edges Dawn Roughly in Test13.PNG   79.21KB   41 downloads

Attached Files

•  Test table for Wall Image Graphic Issues (poor edges) Starting with Test13.vpt   168KB   4 downloads

Edited by jimmyfingers, 27 March 2014 - 05:02 AM.

[MrBungle]

I am so impressed with the way VP has progressed in recent months. As a teacher I have introduced my students to the world of Virtual Pinball and although many are in there Teenage years even they are impressed.

 

Keep up the good work team, you are all legends.

[Arcade4]

No table graphics in Hurricane still with test 13. (Nevermind, it is working now.)
 

Edited by Arcade4, 27 March 2014 - 10:55 PM.

[DJRobX]

What version of Hurricane are you using?  I checked a bunch of them and they all look fine on my system. 

 

There was one other person who reported an issue with Hurricane and Austin Powers (see this post ) that started after Test11.   He had dark playfields with a Nvidia video card under Windows 7, so it wasn't the Intel IGP issue.   I haven't been able to reproduce it.  

Edited by DJRobX, 27 March 2014 - 04:07 PM.

[Arcade4]

What version of Hurricane are you using?  I checked a bunch of them and they all look fine on my system. 

 

There was one other person who reported an issue with Hurricane and Austin Powers (see this post ) that started after Test11.   He had dark playfields with a Nvidia video card under Windows 7, so it wasn't the Intel IGP issue.   I haven't been able to reproduce it.  

Running ATI 5670 with windows 7.

It is fixed now. Was mistakenly running Test 12 still. 

Edited by Arcade4, 27 March 2014 - 10:56 PM.

[Horrible]

 

 

Dx9 is my official exe file now. The most tables run fine. Another with small issues. But my fauvoritetable whitewater still have big troubles with the lights.. I hope that will be fixed becouse i like that table. Thank you very much for all the hard work with vp dx9

 

I played Whitewater a lot recently - such a fun table! The black insert lights you can fix yourself, just go into Table>Images and set Transparency to pure black for all "pfX" textures.

 

Then the only issue left I think are the two lamps on the upper playfield panel... those will need to be fixed once we have the depth bias parameter.

 

Maybe someone can update this wonderful table to the new features? I even reworked the playfield and plastics some time ago but nobody seems to care...

 

https://www.dropbox....al_enhanced.psd

 

 

 

Does anyone know if this is fixable now (see image below) and how (running on DX9 Test 13)?

Also as ClarkKent asks - is anyone looking to update Whitewater?

 

Edited by Horrible, 27 March 2014 - 08:21 PM.

[Findusone]

With 13, Hurricane and Austin Powers works fine for me.

[DJRobX]

Does anyone know if [WhiteWater] is fixable now (see image below) and how (running on DX9 Test 13)?

 

Yes, with the new Depth Bias adjustment.  Open the table and go to Edit, Select Element, and select l17, l17a, l17b, l55, l55a, and l55b (ctl-click to select them all at once).  On the right input "-50" for the Depth Bias.   

[mukuste]

 

Running as admin eliminates the problem.
So if we should be able to get rid of the "run as administrator" for the dx9 branch, there is a fix needed !
 

 

Hmm, the VC project has

 

/MANIFESTUAC:"level='highestAvailable' uiAccess='false'"

 

This allegedly should cause VP to try and elevate to administrator on its own, as long as the logged in user is an administrator.    I know Mukuste is using CMake to build the project.  If he doesn't use this setting, it might explain why people are having issues with UAC in the DX9 builds, that they don't see with the official 9.2.x builds.

 

Yeah, I don't have that setting. That's the problem when you have so many different build systems, they'll invariably get subtly out of sync. I have argued for CMake as the master build file since it can create different VS solutions at the click of a button, but the response was negative.

 

 

 

However, since this latest build test13, walls using .png images and a transparency setting of 123,123,123 now have rough / discoloured (lighter) edges.  Using .png images with an alpha / feathered edge and no set solid colour background had previously led to the smoothest edges I had ever achieved with VP on my mods and improved image quality / softened the hardness between wall images and their backgrounds.  It was working fine with all test versions up to 13 and here is a comparison of 12a vs. 13 below respectively with some sample objects from my WIP AFM GI8 mod placed in an independent test table, which I'm also attaching.  It's zoomed in on the screen shot and the view settings for the attached table and can be easily reproduced by simply running in the latest and any previous version (test12a specifically).

 

Capture of Wall Edges Dawn Properly in Test12a.PNG

 

Capture of Wall Edges Dawn Roughly in Test13.PNG

 

This is an unfortunate inevitability when using prerendered elements. They cannot use this sort of alpha feathering since, as soon as for instance a ball rolls behind this edge, the feathering will stay at the precomputed values and not let the ball shine through.

 

 

 

No table graphics in Hurricane still with test 13.
Not sure if it was supposed to fix it or not though.
Maybe the table will just have to be updated to get it to work now.
Last time all graphics were there was in test 11.

 

I really want you to check again because I reproduced this issue in Test12 and made specifically sure that this table works properly in Test13 before I released that version.

 

 

Does anyone know if this is fixable now (see image below) and how (running on DX9 Test 13)?

Also as ClarkKent asks - is anyone looking to update Whitewater?

 

Yes, this is fixable! You just have to find those two lights and set their Depth Bias to some negative value; try -50 for starters. If you figure out the exact steps to fix this, it would be nice if you post them here or even better in the table compatibility spreadsheet. EDIT: Ah, DJRobX already figured it out while I was posting!

Edited by mukuste, 27 March 2014 - 08:58 PM.

[DJRobX]

Added info on the fix to the spreadsheet too.

[Arcade4]

You were right Mukuste. 

Hurricane works great in Test 13.

I had left Test 12 in my download folder and without paying attention, must have reinstalled 12 on top of 12. Doh!!

Thanks for the fix.

[jimmyfingers]

 

However, since this latest build test13, walls using .png images and a transparency setting of 123,123,123 now have rough / discoloured (lighter) edges.  Using .png images with an alpha / feathered edge and no set solid colour background had previously led to the smoothest edges I had ever achieved with VP on my mods and improved image quality / softened the hardness between wall images and their backgrounds.  It was working fine with all test versions up to 13 and here is a comparison of 12a vs. 13 below respectively with some sample objects from my WIP AFM GI8 mod placed in an independent test table, which I'm also attaching.  It's zoomed in on the screen shot and the view settings for the attached table and can be easily reproduced by simply running in the latest and any previous version (test12a specifically).

 

Capture of Wall Edges Dawn Properly in Test12a.PNG

 

Capture of Wall Edges Dawn Roughly in Test13.PNG

 

This is an unfortunate inevitability when using prerendered elements. They cannot use this sort of alpha feathering since, as soon as for instance a ball rolls behind this edge, the feathering will stay at the precomputed values and not let the ball shine throI;

I'm sorry mukuste, but this answer makes no sense to me.  Are you not seeing that the pictures are different (worse) from test12a to test13?  That is, something has totally changed between versions to make these edges on these type of walls different and noticably worse.  Talking about this element as if it's simply an inevitability when it's a new issue doesn't really answer the question appropriately as to why it has just started and, honestly, gives little hope of actually being addressed - as it totally should be.  This continues a trend of graphical degradations and deviations from VP921 where these type of issues seem to continue to not get much concern or attention and feels like always an uphill battle to get due focus and a commitment on resolution.  Now here seemingly even recognizing the problem and the key logical element that the answer doesn't even fit the fact that the problem is new since test13.  Seems to me something with the changes in transparency aspects that have been introduced (with a bug on ramps) in test12/test12a and now maybe the fix to address those transparency issues in test12a has caused this new issue?  

 

Please address this issue for what it is - new and undesirable. I really hope this trend of the acceptance of graphical issues can be broken as this will be quite sad if VP is to now just simply have to accept this type of quality when we can clearly see that something has changed only in the last version to cause this.  Things at times are maybe just too quick to be answered away vs. actually seeing that there's a real problem and here I don't see any reason why if it worked in test12a and before, has to be something that, from the answer, is something we're just going to have to live with. This is very distressing to see as someone who cares about the quality of how VP looks but can not jump in to your coding and do what you guys do (we're still at your mercy of wanting to spend the time on the areas that maybe not important to you but are to others even if us authors are already a minority and even more so the ones who build and notice when edges aren't clean).