| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0003242 | Spring engine | General | public | 2012-08-13 20:06 | 2013-01-02 04:15 | ||||
| Reporter | sprung | ||||||||
| Assigned To | Kloot | ||||||||
| Priority | low | Severity | trivial | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | 88.0 | ||||||||
| Target Version | Fixed in Version | 89.0.1+git | |||||||
| Summary | 0003242: Shield rendering behaviour when !VisibleShield && VisibleShieldHitFrames | ||||||||
| Description | Previously, 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))) { | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
Kloot (developer) 2012-08-14 00:21 |
fixed, thanks for the reminder. |
|
sprung (reporter) 2012-10-10 21:04 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 (administrator) 2012-10-16 01:22 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 (reporter) 2012-12-25 14:55 |
I've added a pull request regarding the newer stuff to the repository on github. |
| Notes |
| 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 | View Revisions |
| 2012-12-01 23:56 | sprung | Note Edited: 0009253 | View Revisions |
| 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 |
| Issue History |