1394 replies to this topic

[teppotee]

One future suggestion (don't know if this is doable or not...) that I got from the night mod / day version thread:

 

Would it be possible to swap the images when the table is rendered? So that in the script you could still change for example the PF image when table starts (of course all those images need to be included in image manager). What I'm thinking is something like this.

 

1) For example if you have images called "pfOff" and "pfGI" that are used by default and are pointing to day versions of the files. But you would also have "pfOffNM" and "pfOffGI" versions included.

 

2) If user wanted to use night version instead -> we could use different images for the render and change them in the script. Maybe like:

imageManager.pfOff.image = "pfOffNM"

imageManager.pfGI.image = "pfGINM"

etc.

 

3) In exception case when the image name doesn't match -> default would be used.

 

I know you are almost done with VP916 but I just wanted to write this down in case it's relatively easy to implement. I think it would be very useful so that we wouldn't need separate versions for day / night mod's anymore. Of course the downside is that the table size would get bigger... but this option would still be very nice This would also mean that all updates that are done to the table would only be done to 1 version which would also help a lot.

[Bob5453]

 

One future suggestion (don't know if this is doable or not...) that I got from the night mod / day version thread:

 

Would it be possible to swap the images when the table is rendered? So that in the script you could still change for example the PF image when table starts (of course all those images need to be included in image manager). What I'm thinking is something like this.

 

1) For example if you have images called "pfOff" and "pfGI" that are used by default and are pointing to day versions of the files. But you would also have "pfOffNM" and "pfOffGI" versions included.

 

2) If user wanted to use night version instead -> we could use different images for the render and change them in the script. Maybe like:

imageManager.pfOff.image = "pfOffNM"

imageManager.pfGI.image = "pfGINM"

etc.

 

3) In exception case when the image name doesn't match -> default would be used.

 

I know you are almost done with VP916 but I just wanted to write this down in case it's relatively easy to implement. I think it would be very useful so that we wouldn't need separate versions for day / night mod's anymore. Of course the downside is that the table size would get bigger... but this option would still be very nice This would also mean that all updates that are done to the table would only be done to 1 version which would also help a lot.

 

I'm not sure why you couldn't use ramps for this (ramp for each table image, etc.), but it seems like a lot of work to try to please everybody at the same time. I look at this as a hobby and when you start doing too much, meaning creating tables in a way that you don't even play them, then you've turned your hobby into a job.

[teppotee]

Haven't thought about using ramps... maybe that could work and then my suggestion is useless

 

And a very good point about hobby turning into a job... it certainly can feel like that at some point. And it's kind of annoying that when you start playing a table the first thing you think is that hmmm... should I change this or that instead of just enjoying it. Beer helps with that though

[fuzzel]

Hey Toxie / fuzzel, I discovered an odd performance / behaviour aspect (bug?) with primitives and the setting of them being visible or not (.TopVisible) via scripting.  After starting a table with a group of primitives and their “visible” options disabled (in the editor), I get one high level of FPS, then in the script I enabled visibility on the group of primitives using a timer routine 10 seconds later and the FPS drops considerably (to be expected).  However, after setting the .TopVisible back to 0, the primitives disappear from view again but only about 60 % of the performance / FPS returns to that which was witnessed at the start when they were off initially.

 

With RU enabled, I get lower FPS in general but, even maybe more oddly, after the first dip in FPS, it essentially doesn’t come back up at all.  Alternatively with RO, I get much worse FPS out of the gate, even with them off from the editor / start-up, but general low FPS is typical for that setting as far as I have witnessed on my systems, however with RO on at least it seems that the dip in FPS all happens at the start and no perceivable change occurs at any point (start with them disabled from the editor, on from the script, nor back off from the script).  I’ve verified this with both my systems that are Windows 7 32-bit and nVidia graphics cards (slightly different driver levels between my development and mini-cab – 327.23 and 306.97 respectively).  I've even tried with not just disabling the .TopVisible but also setting the X,Y, and Z sizes to 0 as well as transposing up, to the side, and below the table all in efforts to get it to no longer try and process whatever it is about the prmitives that dropped the FPS.

 

See the screenshots below and I’m attaching a test table for which the problems can be reproduced and observed.  I’m wondering if this might have something to do with the fact that the .SideVisible setting (as apparently described as existing in a couple forum posts and supposed code inspection) doesn’t appear to be working and the .TopVisible “appears” to make the primitive not seen.  However, maybe it’s not disabling as much of the processing as possible for the primitive considering it’s only the .TopVisible we’re setting somewhat like older alpha processing where the bottom and top width were set to 0 and it was not on screen visibly but indeed still took a hit on performance (until the alpha = 0 /1 was discovered).  It could make some sense in this regard and as to why I mention it being that this oddity is results in only approximately getting half of the performance levels back after it’s disabled again using just the .TopVisible (i.e if we could set SideVisible would it restore the FPS back to the initial levels?).

 

Curious if this could be remedied as there’s definitely some performance being lost considering that it appears after enabling a primitive’s visibility, it will never be back at the same levels during the game again no matter whether it’s visible or not.

 

Fixed with rev 682. The problem was if a primitive was visible the region information is valid to update the screen. If you hide the primitive (.topVisible=0) the region information was still valid even if nothing was rendered Your're right that .SideVisible isn't working in any way and could be removed.

I found another performance problem with primitives: If you changed the texture of a primitive from the script the complete primitive was calculated again (rotated/scaled and so on) which is not necessary at all and can slow down the FPS. So with rev682 changing just the texture for a primitive shouldn't have an impact on the FPS anymore.

[bundyboss]

Hi,

I've a graphical problem with the table Alien Star. (See pic added).

I've tested with the latest version Rev 682 and 677.

With version 9.1.5 I've not this graphical issue.

I hope it will help you.

 

Regards,

Edited by bundyboss, 23 October 2013 - 09:45 AM.

[fuzzel]

I can't see any picture?!

[bundyboss]

I've edited now the picture seems to be ok.

I add probably the same problem with Cheetah table.

 

Problem still not present with 9.1.5 version

Edited by bundyboss, 23 October 2013 - 10:32 AM.

[jimmyfingers]

@fuzzel - you rock!  Thank you very much for looking into and resolving this issue.  It's also great to know that you even discovered and fixed other aspects that will help with primitives / performance.  Instead of being potentially put off by all these requests, you actually dig even deeper and find even more stuff to improve - that's incredibly admirable and hugely appreciated.  This all does help to feel as well from this stand point that it's even more worth the time to do the testing and compose some notes, caputres, and test tables when you so quickly and handily solve the problem.

 

If you're ever in Toronto, a night of drinks is on me

 

 

Oh yah, same goes for you too Toxie (fuzzel had my initial focus from this latest resolution / improvement) 

Edited by jimmyfingers, 23 October 2013 - 09:52 PM.

[jpsalas]

I've edited now the picture seems to be ok.

I add probably the same problem with Cheetah table.

 

Problem still not present with 9.1.5 version

Those are the decals on the backdrop which are not completely disabled by removing the check of the "Enable Decals" option on the backdrop.
I'm sure fuzzel or toxie will find the drawing error, but they are very easy to fix on those tables: just enable the decals on the backdrop and you'll see the decals that were used in the old 4x3 table. They are not used in the FS table, so just select them all and delete them.

Edited by jpsalas, 24 October 2013 - 01:48 AM.

[bent98]

That's what happends with Nitro Ground Shaker FS also. I pointed out the bug last week but I think it got lost in the shuffle. I let you guys know the exact build it began in a previous post.. JP's simple fix will do the trick also but Toxie or Fuzzel might as well squash that bug as well.

[fuzzel]

Ah I remember you said it started with revision 646 but I didn't change anything on the decals code...Will check out again

[fuzzel]

Ok that was an easy one Fixed with rev683.

[bundyboss]

Thx a lot, I'll test that as soon as I can DL it.

[fuzzel]

I couldn't resist but here is another feature alert

Since rev 684 the lights support lightmaps. Here is a small howto:

- create a light and place it somewhere on the table

- define the playfield as off-image

- define a lightmap as on-image and check the option 'On Image' Is Lightmap

- The center cross of the light can be used to change the position of the lightmap, but you get best results if the cross is in the middle of the light.

- Be sure to draw the shape of the light as a square or a circle. Other shapes can result in texture problems.

 

When you switch on the light the lightmap blends over the portion of the playfield texture (see screenshot)

This way has some advantages:

1. The lightmaps don't have to be big, a size of 128x128 or 256x256 is enough

2. You can use the same lightmap multiple times for as many lights you like

3. It's much faster to lit a table that way instead of drawing multiple versions of the playfield

4. You don't waste a lot of VRAM because you only need one playfield as off image.

 

I attached a test table which you can try to see how it works.

Attached Files

•  LightmapExample.jpg   89.08KB   8 downloads
•  lighttest.vpt   8.52MB   13 downloads

Edited by fuzzel, 25 October 2013 - 01:49 PM.

[toxie]

Awesome stuff fuzzel, that should bring a ton of new eyecandy and make the flasher ramp "abuse" less important (and IMHO will even improve the rendering look this way)..

[fuzzel]

Absolutely! And the way how you can build tables is much easier

[toxie]

Looking forward to the first table that uses that exclusively.. (-> subtle hint to table authors to get to their computers ASAP )

[unclewilly]

Quick question about the lightmap stuff.

So the lightmap texture can be anything and it is blended into what is below it?
And in the off state it doesnt appear at all?

reason I'm asking is I like to use the fading light system.

I also like to make the inserts appear as if they are getting lit from below.

so say I made the lightmap texture as an exact copy of just the insert below. But more intensely bright then the pf below it, it would blend that into the texture on the pf below.

sorry for all the questions. I'm in the middle of 3 back to back 22 hour work shifts and won't get to experiment until Sunday.

[kruge99]

Will these light-maps eventually be able to support a colour property?  (ie: to simulate the coloured replacement LED bulbs)

[fuzzel]

Ok just a few infos about lightmaps. A lightmap is just a texture. What kind of image do you use as lightmap is up to you, normally the lightmap is something like the image below. If you want to color the light then you simply change the color of your lightmap. Take a look at the example I attached on my other post and you will get an idea how to use it.

If you want to create fading lights you still need two or more lights with different lightmaps for the fading steps. The only problem with this method is if two or more lights intersect each other. For example: you create a lightmap to simulate a bulb but in the area of that bulb there is another light and if you switch that other light on it will destroy the illusion of the bulb lighting the table.

Attached Files

•  lightmap.bmp   48.05KB   37 downloads