3889 replies to this topic

[Ben Logan]

Totally agree. Kinda makes all the colors "gel." Good eye, Fren.

[unclewilly]

Can you swap those in the script?

[BorgDog]

Can you swap those in the script?

yes indeed.  table.ColorGradeImage="imagename"

[freneticamnesic]

I assume it's the primitive I'm using for the outer walls here causing this but it's the first I've seen of it. The transmission of the blue light on the fish eye to the left is appearing on the primitive wall next to it apparently a foot back from the light source? 

 

[kiwi]

 

 

@toxie, @fuzzel  I'm liking all the new options with targets and gates and stuff, but have a question.. Gates, can't be collidable and have a close angle other than 0?  If I make it non-collidable it is still one way, but there is no animation.  If close angle is 0 (collidable and animates) then nothing lines up right unless I want to stick primitives for everything and code them to move for all the parts (which I can do, but if we can make this work in vp then better).  

 

I'm trying to do this gate, which is obviously not at 0 degrees and if it were then balls would get stuck there.

 

 

Any thoughts on close angle other than 0 on collidable gates guys?  or is it just not going to happen?

 

In the past I have made the same request, and they said that you can not do that, can not remember why.
But, some time after they have introduced a new feature to read the angle of the gate.
In my tables are examples of the gates you are looking for.

 

Max

[freneticamnesic]

Yea if you use a primitive then just set a + or - offset of the Gate.CurrentAngle but you'd still need to physically move the gate to block the point you want. The gate would be invisible but the primitive gate would be in the spot you need

[zany]

Fren that last screenshot custom color grade gi on looks fantastic.

Agree...looks really nice and real, when colors are not so intence!
Well done Fren!

Having reflections on the outerwalls is amazing, i was about to ask if that was possible yesterday!

[fuzzel]

Sorry that isn't possible at the moment because of the way tables are built.

[toxie]

freneticamnesic, on 25 Nov 2015 - 03:59 AM, said:

It's weird, with the same default colorgrade, the off gi looks under saturated and the on gi looks oversaturated

 

This is due to the way the simpler tonemapping algorithms work (to get the HDR rendered image back to something that a LDR display can actually show).

And we use a pretty simple one because of performance.  

[freneticamnesic]

Having them appear as "reflections" is simply a bonus, the blue light transmission is the only thing killing the effect. It's an easy enough fix and the rest of the walls look neat in desktop mode (not so much in fullscreen mode but they're as you'd expect them to behave)

 

 

freneticamnesic, on 25 Nov 2015 - 03:59 AM, said:

It's weird, with the same default colorgrade, the off gi looks under saturated and the on gi looks oversaturated

 

This is due to the way the simpler tonemapping algorithms work (to get the HDR rendered image back to something that a LDR display can actually show).

And we use a pretty simple one because of performance.  

 

I am not sure I noticed the saturation "problem" until I actually fiddled with the colorgrade image, then I had something to compare it to. And doing as Knorr suggested in photoshop with an image of the table I realized I wanted a little less vibrance, it's fine really but I had a hard time imagining a real life scenario where you'd see a table that glowed like that.

[fuzzel]

rev2417 is up:

 

- add slim hit target meshes
- save some temporary memory
- fix a whole bunch of memory leaks and unitialized mem
- rename vbs folder to scripts
- optimizations to shader inputs/data processing and anti-ball stretch code
 

[vampirolatino2]

like the fixes and optimizations! good job.

[toxie]

don't expect wonders though, performance is roughly still the same.  :/

but the memory fixes should be noticable, especially when you work a lot with ramps.

[mpad]

Still wondering why it causes such a meltdown in my gfx card.
Still wondering why it causes such a meltdown in my gfx card.

[toxie]

this has been answered multiple times.. simply set vsync to 1 or some other number like 120 to limit the number of frames which also keeps the gfx board cooler..

[ClarkKent]

Since the last view versions I do not get a fully fluid ball movement anymore. Not with vsync 1, not with pre rendered frames 0,1,2, nor any other setting. Weird as it worked before.

[TedB]

this has been answered multiple times.. simply set vsync to 1 or some other number like 120 to limit the number of frames which also keeps the gfx board cooler..

 

Well even with these settings - they definitely help - the more demanding tables are not playable for me. Most VP9.9 tables  are working fine (even with B2S). So VP10 is clearly more demanding.
That said, some of JPs tables that I tested are working perfectly fine so it is still possible to have a pleasant experience with VPX with a less capable setup.

 

Bling and additional realism comes with a performance cost - I have no problems with that. I can't blame table authors using new awesome features and adding it to their creations to make the table as good as can be. I can choose to adjust the tables or upgrade my set-up.

 

From what I have understood - performance can be improved by adjusting objects in VP e.g Fren mentioned you can decrease stutter by adjusting the poly in primitives. Would it be possible to have a performance slider linked to the objects and settings that are demanding? I am only talking about graphical options then - it shouldn't affect gameplay. You will then miss a lot of nice VP10 features but at least tables can be played without having to adjust all objects manually.

Not sure if this is already requested, but it would be nice to have a saved preferred DT/FS setting or something to adjust the display setting for your set-up with one click. No biggie, just a nice to have. 
 

[bassgeige]

Since the last view versions I do not get a fully fluid ball movement anymore. Not with vsync 1, not with pre rendered frames 0,1,2, nor any other setting. Weird as it worked before.

 

I encountered the following fps behaviour before a few days myself. I would update to any new gpu to avoid it. For the new Cirqus Voltaire I can not reach a frame limit from 60 fps because it seems not to work with the new table any longer. Instead it shows always more than 60 fps and I think this is the reason for the ball stutter in this case. Did I miss an important setup option?

Attached Files

•  ingame CV v5 and 1.4 backglass.png   102.8KB   20 downloads
•  ingame CV v6 and 1.4 colour mod.png   118.23KB   20 downloads
•  settings.png   84.82KB   21 downloads
•  nvidia.png   36.44KB   20 downloads
•  nvidia2.png   39.53KB   20 downloads

[fuzzel]

rev2418 is up:

 

- fix a bug with wire ramps introduced in rev2417

[ClarkKent]

 

Since the last view versions I do not get a fully fluid ball movement anymore. Not with vsync 1, not with pre rendered frames 0,1,2, nor any other setting. Weird as it worked before.

 

I encountered the following fps behaviour before a few days myself. I would update to any new gpu to avoid it. For the new Cirqus Voltaire I can not reach a frame limit from 60 fps because it seems not to work with the new table any longer. Instead it shows always more than 60 fps and I think this is the reason for the ball stutter in this case. Did I miss an important setup option?

 

Maybe vsync is broken? I have to try to use FPS limiter = 60. At the moment it's not as much fun as before, the performance issue is deteriorating my enthusiasm...