1394 replies to this topic

[bent98]

I guess we will know once 574 is compiled.

[fuzzel]

better try 575

[jimmyfingers]

@jimmyfingers: i would actually rather go for having fading lights natively in the core, instead of having to have these evil hacks that also put some burden on the CPU and makes the scripting more complicated, too.. the question is just on how to do it.. I guess it would be some special light type that allows for blending between off and on via script or would be something more simple like a "time to full off" and "time to full on" better? (at least it would most likely be simpler to implement)

These lights then would be rendered "per frame", similar to how primitives and alpha ramps work..

 

Does that make sense? I would basically (in theory) expose two more parameters (the two "times", maybe in milliseconds), maybe also some blending curves (linear, quadratic, sine, etc) to steer the blend between on/off, and then these lights would simply be automatically do the fading whenever the light changes from on to off or off to on..

In general this sounds like an okay idea, however, it will not yield the same graphic quality / levels as attained with "real" fading lights textures that have 4 separate images for off, b, a, and on. The intermediary levels (b and a) of lights are not simply a blend of off and on and good artists / table authors draw the appropriate growing filaments and lit regions as is more natural with a real life light's brightness levels. Simply having off and on and blending in between levels will degrade the current standard lamp graphic quality that we've been able to achieve to date.

 

We would really need what you're proposing plus the option to add extra textures for intermediary levels and I would say the 4 we've used over the years would be still the standard. If you could modify the light object for off, b, a, and on with assignable textures than control with timings for, as you suggest, time-to-on and time-to-off (time-to-off typically being longer for the glow / heat dissipation) that would seem to be suitable. The only other thing I can think of is that actually using the fading lights routines / lamptimer has improved performance on tables greatly than using native light / lamp control as the fading lamptimer is typically set somewhere between 20 and 40 milliseconds and does not change any lights more frequently than that where as it seems the default pinmame timer is at 1 millisecond. Tables that have not utilized the lamptimer aspects for their routines have typically ground down the FPS. That could still be likely worked around though by simply checking the changed lights state and just applying the light object.state = 0 or 1 within the lamptimer timer sub-routine I suppose.

 

Maybe some of the other artists / authors can chime in too.  I’m not trying to be a pain here, but I really think it’s important while moving forward with VP that we don’t take steps backward in design choices that affect graphic quality or realism – this being maybe a subtle, yet I feel legitimate, example.

Edited by jimmyfingers, 14 May 2013 - 05:33 PM.

[jpsalas]

I haven't thought much about adding fading lights directly into VP. I use a modified Pacdude's fading light system, and I think it works quite well for vpm tables, but it is not so good for originals, since VP has so many nice features for single lights, like timers, patterns and a light sequencer. So a built in fading should be really nice, but for me it doesn't need to be using 2 lights, it could be made using 4 lights with only the on state as the one visible during fading. or it could be done using a single light but changing the image like in the primitives (or alpha ramps), and defining a fading, If no image is selected it could use in between colors like when selecting the the colors for the DMD, which vpinmame chooses the best ones for you. But I don't know how easy will be to implement it.

To make it short: I mean that the fading lights doesn't need to be made using two lights, but 4 steps are more than enough for the fading, and that it should be possible to select the images for the 4 steps. Now this could be done with 4 lights or with a single light, and defining a timer for on and one for off.

 

 

About rev 575: well done fuzzel! All the tables I have tried work very well Thanks! And as far as I know there are no more bugs (at least not new ones )

[unclewilly]

It would be much nicer to use just one light to do the 4 step f ade, but I dont think it would eliminate the need for the fading light script as I at least use it for many other objects such as alpha flashers, some non fading light objects as well as fading gi in some cases. But it would certainly save a lot of time being able to fade the lights using just one light object with 4 images or 4 steps of a standard colored light. Not sure how feasible the implemwntation would be for the devs. Once again, I can never say this enough, I appreciate all the work you guys are doing on the program, as well as including us on the testing and listening to our feedback

[jpsalas]

Still there is something not completely right with the ramps in rev575. Sometimes when I start a table some ramps are not displaying at all, and I can still see some extra lines being drawn. Quitting VP and run it again and the ramps are back to normal, then I do some editing, run the table and some ramps disappear again. Sometimes also VP crashes with a error about this program stopped responding. So I guess there is some debugging left

[fuzzel]

hmm can you detail it a bit more? what ramps or on which tables you see that?

 

Still there is something not completely right with the ramps in rev575. Sometimes when I start a table some ramps are not displaying at all, and I can still see some extra lines being drawn. Quitting VP and run it again and the ramps are back to normal, then I do some editing, run the table and some ramps disappear again. Sometimes also VP crashes with a error about this program stopped responding. So I guess there is some debugging left

[jpsalas]

I'm using it to build my new table, and when I made some changes and run the table to see how it looks, then I see that some ramps are missing. If I stop and start VP again then it works again. So it is only while editing, making changes, running, makes more changes, running... then suddenly it may give an error about that the program has stopped working or I can see some extra triangles and some ramps are missing. As I said, a restart and everything is ok again.

[toxie]

as for the lights: hmmm.. sounds to me like it makes sense to keep the existing solution then, and i'll simply add this additional flag for the off state/image then.. cool..

[jpsalas]

as for the lights: hmmm.. sounds to me like it makes sense to keep the existing solution then, and i'll simply add this additional flag for the off state/image then.. cool..

Yes, I think so, since we use that fading system to do many other things, like animations, flashers, and they can use not only lights, but dropwalls, alpha ramps, or reels.

[unclewilly]

I'm getting same issue as jp updateing bbb. Ramps disappear and primitives show as white boxes. Sometimes also the not responding crash. Exit vp and restar and everything is back to normal. In my case couldn't run the table twice without this happening

[oooPLAYER1ooo]

Is there a way we can swap the light image like we do alpha ramps via script?
That would be a sweet feature on wpc tables that use 8 step gi instead of using 8 lights per zone

[toxie]

Lights are pre-rendered, alpha ramps are rendered per frame, so unfortunately no.. Maybe in the future?!

 

 

@JP+UW: But this new error first appeared in 575? Or before that?

Edited by toxie, 15 May 2013 - 12:30 PM.

[oooPLAYER1ooo]

Lights are pre-rendered, alpha ramps are rendered per frame, so unfortunately no.. Maybe in the future?!
 
 
@JP+UW: But this new error first appeared in 575? Or before that?

I just wanted that idea to be floated, maybe something new in the future.
That feature would save a ton of light objects . Anyway carry on

[jpsalas]

@JP+UW: But this new error first appeared in 575? Or before that?

 

I don't know since I haven't used much the older revisions as an editor. But I'll try with 533 which was the first one with the vertex change. And I'll see how it goes. I'll report in a few hours.

[jpsalas]

Everything seems ok with older versions, and today I can't reproduce the error (the crash to the desktop and the ramps disappearing ?!). It only happens from time to time, mostly when you less expect it, and always when you run the table after making some changes. This is mostly with rev575, but I have had a crash or two with older rev too.

 

But what I just have noticed is that when the ball is moving under the alpha ramps used as flashers, you can see an square around the ball from time to time. I add here the test table with all the alpha flashers on, so you can see how it looks.

(there is a ball in the plunger, and you get a new ball if you press the "2" key, since I'm testing the kickers )

 

Those squares appears on all the revisions. I haven't tested changing options, but they appear if you have the Additive alpha option on.

 

Edited by jpsalas, 15 May 2013 - 06:55 PM.

[settingsons]

Wow - Incredible dev work going on with VP! - thanks to the devs for all their amazing efforts. Cyberpints all round

[oooPLAYER1ooo]

getting random crash's using rev 575, usually when i load the table i insert credit hit start and it crashes

Edited by oooPLAYER1ooo, 17 May 2013 - 03:10 AM.

[cmd]

getting random crash's using rev 575, usually when i load the table i insert credit hit start and it crashes

 

I'm getting similar crashes. I can load a VP9 table and play it the first time no problem. If I exit to editor - click "play" to re-load table - press"1" to start table, table begins to start but when kicker tries to load ball to plunger lane it crashes every time. Have tried about 10 recent VP9 tables to verify this.

 

cmd.

[oooPLAYER1ooo]

yep thats pretty much what im getting, but when table is running it is working as good as ever