2087 replies to this topic

[bent98]

I confirmed this  as well . It behaves  this way on my system.

Edited by bent98, 21 March 2014 - 08:15 PM.

[BuckoBundy]

For the second time now, I suddenly see corrupted graphics (looks like transparency or ordering issues) just out of the blue when firing up one of the test versions. So yesterday I played a few tables using test11 with everything looking fine, today I startup test11 again, load the same table I played last time and these graphic issues appear. I never changed any settings in those two days. And looking at the video options, everything looks the same as well.

This seems related to the VP registry settings because deleting 'HKEY_CURRENT_USER\Software\Visual Pinball' solves the problem.

[DJRobX]

For the second time now, I suddenly see corrupted graphics (looks like transparency or ordering issues) just out of the blue when firing up one of the test versions. So yesterday I played a few tables using test11 with everything looking fine, today I startup test11 again, load the same table I played last time and these graphic issues appear. I never changed any settings in those two days. And looking at the video options, everything looks the same as well.
This seems related to the VP registry settings because deleting 'HKEY_CURRENT_USER\Software\Visual Pinball' solves the problem.

Which tables? Next time you see corruption a screenshot would be helpful if you can get one.


Sent from my iPhone using Tapatalk

[mukuste]

But wouldn't this result in a too dark texture?

Will this lighting bug be addressed in a future release?

 

On the contrary, it will result in restoring the textures to their full brightness. The heads on Roadshow are too dark without this fix.

 

Having the "Enable Lighting" flag set on a wall which is used as a billboard is a table bug and has to be fixed as such.

 

 

Bug #2:  Of course, I did this and no matter what I did I couldn't see the red light ... ever, even if I never turned on ledf.     After a lot of WTFs, I sat in the debugger for a while.   The reason: the lights live in the backdrop!   There's some code that blocks all backglass items from going into the light vector, which is what allows them to come to the front when the state changes.  If I change that a little:

 

if (pe->m_fBackglass && pe->GetItemType()!=eItemLight)
                m_vHitBackglass.push_back(ph);      // VP9COMPAT: fixes Homer head on TSPP, remove in VP10

  else if (pe->GetItemType() == eItemLight)
                m_vLights.push_back(ph);            // VP9COMPAT: special treatment for lights

 

the lights start to work again.

 

Thanks, another good find. I'm terrified that making this fix for one table will break ten others again, but I'll have it in the next release and we see if anything breaks.

 

 

Mukuste,

It seems there is an issue with solid ramp transparency in Rev 10 and 11.  Please see the red circled areas in the SS below.  This is on my WIP of NGG but is also present in other tables (Airborne, Car Hop).  Edges look fine in Rev 9.  All of the circled objects are solid ramps.

The green circle represents another strange problem.  If an image that extends to the edge of the table is used on an alpha ramp in World Mode and the alpha ramp object extends off the edge of the physical table in the editor, the image gets extended.

Here is a simple table showing the problem.  Doesn't happen in 9.2.1

 

I'll look into the first one. For the second one, is it a problem simply not to have the alpha ramps extend off the table?

 

 

 

For the second time now, I suddenly see corrupted graphics (looks like transparency or ordering issues) just out of the blue when firing up one of the test versions. So yesterday I played a few tables using test11 with everything looking fine, today I startup test11 again, load the same table I played last time and these graphic issues appear. I never changed any settings in those two days. And looking at the video options, everything looks the same as well.
This seems related to the VP registry settings because deleting 'HKEY_CURRENT_USER\Software\Visual Pinball' solves the problem.

Which tables? Next time you see corruption a screenshot would be helpful if you can get one.

 

 

Yes, that would help. Also, next time you have that issue, a screenshot or registry dump of the registry settings before you delete them and after you reset them in VP to work again would be very helpful.

[Pablouk]

Hi all been a while since i fired my cab up but was just wanting to know the best install method for the DX9 version or do i just use the latest exe.

 

Iam getting loads of flashing going on on the ramps when AAx4 is switched on on scared stiff and cant seem to get rid of ball trails on any of the new table releases.

 

any advice would be nice

 

Thanks

Edited by Pablouk, 21 March 2014 - 08:43 PM.

[zany]

I don't touch my tables...doing workarounds as long as this is in test stages.
The result so far is AMAZING...best ever that could have happend to VP.
One thing i've been noticed though, is that new releases/mods is kind on idle now, and i guess that is because of you mukuste!

[DJRobX]

Thanks, another good find. I'm terrified that making this fix for one table will break ten others again, but I'll have it in the next release and we see if anything breaks.

 

 

For fun I was playing around with the order sort.   I'm not at all suggesting you add this because it's even more terrifying for sure, but if I do this:

 

std::unordered_set< Hitable* > toRemove (m_triggeredLights.begin(), m_triggeredLights.end());
   m_vLights.erase(std::remove_if(m_vLights.begin(), m_vLights.end(), [&toRemove] (Hitable* x) -> bool {
    return toRemove.find(x) != toRemove.end();}), m_vLights.end());

   m_vLights.insert(m_vLights.end(), m_triggeredLights.begin(), m_triggeredLights.end());

 

This preserves the order of m_triggeredLights, so the most recent changes go to the end of the order list.   Now the lights work on the original table as-is, without the need to hack the script.    I'll have even more fun running this with other tables and seeing the carnage it causes, LOL

[mukuste]

Preserving the order of triggered lights is actually a good idea. I just can't use the C++11 classes and lambda syntax since that won't work on older versions of MSVC.

 

Also, I think you have a bug there in that a light which gets triggered multiple times a frame will now get re-added to the lights vector multiple times?

[DJRobX]

Preserving the order of triggered lights is actually a good idea. I just can't use the C++11 classes and lambda syntax since that won't work on older versions of MSVC.

 

Also, I think you have a bug there in that a light which gets triggered multiple times a frame will now get re-added to the lights vector multiple times?

 

It works in Visual Studio 2010.   Are Toxie or Fuzzel compiling with an older version of VS than 2010?  (I know at least one of them is using VS 2010 as I can see the 2010 project gets updated).    Do we need to continue supporting compilers that are even older?

 

I went through a bunch of tables and did not see any apparent side effects from this so far.    I see what you're saying about it re-adding multiple times bug though.    I'm sure there's a cleaner way to build the lights vector, especially if we aren't going to use the C++11 constructs.  I was just looking for a fast and cheap way to test the theory anyhow. 

 

In case anyone was wondering, this does NOT fix the display in TSPP.   That one is completely different - it's built with gates attached to rows of invisible walls.  I'm still trying to figure out where the heck the dark dots even come from on that one.  

Edited by DJRobX, 21 March 2014 - 10:55 PM.

[DJRobX]

I took a stab at cleaning this up (version 2, with indexed searching!)

 

Player.h - Change m_vLights vector into a List (m_lLights), and an index map:

std::list< Hitable* > m_lLights;      // lights objects (VP9COMPAT)
std::map< Hitable *, std::list<Hitable *>::iterator> m_mapLightIndex;

And add new function TriggerLight:

    void TriggerLight(Hitable *pLight);

Player.cpp - new function TriggerLight

void Player::TriggerLight(Hitable *pLight)
{
    // Is this light in our list of lights?
    std::map< Hitable *, std::list<Hitable *>::iterator>::iterator lightIt = m_mapLightIndex.find(pLight);
    if (lightIt!=m_mapLightIndex.end())
    {
        // Move it to the end, and update the index.

        m_lLights.erase(lightIt->second);
        m_lLights.push_back(pLight);
        lightIt->second = --m_lLights.end();
    }
}

Update the code that adds lights to also add the index to that light:

 

// sort into proper categories
            if (pe->GetItemType() == eItemLight)
            {
                m_lLights.push_back(ph);    
                m_mapLightIndex[ph] = --m_lLights.end();// VP9COMPAT: special treatment for lights
            }

 

And change the RenderDynamics function to use the list instead (and remove all previous references to m_triggeredLights)

for (std::list<Hitable *>::iterator iter = m_lLights.begin(); iter!=m_lLights.end(); iter++)
      (*iter)->PostRenderStatic(m_pin3d.m_pd3dDevice);

In light.cpp use the new function instead of pushing into a vector:

         // notify the player that we changed our state (for draw order determination)
         g_pplayer->TriggerLight(this);

You of course need to update the other references to m_vLights to m_lLights. 
 

Instead of maintaining another vector of triggered lights, we just move the light to the end of the list at the time it's triggered.    You can then remove the triggered light vector and its associated code completely.   I don't see any perceptible difference in performance on my machines (the list of lights isn't that large in the scheme of things).  

 

*EDIT* updated with index to get rid of linear searches.

Edited by DJRobX, 22 March 2014 - 02:39 AM.

[DreamTrap]

Hi all been a while since i fired my cab up but was just wanting to know the best install method for the DX9 version or do i just use the latest exe.

 

Iam getting loads of flashing going on on the ramps when AAx4 is switched on on scared stiff and cant seem to get rid of ball trails on any of the new table releases.

 

any advice would be nice

 

Thanks

install the latest full version of vp 9.2.1 than download test 11 exe in this thread front page and drop it in visual pinball install folder.

 

to turn off ball trials on a table open the table in the editor, click on options to the left to bring them up, than over to the right click on ball, where it says trials motion blur in enable box type in 0.

 

if you want them all off in vp video options uncheck  ball trials.

Edited by DreamTrap, 22 March 2014 - 02:05 AM.

[mukuste]

Saving tables which contained primitives in Test12 corrupted the table file. This is fixed by Test12a.

Download VP9_DX9_test12a here:  VP9_DX9_test12a.zip   679.28KB   148 downloads
Important: instead of fullscreen mode, run in "windowed fullscreen" mode.

If you get flicker, please disable 4xMSAA.

Try the frame limiter, e.g. at 120 fps, for smoother gameplay!

Table compatibility spreadsheet (thanks to gtxjoe): https://docs.google....EPwri8/viewform

 

This is the first test release out of the main SVN repository since the DX7 version isn't being developed anymore.

 

Changes since Test11:

• (fuzzel & me) All potentially transparent objects now have a "depth bias" field. If you have depth ordering issues like lamps being partially obscured by other objects, then put the lamp's depth bias to some negative value to pull it closer to the camera for purposes of depth sorting.
• a change to hopefully make running VP as administrator unnecessary
• bumper lights can now properly be turned on from the options panel
• fixed an issue with unsightly seams on solid ramps with transparency (now back to test9 status)
• fixed a rare bug where walls would sometimes not get drawn if they had no top element
• lights now always use the lights update routine, even if they are on the backglass (change suggested by DJRobX to fix Monopoly lights)
• (fuzzel) environment mapping on wire ramps if a texture is supplied
• (fuzzel) add wire ramp options: diameter and distance X/Y of the wires
• (fuzzel) add CurrentAngle property to spinners

Known general issues:

*) textboxes don't work
*) EM reels only work in Image Reel mode, not Text Reel
*) text decals don't work
*) kickers cut the ball in half
*) Stereo 3D only works on NVIDIA so far
*) AA hardwired to 4xMSAA, flickers
*) textures aren't preloaded, can lead to stutter in some cases
*) screen shake doesn't work
*) adaptive vsync always falls back to normal vsync (can only be supported if we drop XP)
*) stereo3D parameters are different
*) "real" full screen mode doesn't work with VPM/B2S. Instead, use "Windowed fullscreen" mode.
*) lost devices aren't handled properly (real fullscreen issue only)
 

Known specific table issues:

https://docs.google....p=sharing#gid=0

 

Happy testing!

Edited by mukuste, 22 March 2014 - 08:18 PM.

[mukuste]

Here's an example how to use the new depth bias.

 

On unclewilly's Monster Bash, the lower two lights on the Creature Feature panel don't render correctly in the DX9 version (they lack the halo). This is because their average height is below that of the panel, making them render before the panel, which then overwrites the halo. So to fix this, you could find the l81 ramp and set its depth bias to -80, and for l82, set it to -25. This will cause the engine to draw these elements after the panel again.

 

Of course, on this table, the easier and better fix is to just set the Creature panel itself (Ramp3) to be a solid ramp instead of an alpha one, but this is just to illustrate the idea.

[BananaBoat]

It's getting to the point where novices like me are getting lost in the detail of setting these manual values to fix these issues.

Is there a register to record these issues with the recommended fix logged accordingly?

Sent from my HTC_PN071 using Tapatalk

[DreamTrap]

environment mapping on wire ramps huh...that should bump up the video requirements!

[mukuste]

It's getting to the point where novices like me are getting lost in the detail of setting these manual values to fix these issues.

Is there a register to record these issues with the recommended fix logged accordingly?

Sent from my HTC_PN071 using Tapatalk

 

Yes, the spreadsheet by gtxjoe, it's linked in the post!

 

Anyway these details are for the table authors. For you as a user, the best thing is just to wait until people release table updates which include these fixes.

[kiwi]

I have noticed that the solid ramps have lost their transparency.
Shooter, bumpers skirt, pegs are made with solid ramps, even the apron is made with a solid ramp but this is not abnormal.

 

 

Thanks

 

Max

Edited by kiwi, 22 March 2014 - 09:22 AM.

[mukuste]

I have noticed that the solid ramps have lost their transparency.
Shooter, bumpers skirt, pegs are made with solid ramps, even the apron is made with a solid ramp but this is not abnormal.

 

Thanks

 

Max

 

Sorry, I don't understand... is this a new issue with Test12 you are reporting?

[kiwi]

 

I have noticed that the solid ramps have lost their transparency.
Shooter, bumpers skirt, pegs are made with solid ramps, even the apron is made with a solid ramp but this is not abnormal.

 

Thanks

 

Max

 

Sorry, I don't understand... is this a new issue with Test12 you are reporting?

 

Yes, with test12.
I forgot to add the picture.
The table is available in my Upload list.

 

Max

[mukuste]

 

 

I have noticed that the solid ramps have lost their transparency.
Shooter, bumpers skirt, pegs are made with solid ramps, even the apron is made with a solid ramp but this is not abnormal.

 

Thanks

 

Max

 

Sorry, I don't understand... is this a new issue with Test12 you are reporting?

 

Yes, with test12.
I forgot to add the picture.
The table is available in my Upload list.

 

Max

 

 

I think the proper transparency color has to be set, e.g. white on Anello1? Or does the texture use an alpha channel?