666 replies to this topic

[fuzzel]

Ok I've run into some graphics issues with mb that will force me to switch all the gi and flashers over to the new flasher object.

Just a few questions.

Will the ru checkbox be fixed or will it always need to be checked.

Also will a vertical flasher object be possible.

I haven't had a chance to look at the commands yet. Does this object also use the triggersingleupdate command

I appreciate this object as it should make mb look awesome

Since rev832 the RU option for flashers is removed. A flasher has to update it's region because of the transparency. Let me know if this works better now.

[unclewilly]

I'll be switching the whole mb table over to using the flasher object for gi and flashers soon. Once I finish I'll send you a copy for testing

The table will probably be a good performance test for vp

[fuzzel]

ok looking foward testing it regarding your question if vertical flashers are possible: I fear no they aren't. I would like to keep the flasher simple as it is now because of performance reasons.

Edited by fuzzel, 29 December 2013 - 11:41 PM.

[unclewilly]

That's fine I can use alpha ramps for the 2 verticle flashers I need

[jimmyfingers]

@fuzzel - Have you simply removed the option but forced it on / hard coded it to always be enabled?  Or is it now no longer RU enabled at all but the bug fixed and working without the paint ball effect? 

Edited by jimmyfingers, 29 December 2013 - 11:56 PM.

[koadic]

Hey Fuzz, in regards to copy/paste of flashers, can you set it up so it inherits the lock state and layer of the flasher being copied? currently when pasted, it is unlocked and set to layer 1 regardless of original flasher properties.
EDIT:I guess this applies even when loading the table into the editor, as all the flashers get moved to layer 1 and unlocked... as well as randomly changing the 'Display Image in Editor' property

And I agree with UW, it would be nice to be able to either have a vertical option, or an angle input (like with gates) where we could create whatever angle of flasher effect we want, but if it isn't possible/feasible, then we'll just have to make due...

Also, when using the flashers close to the bottom of the screen, leaving RO disabled and just checking the update regions box, the artifacts left over at the bottom of the screen are even worse than when just using ramps... left image is using flasher, right is using alpha ramp, with some extra black space added to the bottom so it wasn't right up against the edge. While the right is better, it still leaves some of the flash image behind (can see if you zoom in a little)

Edited by koadic, 30 December 2013 - 01:45 AM.

[jpsalas]

just a small bug report: in rev832 you cannot copy/paste primitives anymore

(it doesn't work on rev831 either, but it works in rev828)

Edited by jpsalas, 30 December 2013 - 11:28 AM.

[fuzzel]

@fuzzel - Have you simply removed the option but forced it on / hard coded it to always be enabled?  Or is it now no longer RU enabled at all but the bug fixed and working without the paint ball effect? 

RU is always on now. I couldn't get it to work otherwise...If you don't enable RU you get the paint ball effect because the flasher is drawn over the non updated region over and over again (that creates the paint ball effect). If I don't use RU at all you need a refresh light again or you won't see the flasher anymore.

 

@all: rev833 fixes the copy'n paste issues for flashers and primtives. I can add a rotation option for the flasher so you can rotate it like a primitive in any direction you like but I've no idea how to visualize this layout in the editor. Because if you rotate the flasher by 90° it becomes vertical and you will only see a thin line in the editor. Or I leave the flasher as it is in the editor and you have to check the rotation playing the table...

[fuzzel]

and rev 834 changes the rendering a bit so you won't see artifacts anymore BUT you have to adjust the height/drawing order again if you have overlapping flashers, just like the old way with ramps.

[koadic]

Any way of fixing it so the artifacts left by the ramps go away too?

And I know that fps isn't the end all, be all of VP performance, but here are some numbers using the Flasher object compared to alpha ramps...

Standard method using ramps, 8 flashers, 16 gi lights
(taken using FRAPS except where noted, F11 drops framerate by about 20 when in use)

- RO off/RO on
Fresh table start - 625/375
Average fps of light and flasher test from rom - 585/355
Ball sitting in shooter lane - 615/535
FPS(avg) of two games as reported by F11 - 575/510

New method using flasher objects, 8 flashers, 16 gi lights (Turned on/off by .isvisible, Additive blend @ 255, unused ramps set to .alpha = 0)
(taken using FRAPS except where noted, F11 drops framerate by about 20 when in use)

- RO off/RO on
Fresh table start - 515/380
Average fps of light and flasher test from rom - 435/355
Ball sitting in shooter lane - 500/530
FPS(avg) of two games as reported by F11 - 460/505

[fuzzel]

Ah nice test...do you use the RU option on the ramps or is it without RU and a refresh light?

[koadic]

No RU, ramps updated with .triggersingleupdate

[destruk]

Thanks for fixing the Virtuapin controller Exit Game button.

[koadic]

Thanks for fixing the Virtuapin controller Exit Game button.

No prob I might end up implementing an option to allow the PBW style behavior for keyboards/generic controllers as well (unless someone else does it first)

[fuzzel]

No RU, ramps updated with .triggersingleupdate

Ok that makes sense...can you test it with rev831 again please and uncheck RU and use .triggersingleupdate on the flashers? I suppose that the performance is near the ramps then...

[jimmyfingers]

I also am witnessing less performance using the flasher objects vs. traditional ramps.  My guess is it's mainly related to the RU being hardcoded / required as it stands now.  I've always had lower performance on all of my systems with that option used either generally via Video Preferences or specifically (on ramps) since that per object option was available. 

 

I think it would still be potentially useful, if you can do it fuzzel, to have a flasher object version that does not use RU but indeed requires the light refresh or maybe also the .triggersingleupdate command for updating the flasher objects.  The light refresh has it's benefits and does not bother me personally to use.  In fact, there could be an argument made and I prefer it's use when using a newer method for updates that I created via scripting and discussed previously regarding a single refresh light that only get's updated once per lamptimer cycle (updating all changed ramps in one pass / with only one update hit) and is signalled simply using a variable.  I know that I and other author's who use this simplified / optimized method have achieved much better performance / smoother game play especially when also using forced AA via nVidia control panel.

 

@Koadic - could you PM me your test table as I'd like to run similar tests as you did but using a refresh light and the single update / optimized refresh method.  Would like to compare that further to the performance of the flasher object as well as even the ramps method using the .triggersingleupdate such as you had used.

Edited by jimmyfingers, 30 December 2013 - 08:03 PM.

[onemanproject]

3D stereo output is not working for me. If i checked "enable 3 D stereo" two pictures are on the screen, no real 3 D.

If i checked "enable Antialias 3 D" nothing happens.

 

Ich weiss nicht ob das schon einmal besprochen wurde.?

[koadic]

No RU, ramps updated with .triggersingleupdate

Ok that makes sense...can you test it with rev831 again please and uncheck RU and use .triggersingleupdate on the flashers? I suppose that the performance is near the ramps then...

If I turn off Update Regions for the flashers, and I am not using RO on the table, the flashers don't appear correctly using .triggersingleupdate (paintball effect), but if I enable RO, then I don't need Update Regions enabled (and no need to trigger update either), but the framerate is no different than if it was enabled. Using a refresh light w/o Update Regions or enabling RO introduces it's own unique issues (not usable in this fashion)
 

@Koadic - could you PM me your test table as I'd like to run similar tests as you did but using a refresh light and the single update / optimized refresh method.  Would like to compare that further to the performance of the flasher object as well as even the ramps method using the .triggersingleupdate such as you had used.

Sure, will send it here in a couple minutes...

3D stereo output is not working for me. If i checked "enable 3 D stereo" two pictures are on the screen, no real 3 D.
If i checked "enable Antialias 3 D" nothing happens.
 
Ich weiss nicht ob das schon einmal besprochen wurde.?

Not working as in it was working before? or...

Are you using a 3D tv or monitor? as that is what it is intended for, stereoscopic viewing with a specialized monitor.

Edited by koadic, 30 December 2013 - 08:21 PM.

[Xendo]

Is there a tutorial table anywhere that has demos of the new features?

[fuzzel]

ok next test phase in rev 836 I added RU and triggerSingleUpdate again and a rotation option for the X/Y/Z axis like primitives. Please test