3889 replies to this topic

[bent98]

Toxie are you going to update the new compile or Fuzzel?

 

dying to test.

[maestro300]

Me to, but I think I figured it out. You can change one without changing the other, but if you do not set those values individually, a relationship is formed.

 

Off topic-- but great job on this table!    Do you own the real M&M Pacman pinball machine?    I own one and this really does play just like it.   The only difference is I'm not at 6 degree slope on my real machine-- so the VP version plays faster.    

[fuzzel]

rev1837 ist up:

 

- optimize flasher data layout and also never draw lights/flashers that are off
  introduces potential compatibility problem if a table uses lights with attached surfaces that are not directly below the light
  but according to the alpha testers this should be okay, lets see

- improve/correct bloom effect
 

[Shockman]

Directly below? I thought that was the only way it worked. Image as light off.

 

The yellow pacman lights, which you wont see in this image use an image for off state. directly below. The direction arrows, also gone, use no image, just a dark off and bright on.

 

There is not a single insert working at all. Off makes them invisible. 

 

I could probably fix this by putting the off light images off the full table size graphic they are on and directly onto the playfield image. And draw and color the arrow lights to have an image as well. Agreed? It would be worth the work to have a significant gain in FPS. Is this what you meant by directly below (physically below instead of assigned)?

Edited by Shockman, 10 March 2015 - 10:44 PM.

[toxie]

oh.. that i didn't really consider.. if someone uses a different image than the one on the attached surface, then of course it won't work like this.. :/

 

EDIT: so i'll add a check for this so that this will still work as before. but if you want the speed then the image should match with the one from the surface (or the playfield if no surface used).

Edited by toxie, 10 March 2015 - 11:05 PM.

[jimmyfingers]

Nice performance improvement for sure but I'm seeing significant problems with inserts and dynamic GI light objects (drawn) in one of my two VP10 conversion WIPs plus a slight one in the other WIP and likely is only slight because it doesn't use table / PF drawn GI in any way (older / non-dynamic GI pin).  

 

Would it be possible to make the option to draw the off image / state a check box for the light object, so where not needed it can be cleared for performance but where issues arise it could be selected?  That strikes me as something doable and that would probably be the best of both worlds and even still allow other ways to potentially get around issues via scripting or other techniques but if all else fails re-selecting a light object property to draw even when off (as before).

 

EDIT:

I'm seeing something else that may be complicating things and / or making the adverse affects appear worse than need be.  If this change is only for not drawing "off" lights, then something seems a miss as I can create a new light object, set the state to 1 / on in the editor, assign no scripting to it so that it will always be on, use an image for it (like a drawn lamp or plastic GI) and it will still not show despite being in an "on" state.  This occurs whether it is surfaced on a wall directly beneath it or not.  I did notice that if setting the light to "passthrough" though and if surfaced on a wall - looking only proper if the wall was directly below - (using a plastic GI light / wall as a test) then it would remain on / be visible, so it seems that "passthrough" on the light object being set / selected or not is entering the mix and that doesn't seem to be right.  If we could have "on" lights not disappear with images applied to them then likely the amount of problems would decrease and increase the solutions / workarounds to fix / modify how tables are built but still attempting to take advantage of the potential performance gains (still though seemingly much better if this was an option on lights / flashers to largely facilitate all scenarios of functionality or performance increase).

 

The performance gain is very nice so hopefully this can be tweaked a bit more to be usable, but like I say, right now I don't see why even "on" state lights with images are failing to be drawn as well.

Edited by jimmyfingers, 10 March 2015 - 11:38 PM.

[freneticamnesic]

4xaa is .....now playable!

[Shockman]

Are you confirming it will work if I redo those lights on the playfield image?

 

That is going to be a hell of a lot of work. They are not islands sitting on a alpha channel. They are images of off state inserts on the blue print image. Probably very common because we use to need two sets. Off and on. Most have added black around the border to reduce shine if the light is not perfectly aligned or fit. It would be probably easier to draw over than copy and paste. That would have to be pixel perfect and without the blue print images as a guide could take the rest of the year to draw and redraw to correct alignment. Just being dramatic. I could get to know PS layers better, but that is what it would take.

 

This might be worth it though. It might take days, and for me I am seeing no more than 30 fps increase. It synced at 60 before and syncs at 60 now, with more left over though 30 on default table, 20 on mine. If that is enough to run some effect or post process I could not afford before it would be worth it.

 

It might not have killed a well used and much needed feature, but it did give it a knock out blow this round.

 

I like the idea of an option. There must have been some table not effected by this. Weird that it was the one used for testing. Seriously though with an option we can keep running and working to get in shape to turn that option on. I put a smudge on a graphic and used it as the playfield image with a light over it and the smudge did keep showing with the light off, so it looks like this can be made to work.

Edited by Shockman, 10 March 2015 - 11:32 PM.

[toxie]

Nice performance improvement for sure but I'm seeing significant problems with inserts and dynamic GI light objects (drawn) in one of my two VP10 conversion WIPs plus a slight one in the other WIP and likely is only slight because it doesn't use table / PF drawn GI in any way (older / non-dynamic GI pin).  

 

Would it be possible to make the option to draw the off image / state a check box for the light object, so where not needed it can be cleared for performance but where issues arise it could be selected?  That strikes me as something doable and that would probably be the best of both worlds and even still allow other ways to potentially get around issues via scripting or other techniques but if all else fails re-selecting a light object property to draw even when off (as before).

 

It will be automatic anyhow: As soon as you select a non-matching off image (or no image at all) for a standard light (bulb lights are completely separately handled), then the element -has- to be rendered, otherwise the off image is useless (as shockman pointed out).

[Shockman]

oh.. that i didn't really consider.. if someone uses a different image than the one on the attached surface, then of course it won't work like this.. :/

 

EDIT: so i'll add a check for this so that this will still work as before. but if you want the speed then the image should match with the one from the surface (or the playfield if no surface used).

Are you saying all we need to do is put the lights image an a surface and the light on the same surface? That would be a piece of cake.

 

Edit:

Never mind . Got excited and went to try it. Have to put it on the table (wall, ramp, flasher) and show it to create a surface for it. It might work if the lights were the only part of the graphic and the background transparent.

 

I for one will put the inserts on the playfield image eventually and turn on the optimization.

 

Thank you. 

Edited by Shockman, 10 March 2015 - 11:56 PM.

[toxie]

and implemented like mentioned above, so will be in the next build.. please let me know if by then there are still problems with your tables..

 

Are you saying all we need to do is put the lights image an a surface and the light on the same surface? That would be a piece of cake.

 

The principle to get performance is simple: The images of both the surface and the light -have- to match, otherwise the light has to be -always- drawn on top (and as its dynamic, it will need to be updated each frame, even if off).

So if the surface is static (or if it ideally is the playfield itself), then everything will be fast (at least if most lights on the table are usually off).

 

EDIT: or simply use bulb lights or flashers, these are less complicated to use and will just automatically profit if they are off.

Edited by toxie, 10 March 2015 - 11:46 PM.

[jimmyfingers]

Toxie, what are your thoughts on the differing behavior regarding whether "PassThrough" is selected or not on a light as well as "on" lights also not showing even though they're on and not off?  I edited my post above so you may not have seen my comments on that witnessed nuance.

 

Also Toxie, I really think an option would still be be very very useful, regardless of the attempt to make it automatic and dependent on underlying / surfaced objects / images.  There were benefits before this with GI and lamps no overlapping when specifically not being surfaced on  a visible objects (lamp walls not visible but still surfaced and PF GI did not over-write / blink the lamps when active - light / lamps prevailed in the rendering).  This option would be very appreciated so we can work towards the performance increase but having compatibility where needed as things are potentially retooled and if not capable due to some scenarios, that we can leave permanently.  I don't see it as that unreasonable or undoable to have a choice / selection on a light for "draw when off" or something similar.

Edited by jimmyfingers, 10 March 2015 - 11:51 PM.

[toxie]

this should also work with the next build again (basically everything should work like before, but 'compatible' lights will still see the performance increase like in the broken build), if not then please let me know.

[jimmyfingers]

All right, looking forward to checking that updated build out.  Thanks again for looking into / raising this rendering performance improvement as, even if there might be a few growing pains and tweaks needed to tables and / or the source code or not all elements / designs capable of the performance boost, the overall prospects look very promising 

[Shockman]

What would really help now is like a blue print image, but with the white fully transparent and only lights showing. But everything could be erased around the lights and that used as a PS layer to guide light placement.

 

Nevermind. I can create one from a blueprint export easier than you could program one.

Edited by Shockman, 11 March 2015 - 12:15 AM.

[Slydog43]

wow MB FPS went from 215 to 295 with latest build, incredible improvement!

[Shockman]

Confirmation, and my first set of optimize compatible lights. Also my first off image in new build.

 

 

The maze lights off did not use an image but did use a lights off state for visual. Can't be part of the playfield image. The maze light are all below the surface. I will figure something out with them too.

[Shockman]

It's nice, and I had no idea that you can create different blueprints based on what layers are active. Very handy.

[fuzzel]

ok bugfix rev1838 is available.

[chas]

ok bugfix rev1838 is available.

where are the new revs'