"Paper cuts" -- minor bugs and annoyances "Post problems here that could be fixed with a few minutes of effort"
#572 Posted 06 May 2013 - 01:19 AM
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:
This post has been edited by Fox: 06 May 2013 - 01:26 AM
#573 Posted 06 May 2013 - 01:44 AM
This post has been edited by Diaz: 06 May 2013 - 01:46 AM
#574 Posted 06 May 2013 - 06:36 AM
#575 Posted 06 May 2013 - 06:41 AM
#576 Posted 06 May 2013 - 12:35 PM
#577 Posted 06 May 2013 - 12:52 PM
DavoX, on 06 May 2013 - 12:35 PM, said:
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.
#578 Posted 06 May 2013 - 01:02 PM
Diaz, on 04 May 2013 - 02:03 AM, 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.
#579 Posted 06 May 2013 - 01:41 PM
#580 Posted 06 May 2013 - 02:31 PM
Helixhorned, on 06 May 2013 - 01:02 PM, said:
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?
#582 Posted 06 May 2013 - 03:06 PM
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.
This post has been edited by Diaz: 07 May 2013 - 12:33 AM
#583 Posted 06 May 2013 - 04:34 PM
#584 Posted 06 May 2013 - 10:32 PM
This post has been edited by Diaz: 06 May 2013 - 10:33 PM
#585 Posted 09 May 2013 - 11:52 PM
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/
This post has been edited by M210: 09 May 2013 - 11:53 PM
#586 Posted 11 May 2013 - 02:19 AM
#587 Posted 11 May 2013 - 09:37 AM
#588 Posted 11 May 2013 - 01:38 PM
M210, on 09 May 2013 - 11:52 PM, said:
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
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.
#589 Posted 12 May 2013 - 04:26 PM
#590 Posted 15 May 2013 - 03:39 AM
#592 Posted 15 May 2013 - 07:02 AM
#593 Posted 15 May 2013 - 07:31 AM
#594 Posted 15 May 2013 - 08:09 AM
LAW, on 15 May 2013 - 07:02 AM, said:
Windows 2000 is not supported, sorry.
#595 Posted 15 May 2013 - 12:48 PM
TerminX, on 15 May 2013 - 08:09 AM, said:
Dam, that's what I have feared of. Another reason to buy a new rig :/
Thanks for the info.
This post has been edited by LAW: 15 May 2013 - 12:49 PM
#596 Posted 16 May 2013 - 11:56 AM
#597 Posted 16 May 2013 - 12:17 PM
DavoX, on 16 May 2013 - 11:56 AM, said:
They start to flicker in 50% of the cases. No regression as far as I can see.
#599 Posted 24 May 2013 - 08:16 AM
DavoX, on 04 May 2013 - 09:54 AM, said:
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.