View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003242Spring engineGeneralpublic2012-08-13 20:062013-01-02 04:15
Reportersprung Assigned ToKloot  
PrioritylowSeveritytrivialReproducibilityalways
Status resolvedResolutionfixed 
Product Version88.0 
Fixed in Version89.0.1+git 
Summary0003242: Shield rendering behaviour when !VisibleShield && VisibleShieldHitFrames
DescriptionPreviously, shields with VisibleShield = 0 and VisibleShieldHitFrames > 0 (and, of course, shieldAlpha > 0) used to be invisible, but they would appear when struck. Currently, shields with VisibleShield = 0 don't appear when struck even if they have VisibleShieldHitFrames > 0.

After a quick glance at the code, i suspect that line 51 in
rts/Sim/Projectiles/Unsynced/ShieldProjectile.cpp
might be responsible for that:

if ((allowDrawing = wd->visibleShield)) {
    //push the segments
}

So the segments aren't there at all, even if they could appear because of the visibleShieldHitFrames tag. I propose changing it into:

if ((allowDrawing = (wd->visibleShield || wd->visibleShieldHitFrames))) {
TagsNo tags attached.
Checked infolog.txt for Errors

Activities

Kloot

2012-08-14 00:21

developer   ~0009121

fixed, thanks for the reminder.

sprung

2012-10-10 21:04

reporter   ~0009253

Last edited: 2012-12-01 23:56

 The shields do render when hit now, however, they also do more unexpected things.

First of all, despite VisibleShield = 0, it now renders at the shieldAlpha value all the time even if not under fire. Line 270 is responsible for that, since it doesn't respect VisibleShield. I propose changing it from

segmentAlpha = shieldDef->shieldAlpha;
to
segmentAlpha = (shieldDef->visibleShield ? shieldDef->shieldAlpha : 0.0f);

Furthermore, when hit, it fades out to almost nothing (even with VisibleShield = 1) only to instantly come back to shieldAlpha, unlike the expected behaviour of fading straightaway to shieldAlpha (or 0, if visibleShield == 0).

The lines in question are 272 to 276. The code comments suggest that:
// when a shield is hit, increase segment's opacity to
// min(1, def->alpha + k * def->alpha) with k in [1, 0]

However, the code is actually
if (shield->hitFrames > 0 && shieldDef->visibleShieldHitFrames > 0) {
segmentAlpha += (shield->hitFrames / float(shieldDef->visibleShieldHitFrames));
segmentAlpha *= shieldDef->shieldAlpha;

This means that before it's hit, segmentAlpha equals shieldAlpha, after it is struck it becomes shieldAlpha*(shieldAlpha+1) - which isn't the shieldAlpha*2 the comments suggest, then it gradually fades to shieldAlpha*shieldAlpha - which again isn't what the comments say, and after the fade is done, it's instantly back to shieldAlpha.

I propose multiplying only the (hitFrames / maxHitFrames) part by shieldAlpha instead of the whole segmentAlpha (which is already shieldAlpha because of line 270).

That would be

if (shield->hitFrames > 0 && shieldDef->visibleShieldHitFrames > 0) {
segmentAlpha += (shield->hitFrames / float(shieldDef->visibleShieldHitFrames)) * shieldDef->shieldAlpha;

This achieves a gradual fade-back from twice the starting alpha to starting alpha.

As a side note, line 282:
if (!shield->isEnabled) return;
could be moved before line 263 so as to avoid calculating alpha for disabled shields.

abma

2012-10-16 01:22

administrator   ~0009259

Last edited: 2012-10-16 01:23

 @sprung:
time to use github / send pull requests / take kudos? ;) (sorry, can't say anyithing about your patch, as i'm not familar with opengl)

sprung

2012-12-25 14:55

reporter   ~0009534

I've added a pull request regarding the newer stuff to the repository on github.

Issue History

Date Modified Username Field Change
2012-08-13 20:06 sprung New Issue
2012-08-14 00:21 Kloot Note Added: 0009121
2012-08-14 00:21 Kloot Status new => resolved
2012-08-14 00:21 Kloot Fixed in Version => 89.0.1+git
2012-08-14 00:21 Kloot Resolution open => fixed
2012-08-14 00:21 Kloot Assigned To => Kloot
2012-10-10 21:04 sprung Note Added: 0009253
2012-10-10 21:04 sprung Status resolved => feedback
2012-10-10 21:04 sprung Resolution fixed => reopened
2012-10-16 01:22 abma Note Added: 0009259
2012-10-16 01:23 abma Note Edited: 0009259
2012-12-01 23:56 sprung Note Edited: 0009253
2012-12-25 14:55 sprung Note Added: 0009534
2012-12-25 14:55 sprung Status feedback => assigned
2013-01-02 04:15 jK Status assigned => resolved
2013-01-02 04:15 jK Resolution reopened => fixed