Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Semi-transparent colors in sprites turn black on -Dnext #2026

Closed
starry-abyss opened this issue Jan 9, 2017 · 8 comments
Closed

Semi-transparent colors in sprites turn black on -Dnext #2026

starry-abyss opened this issue Jan 9, 2017 · 8 comments

Comments

@starry-abyss
Copy link
Contributor

starry-abyss commented Jan 9, 2017

  • Flixel version: dev
  • OpenFL version: 3.6.1
  • Lime version: 2.9.1
  • Affected targets: neko, windows

Code snippet reproducing the issue:

package;

import flixel.FlxSprite;
import flixel.FlxState;
import flixel.util.FlxColor;

class PlayState extends FlxState {
    var sprite:FlxSprite;
    
    override public function create():Void {
        super.create();
        sprite = new FlxSprite();
        sprite.makeGraphic(300, 300, FlxColor.RED & 0x88FFFFFF);
        add(sprite);
        bgColor = FlxColor.GREEN;
    }
}

If I remove the & 0x88ffffff part, the sprite is plain red (which is good) on both legacy and next.


Observed behavior:
(next)
default

Expected behavior:
(legacy and Flash)
default

@IBwWG
Copy link
Contributor

IBwWG commented Feb 1, 2017

I'm getting this also on linux64 with haxe 3.4.0, haxeflixel 4.2.0, openfl 3.6.1, lime 2.9.1.

lime test neko:

limewithoutdnext

lime test neko -Dnext:

limednext

As you can see, the effect is dramatic as soon as you're 1/255th less than full alpha, and gets worse from there.

Code used:

package;

import flixel.FlxState;
import flixel.FlxSprite;
import flixel.util.FlxColor;

class PlayState extends FlxState
{
	override public function create():Void
	{
		super.create();
		for (i in 0...256) {
			var box = new FlxSprite();
			var colour = new FlxColor(FlxColor.WHITE);
			colour.alpha = 256 - i;
			box.makeGraphic(10, 120, colour);
			box.setPosition(10 * (i % 64), 120 * Std.int(i / 64));
			add(box);
		}
	}
}

@Tembac
Copy link

Tembac commented Feb 1, 2017

This is maybe a problem with openfl 3.6.1.

I had a similar problem before using only openfl. It was supposedly fixed october 2015: http://community.openfl.org/t/several-problems-with-swf-from-fla-and-windows-target/6628

@Gama11
Copy link
Member

Gama11 commented Feb 1, 2017

@Tembac OpenFL 3.6.1 should have that fix then, it was released 2016-03-29.

@Tembac
Copy link

Tembac commented Feb 1, 2017

Ups, I have my years mixed :D jaja.

@Gama11
Copy link
Member

Gama11 commented May 21, 2017

@Beeblerox I wanted to see whether this will be fixed by #2068 - it seems the color of the sprite in the upper left is somewhat off on the FlxMaterial branch:

vs Flash (expected):

@Beeblerox
Copy link
Member

@Gama11 i will look into it.

@Beeblerox
Copy link
Member

@Gama11 i think the problem on my branch is caused by shaders which suppose to work with premultiplied alpha. So in order to fix this i need to add new property to material and chose shader appropriately.

You can check it yourself if you change DEFAULT_FRAGMENT_SOURCE constant it flixel.graphics.shaders.quads.FlxTexturedShader class to:

	public static inline var DEFAULT_FRAGMENT_SOURCE:String = 
			"
			varying vec2 vTexCoord;
			varying vec4 vColor;
			varying vec4 vColorOffset;
			
			uniform sampler2D uImage0;
			
			void main(void) 
			{
				vec4 color = texture2D(uImage0, vTexCoord);
				
				vec4 result = color * vColor + vColorOffset;
				result = clamp(result, 0.0, 1.0);
				
				gl_FragColor = result;
			}";

@Gama11
Copy link
Member

Gama11 commented Apr 19, 2018

This looks good to me with OpenFL 8:

@Gama11 Gama11 closed this as completed Apr 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants