[Plagman]

I think you have to press Ctrl-P for it to toggle parallaxing modes, it shouldn't do it randomly.

[Diaz]

I believe I have asked this before, but is it possible to create Polymer spotlights that don't cast shadows?
Would be quite useful for optimization, or for using the spotlights as texture projectors only. Thanks!

[Plagman]

I think there's already a flag to achieve that internally, the issue is how to specify it using the SE. It was already super hackish to cram all the light members into the SE members like that and I think we're out of space by now. If there's a member that could be used for that then I it would be trivial.

[Danukem]

Plagman, on 16 April 2012 - 02:46 PM, said:

I think there's already a flag to achieve that internally, the issue is how to specify it using the SE. It was already super hackish to cram all the light members into the SE members like that and I think we're out of space by now. If there's a member that could be used for that then I it would be trivial.

AFAIK pal is not used for anything (except in DukePlus), since the light color is determined by xvel/yvel/zvel. I suppose clipdist could be used as well.

[Mblackwell]

Couldn't just use an htflag? Though not sure if those can be set from mapster.

[Diaz]

Pal would be the easiest IMO. It's not used for anything. DukePlus uses pal 1 and 2, but the no shadow flag could be set for pal 3, for example, and it wouldn't break anything.

[Danukem]

Diaz, on 16 April 2012 - 07:13 PM, said:

Pal would be the easiest IMO. It's not used for anything. DukePlus uses pal 1 and 2, but the no shadow flag could be set for pal 3, for example, and it wouldn't break anything.

Or pal 4, since that would make it visually obvious that there was something different about that SE.

[Jimmy]

I usually use Pal 3 to tag miniboss Battlelords. Other people may as well, it's just a thought.

[Fox]

That's not a good idea, since there is one instances which the CON sets pal 21 to the Battlelord, which is the palette it will return to after it is frozen.

[Danukem]

Are you guys smoking something? We were talking about pal on an SE50, not on battlelords and whatnot.

[Diaz]

Yeah, we'd use a different pal for the SE itself, not for objects we don't want to cast shadows individually

[Plagman]

Sure, I guess; I hate to pile more hacks on top of hacks, but whatever. I'll try to get it hooked up to the pal bit.

[Diaz]

That's awesome! Sure it will be great to be able to project textures and having spot-shaped lights that don't kill performance... thanks a lot

[Helixhorned]

Why not use cstat bit 2⁴ (wall-aligned)? It's one bit we need, after all, so when somebody comes around requesting a property that really needs a scale, pal will be available. It might mildly break existing maps if people wall-aligned their SE50s for some reason (e.g. to make their direction obvious).

[Danukem]

Helixhorned, on 17 April 2012 - 10:17 AM, said:

Why not use cstat bit 2⁴ (wall-aligned)? It's one bit we need, after all, so when somebody comes around requesting a property that really needs a scale, pal will be available. It might mildly break existing maps if people wall-aligned their SE50s for some reason (e.g. to make their direction obvious).

People sometimes wall-align sprites by accident, but on SE50 that's probably very rare.

[Hendricks266]

Mblackwell, on 16 April 2012 - 07:06 PM, said:

Couldn't just use an htflag? Though not sure if those can be set from mapster.

Nope, hittypes and spriteext are not stored in maps.

Fox, on 16 April 2012 - 08:04 PM, said:

That's not a good idea, since there is one instances which the CON sets pal 21 to the Battlelord, which is the palette it will return to after it is frozen.

Pal 3 is perfectly fine. The boss code always does "ifspritepal 0 else" for miniboss checks so pal 3 and pal 21 work equally.

[Fox]

That's for ifspritepal command, but for spritepal it uses a value of 21.

state boss1code

  ifaction ABOSS1FROZEN
  {
    ifcount THAWTIME
    {
      ai AIBOSS1SEEKENEMY
      spritepal 21
    }
    else
      ifcount FROZENDRIPTIME
    {
      ifactioncount 26
      {
        spawn WATERDRIP
        resetactioncount
      }
    }

[Hendricks266]

Yes, but that does not make a difference. Pal 3 will just become pal 21. It is not a reason to avoid using pal 3.

[Jimmy]

Trooper Dan, on 16 April 2012 - 09:07 PM, said:

Are you guys smoking something? We were talking about pal on an SE50, not on battlelords and whatnot.

Doh! I somehow misconstrued the conversation. Continue!

[Diaz]

What the hell, lol....

I was suspecting you could have loads of Polymer lights as long as their radius was small and the number of objects affected low, but I wasn't expecting it to be true to this extent...

Just look at the number of lights and the framerate....

Attached thumbnail(s)

• 

[Tea Monster]

Holy crap! So what has everyone else been doing wrong then?

[Diaz]

Tea Monster, on 22 April 2012 - 02:36 PM, said:

Holy crap! So what has everyone else been doing wrong then?

I guess using higher radius lights, which causes many objects to be redrawn for each light; that's assuming I'm understanding how lights work, of course.

[Danukem]

Diaz, on 22 April 2012 - 02:40 PM, said:

I guess using higher radius lights, which causes many objects to be redrawn for each light; that's assuming I'm understanding how lights work, of course.

In that shot you have a simple map area with some models (the arcade machines). My understanding is that the complexity of the map, and especially having lots of child sectors, greatly reduces performance and increases the amount of light calculations. On the other hand, Polymer handles models very well. So my guess is that the good performance there has more to do with the map than the radius of the lights.

[Fox]

But the map itself is converted in a model of sort. But I guess a detailed map is a complex 3D structure no matter what.

[Mblackwell]

Note: The number of objects visible across sectors slows the engine down regardless of the number of polygons in them. 1024 objects with 10k polys will be slower than 100 objects with 102,400 polys. Sounds strange maybe but the engine (Polymer) is a beast when it comes to rendering each polygon, it's the separate objects that make more of a difference in speed.

[Tea Monster]

Is there any way to run some kind of "pre-compile" on the map while the level is loading? Maybe you could run this as a seperate process before hand?

[Danukem]

Tea Monster, on 22 April 2012 - 05:03 PM, said:

Is there any way to run some kind of "pre-compile" on the map while the level is loading? Maybe you could run this as a seperate process before hand?

BUILD maps don't ever get compiled. It's one of the best features of the engine and allows for great versatility and ease of mapping. The ability to change things on the fly in-game is also pretty awesome. When you realize that all the Polymer lights have to be completely dynamic with nothing compiled, it makes the performance challenges a little less surprising, no?

[Diaz]

Trooper Dan, on 22 April 2012 - 02:47 PM, said:

In that shot you have a simple map area with some models (the arcade machines). My understanding is that the complexity of the map, and especially having lots of child sectors, greatly reduces performance and increases the amount of light calculations. On the other hand, Polymer handles models very well. So my guess is that the good performance there has more to do with the map than the radius of the lights.

I believe that every object needs to be drawn once for each light that hits it. So if an object is hit by 10 lights it will have to be rendered 10 times.
A light with a large radius means more objects will be affected, and several lights with a large radius means you're redrawing the entire scene several times. So it doesn't depend on either the amount of objects or the radius of lights, but rather a combination of both. I have several more complex scenes where the framerate still stays above 60.

And yes, when you notice how fast Polymer is drawing models (which are the basic building block of today's engines) and you realize that every light is dynamic, the renderer doesn't look to be badly optimized at all!

[Fox]

I wonder, is there any planning to include all the Sector Effectors from Shadow Warrior in EDuke32?

[Master Fibbles]

I think all of the tags were at some point integrated but it is kind of moot. TROR makes the system in Shadow Warrior useless (and it was buggy).