0000896: Additive rendering erronously handles pure colors

Chat on our Discord Server Get the latest version: 3.2
Source Code

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000896

Zandronum

[All Projects] Bug

public

2012-06-24 15:09

2012-07-07 19:18

Reporter

Bloax

Assigned To

Priority

normal

Severity

tweak

Reproducibility

always

Status

closed

Resolution

no change required

Platform

Microsoft

Windows

OS Version

XP/Vista/7

Product Version

98d

Target Version

Fixed in Version

Summary

0000896: Additive rendering erronously handles pure colors

Description

When an actor with the "Add"itive Renderstyle has a sprite with a pure color range (Eg. The RGB(0,0,0)-RGB(0,255,0) range) - they are handled incorrectly.

Or rather, they may be handled "correctly" - but the result is VERY ugly.

(And yes, I labeled this "Tweak" because the fix would quite literally be a tweak.)

Steps To Reproduce

Run AdditiveTest2.pk3, and summon "Testshot" for an example with the pure green range, and "Testshot2" for one with the red one.

They will both clip at the maximum of their color range (Eg. With green at RGB(0,255,0)) And stop increasing in "optical" brightness, since pure red, green or blue aren't the brightest colors one can see. (That is pure white.)

This is most likely a problem with the algorithm (I guess?) that handles the addition of the colors.

Additional Information

Fixing this may very well slow down additive rendering (IFs aren't the lightest of operations), but it'd make things less ugly.

As for how fixing this might work, -I THINK- that having an If (AddColor == OldColor && AddColor != White) and then somehow add the OldColor value to the OTHER colors (Instead of adding x Green to 255 Green, add it to Red/Blue).

Of course I'm silly and I have no idea how this stuff works. But in my little fantasyland bubble of joy, that somehow makes sense.

Attached Files

AdditiveTest2.pk3 [^] (3,276 bytes) 2012-06-24 15:09

Relationships

Notes
(0003840) Torr Samaho (administrator) 2012-06-24 15:27	Is this any different in GZDoom 323?

(0003848) Bloax (reporter) 2012-06-24 22:28	It's exactly the same. And my best guess is that it's caused by the way the addition is done.

(0003857) Torr Samaho (administrator) 2012-06-26 20:41	Is it still the same in the latest (G)ZDoom version?

(0003861) Bloax (reporter) 2012-06-27 00:23	Exactly the same still.

(0003869) Edward-san (developer) 2012-06-29 23:56	What about latest gzdoom build?

(0003904) Bloax (reporter) 2012-07-06 04:54	Boo, slow reply. But yes, it's exactly the same all around the house. And even outside of it. (Photoshop, despite its' usually weird, hacky ways - also has this issue.)

(0003908) Torr Samaho (administrator) 2012-07-07 19:18	Well, if it's the same in Photoshop, I'm pretty sure it's working as intended. If you still think it's a bug, please report it at the ZDoom/GZDoom forum.

**Issue Community Support**
This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	carpathia
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2012-06-24 15:09	Bloax	New Issue
2012-06-24 15:09	Bloax	File Added: AdditiveTest2.pk3
2012-06-24 15:27	Torr Samaho	Note Added: 0003840
2012-06-24 15:28	Torr Samaho	Status	new => feedback
2012-06-24 22:28	Bloax	Note Added: 0003848
2012-06-24 22:28	Bloax	Status	feedback => new
2012-06-26 20:41	Torr Samaho	Note Added: 0003857
2012-06-27 00:23	Bloax	Note Added: 0003861
2012-06-29 23:56	Edward-san	Note Added: 0003869
2012-07-06 04:54	Bloax	Note Added: 0003904
2012-07-07 19:18	Torr Samaho	Note Added: 0003908
2012-07-07 19:18	Torr Samaho	Status	new => closed
2012-07-07 19:18	Torr Samaho	Resolution	open => no change required

Questions or other issues? Contact Us.

Links

Doom and Doom II are the property of id Software.