[Plagman]

That's how light works, though. What else do you propose?

[Fox]

I don't know, but the lights shouldn't oversaturate textures like that. It can look really bad.

Spoiler

Maybe it could work like "light works" in terms of illuminating the shading table, but when it comes to saturating the base texture, it would not add one light over another. Here is an example, on the left how Polymer works, and on the right what I am talking about:

[Diaz]

Whatever is done should be optional (a flag) - sometimes a single light is not bright enough and I do use the oversaturation on purpose quite often.

[Mblackwell]

Isn't that what things like spec maps are for? To change how a light is reflected or absorbed across a surface? The only way to get more accurate would be to include gloss maps too.

[Fox]

Spec maps would only serve to adjust the intensity to a very limited degree.

[DavoX]

When I select a group of sectors with RIGHT CTRL and then I enter 3d mode the floors and ceilings have this really ugly green palette, is that some how to know which sectors were selected? I find it to be a hassle because I can't change lighting properly with that palette.

[Helixhorned]

DavoX, on 06 May 2013 - 12:35 PM, said:

When I select a group of sectors with RIGHT CTRL and then I enter 3d mode the floors and ceilings have this really ugly green palette, is that some how to know which sectors were selected? I find it to be a hassle because I can't change lighting properly with that palette.

Yeah, when I coded that feature I made it conditional on shade preview ([']+[X]) instead of adding another switch. Are there situations where you are simultaneously highlighting sectors and editing lights? I assumed that the former would always be more or less temporary.

[Helixhorned]

Diaz, on 04 May 2013 - 02:03 AM, said:

The grass sprites I'm using on my mods would, IMO, look better if they weren't affected by Polymer lights and had a constant shade (or the shade I give them in Mapster). Would it be possible to add a new cstat flag to sprites so they aren't affected by Polymer lights? It would also vastly improve performance, as those sprites wouldn't need to be drawn as many times as the number of lights that affect them.

That's a good idea. A problem is where to add this flag, though. Since Polymer would read it, it will have to be on the engine side: either a sprite[].cstat bit or somewhere in spriteext[]. We don't want to have it like spriteext[].flags bit 16 (allow tsprite animation), since then you'll need actor code which sets that bit for a particular sprite. Then again, you'd most likely want to have this per-tile, but there's no access to a fitting member from CON at the moment.

[DavoX]

I didn't know it was conditional with shade preview. I would think that if someone wants to preview the shading and editing a bunch of sectors at the same time, it should be turned off. Maybe it can be switched to shading preview off mode?

[Diaz]

Helixhorned, on 06 May 2013 - 01:02 PM, said:

That's a good idea. A problem is where to add this flag, though. Since Polymer would read it, it will have to be on the engine side: either a sprite[].cstat bit or somewhere in spriteext[]. We don't want to have it like spriteext[].flags bit 16 (allow tsprite animation), since then you'll need actor code which sets that bit for a particular sprite. Then again, you'd most likely want to have this per-tile, but there's no access to a fitting member from CON at the moment.

Well, there's a sprite[].cstat flag for avoiding casting Polymer shadows, so I guess it makes sense to use another cstat flag for this. Is code run in EVENT_GAME for sprites that have statnum 0 considered actor code?

[Fox]

Yes, or at least in this context.

[Diaz]

In that case per-tile would be optimal, but if it can't be done, cstat shouldn't hurt much - in my case, and in the shrinker projectile case, they're both running code already (my grass fades in the distance), so setting a cstat would be trivial I guess...

In any case I think the performance benefit of not having to re-render many sprites many times would be greater than that of having them not run code. This probably applies to particle effects as well, such things would benefit enormously from not being affected by lights and in most cases don't really need to be.

[Mblackwell]

They should only have to be actors for long enough to set the cstat. Then you can change them to whatever you want. It would only be slow at map load.

[Diaz]

Yep, that makes sense. However, the fact that the map is much faster in-game (with the fade out code running) than in Mapster (with all sprites visible), or in-game without fade out code, makes me think it's the rendering itself that is slower.

[m210®]

I found a bug since rev3681

Tile 546 (CRACK1) doesn't explode after shot of projectile with PROJ_WORKSLIKE 65536 ( PROJECTILE_FLAG_RADIUS_PICNUM )
I use it for operate with htpicnum, which doesn't works without this flag

And second bug with sound I found, I leave at this thread with example
http://forums.duke4....ounds-in-eduke/

[fgsfds]

eduke doesn't save polymer checkbox state when using mods with custom .cfg name.

[fgsfds]

Also, add an ability to ignore megaton's grps. Through config or command line, doesn't matter. It causes lots of problems with mods that doesn't require Duke.

[Helixhorned]

M210, on 09 May 2013 - 11:52 PM, said:

I found a bug since rev3681

Tile 546 (CRACK1) doesn't explode after shot of projectile with PROJ_WORKSLIKE 65536 ( PROJECTILE_FLAG_RADIUS_PICNUM )
I use it for operate with htpicnum, which doesn't works without this flag

Thanks for reporting this apparent regression. The behavior is now the same as pre-r3681, but actually correct C code.

Since there were a couple of those in the last time, it may be of interest how these come about. In this case, in r3681, an out of bounds access (which results undefined behavior in C) in the CRACK* handling code was fixed, but changed the apparent behavior. From a strict point of view, no previous behavior was removed, because one can assume (and a C compiler does for optimization purposes) that undefined behavior does not happen. However, the change made some code not run that previously did. (But notably, only by chance. An equally valid course of action in the old version would have been a crash, for example.)
Another apparent regression in this category was the presumably "broken" disapprearance of the HUD weapon when constantly issuing 'tip'. Again, the problem here was, that originally, an array was read out-of-bounds (and not "merely" off by one in this case), invoking undefined behavior. To stress it once again: old versions were completely broken in that respect: doing that might have drawn the weapon squarely on the screen or crashed EDuke32. It was purely coincidence that it appeared to work.

The important message here is that for this reason, mods that stick with one particular EDuke32 version live on the unsafe side, to say the least. Especially large mods inevitably expose some undefined behaviors that were previously not hit. Ideally, development would proceed in a more branchy fashion -- one main branch with "stable" and "development" releases and occasional critical bugfix merges. But OTOH EDuke32 is probably not a that large project to warrant the increased complexity.

There's nothing much that can be done about that. C is and will probably always stay an unsafe language. Thankfully, nowadays there are projects permitting to check large classes of bugs, so hopefully at some point a state can be reached where we can deservedly call our code "stable", or at least close to that.

Quote

And second bug with sound I found, I leave at this thread with example
http://forums.duke4....ounds-in-eduke/

It's on my list. I would first need to write an equally entertaining post about why this happens, and then decide which of the various resolutions is preferred.

[Fox]

Phew, one of the things I hate the most about the editor is that new walls inherit the properties of adjacent ones. Is it possible to make new walls with standard picnum / cstat / repeat / offset?

[Diaz]

Anyone noticed that the Polymer aspect ratio option is messed up? Instead of displaying the aspect ratios, it displays either "custom" or "auto" and doesn't work as expected (try it and you will see what I mean)

[TerminX]

Fixed in r3769.

[LAW]

So can I kindly ask if that GetRawInputData error is unavoidable?

[Diaz]

TerminX, on 15 May 2013 - 06:54 AM, said:

Fixed in r3769.

That was quick, thanks

[TerminX]

LAW, on 15 May 2013 - 07:02 AM, said:

So can I kindly ask if that GetRawInputData error is unavoidable?

Windows 2000 is not supported, sorry.

[LAW]

TerminX, on 15 May 2013 - 08:09 AM, said:

Windows 2000 is not supported, sorry.

Dam, that's what I have feared of. Another reason to buy a new rig :/

Thanks for the info.

[DavoX]

I'm guessing it's a bug that SE 3 random lights after shot out don't flicker, they change the shade but don't flicker. I'm using a ceiling light and the pallette is 0.

[Helixhorned]

DavoX, on 16 May 2013 - 11:56 AM, said:

I'm guessing it's a bug that SE 3 random lights after shot out don't flicker, they change the shade but don't flicker. I'm using a ceiling light and the pallette is 0.

They start to flicker in 50% of the cases. No regression as far as I can see.

[DavoX]

I didn't know that Thanks.

[Helixhorned]

DavoX, on 04 May 2013 - 09:54 AM, said:

When I select a sprite in 2d mode and copy it while pressing the mouse button 1 the main original sprite won't move with the mouse, I have to select it again to keep making copies somewhere else.

I think we had this discussion once which IIRC even lead to a Mapster32 change. Let's see if I understand you right.

Suppose we highlight multiple sprites using RShift. (Highlighting one sprite is arguably pointless.) Then we press LMB and keep it held down. Next, we repeat pressing [Ins] and moving the duplicated sprites a bit off. Each time we duplicate the sprites, the old ones lose their highlighting, so we always have and equal amount of sprites highlighted at any time. This works for me as described. Where does it not behave as expected?

[DavoX]

No, what I mean is that when you press Insert the mouse should be free to move, but instead sometimes (not always) it freezes and you have to release the mouse button and press it again to move the sprite again. I think it's related to a limit on amount if buttons that you can have pressed at the same time.