616 replies to this topic

[cyberpez]

The one thing I didn't change 

 

That took care of it!!!  thanks toxie!!!

[toxie]

i quickly looked on how easy it would be and even the standard DX9 performance queries failed on me.. so no low hanging fruit there to get this done easily..

 

unless one has a typo in there that f*#ks it all up.. 

so maybe not that unlikely to have something like that.. i'll see what i can do..

[DJRobX]

Yes, good plan, but not as easy as simply adding timers around function calls unfortunately.. To properly do this one would need something like perfkit SDK (who knows if this still works properly nowadays) as so much is running async on the CPU/GPU nowadays..

 

Thanks for checking.   We could do it without perfkit SDK in a brute force manner by automating what I currently have to do manually - exclude/remove an object, render, review FPS, rinse, repeat.    It would take a while for a table with a lot of objects but the performance analysis doesn't have to be pretty or fast.   If I get some time I"ll tinker around with that and let you know if I get it to work if your method fails. 

 

 

 

As Toxie already said it's quite complicated to add that and imho it shouldn't be part of VP. As a rule of thumb for better performance when building a table is to combine as much meshes as possible into one mesh that also uses one texture/material. Performance will surely drop when you draw a lot of small walls with different and transparent textures/materials. Especially VP9 ports behave like that if the author didn't pay attention.

 

 

 

Yep the idea is to help table authors understand what has impact.     If not part of VP, what would it be part of?    That's like saying the code profiler shouldn't be part of visual studio.  

Edited by DJRobX, 28 July 2017 - 09:37 PM.

[nFozzy]

Does anyone have a copy of rev3086?

[kiwi]

 VPX_3_beta_rev3086.zip   6.99MB   13 downloads

[toxie]

any reason in particular why you ask for that version? 

[Dozer316]

Hiya Guys, just a quick one regarding ball light reflections. On this Indy 500 build which is a resized port of vp9 version I cannot get lights to reflect off the ball no matter what I try.

If I set a lamp bulb enabled at height 35 for example I can see the ball cutting into the lamp halo as it passes but nothing reflects. I've mirrored other table environment settings where reflections work fine so not sure what's going on.

Any insight would be great - Dozer.

Sent from my SM-G930F using Tapatalk

Edited by Dozer316, 30 July 2017 - 08:55 PM.

[flupper1]

I had this as well and fixed it for Diner, but I do not remember how. If you copy a light from the slingshots GI of Diner, does that work? I even used two lights below the playfield for nice highlights.

[Dozer316]

I had this as well and fixed it for Diner, but I do not remember how. If you copy a light from the slingshots GI of Diner, does that work? I even used two lights below the playfield for nice highlights.

 

Hey Flupper, I fixed it today too accidentally.  What caused it was I had dragged a number of old ramps out to the side of the table which meant that when I first started the table I had very high X and Y offsets to get it centered.  (Like in the 1000's).    I left all this old stuff out there because the script was still calling old alpha ramps etc.     I finally got around to cleaning up the script today and deleted all this old stuff which meant I could centre again with small offsets and it fixed the reflection problem! 

I'm actually about to start doing the ramps for I500 with your tutorial so thanks a million for taking the time to put that together.

[BorgDog]

So, what's the deal with legacy mode on targets, drop targets in particular. First off it's not documented what it is/does in commandreference.txt, and secondly without it turned on drop target hits don't always register, the ball just bounces off.  I know this has been going on for quite some time and everyone's solution is to just turn on legacy mode then it all works, which is fine, but I currently working on a setup where I can't have the drops drop if hit from behind, which they do if set to legacy.  I could put a small wall behind them all and script around it, but it's a feature that should work and just doesn't always, like 95% of the time it works, but it's really annoying when it doesn't, especially when it does it several times in a row.

 

If you play long enough on the default table the drop targets on the right side will exhibit this behavior.

[jpsalas]

In legacy mode any hit on the droptarget will count, this is: all the sides will register the hit, front, sides and back. But if legacy mode is not selected then only the hits on the front side will register as a hit.

[BorgDog]

Yeah I pretty much have that figured out, but it also doesn't register direct hits on the front either, which is the real issue and has been brought up several times by many people.

Sent from my Nexus 6 using Tapatalk

[Practicedummy]

So, what's the deal with legacy mode on targets, drop targets in particular. First off it's not documented what it is/does in commandreference.txt, and secondly without it turned on drop target hits don't always register, the ball just bounces off.  I know this has been going on for quite some time and everyone's solution is to just turn on legacy mode then it all works, which is fine, but I currently working on a setup where I can't have the drops drop if hit from behind, which they do if set to legacy.  I could put a small wall behind them all and script around it, but it's a feature that should work and just doesn't always, like 95% of the time it works, but it's really annoying when it doesn't, especially when it does it several times in a row.

 

If you play long enough on the default table the drop targets on the right side will exhibit this behavior.

 

Phew! I thought I was going crazy when It seemed the drop targets on certain tables weren't registering. Wasn't sure if it was my eye playing tricks on me.

[Thalamus]

@BorgDog : Curious, these targets are they at 0 angle ? I believe I read somewhere that a slight angle change, even by a degree could changed their behaviour. Don't remember where I read it, or if it is valid in this case.

[fuzzel]

I'll check that when I'm back from vacation it sounds like that the hit shape of a drop target has an orientation issue.

[toxie]

 

Yes, good plan, but not as easy as simply adding timers around function calls unfortunately.. To properly do this one would need something like perfkit SDK (who knows if this still works properly nowadays) as so much is running async on the CPU/GPU nowadays..

 

Thanks for checking.   We could do it without perfkit SDK in a brute force manner by automating what I currently have to do manually - exclude/remove an object, render, review FPS, rinse, repeat.    It would take a while for a table with a lot of objects but the performance analysis doesn't have to be pretty or fast.   If I get some time I"ll tinker around with that and let you know if I get it to work if your method fails. 

 

 

 

As Toxie already said it's quite complicated to add that and imho it shouldn't be part of VP. As a rule of thumb for better performance when building a table is to combine as much meshes as possible into one mesh that also uses one texture/material. Performance will surely drop when you draw a lot of small walls with different and transparent textures/materials. Especially VP9 ports behave like that if the author didn't pay attention.

 

 

Yep the idea is to help table authors understand what has impact.     If not part of VP, what would it be part of?    That's like saying the code profiler shouldn't be part of visual studio.  

 

I think i found a reasonable trade-off for now, something which then again the authors can build upon (our your additional code??).

The F11-stats/debug display now has 2 additional modes: One which tracks the timings for each rendering component (like ambient occlusion, playfield reflections, elements rendering), and one which tracks the timings for each element type(s).

This way one can see with mode 1 which rendering components dominate the gameplay (e.g. if it's just something that must be triggered anyway like ambient occlusion (if enabled) and that cannot be changed by the author) and then with mode 2 which element type(s) are dominating the author created part.

[toxie]

Here the new stats

Attached Files

•  Untitled.jpg   170.53KB   12 downloads
•  Untitled2.jpg   170.85KB   11 downloads

[Thalamus]

Sweet Toxie. Without actually trying this yet, wouldn't it make sense to also display the max values seen ?

[toxie]

maybe, but the variance/wrong measurement probability is much higher here than with the per-frame timings already existing, so there could be a lot of false info in the end.

[BorgDog]

@BorgDog : Curious, these targets are they at 0 angle ? I believe I read somewhere that a slight angle change, even by a degree could changed their behaviour. Don't remember where I read it, or if it is valid in this case.

 

Both the ones in my table and the default table are at an angle.

 

I'll check that when I'm back from vacation it sounds like that the hit shape of a drop target has an orientation issue.

 

Thanks fuzzel.