RGB values seem to be wrong when alpha less than 1.0?

===============================

I first noticed this when building a shader that would allow you to view channels in various ways. I was going to post this in the "Construct engineering" forum, but after closer inspection it seems that this odd issue originates from Construct itself rather than the effects system, so I figured I'd ask here.

I may be doing something wrong, but it really looks like the alpha channel somehow corrupts the image data in the R, G, and B channels.

Specifically it's as if, for each pixel, the alpha value is being multiplied into the R, G, and B values. If that's really what's going on, it means that image data is being destroyed, as the color depth resolution in the R, G, and B channels is discarded in the presence of non-1.0 alpha values.

To see an example of what I mean, using the Construct image editor, try loading and saving an image with 0 to 1 alpha gradient. You should see all the R, G, and B channel values clamped to black as alpha approaches 0, irrespective of what data was originally in the R, G, and B channels.

At any rate, if the alpha is really being multiplied into the data, the R, G, and B channel information can't be recovered. For example, dividing the RGB values by alpha will approximate the original colors, but with lots of ugly banding, quantizing, and aliasing as you near low alpha areas. The original data is definitely not recoverable from that.

This may also explain another kind of glitchy behavior I've seen in the image editor, namely, that the soft edged brushes paint a kind of dirty aliased range of colors rather than just the color you selected.

To see this effect for yourself, in the image editor, pick a gray-green color (or any other desaturated color) and fill the whole frame, now get a large soft edged brush and draw the same color in the center of the frame. Obviously you should not see anything change, because the whole frame is already the color you're trying to draw with. Instead however, you will get a grungy mess of various colors loosely similar to the selected color. I think this may be because of the alpha glitch I mentioned above, causing waves upon waves of compounding rounding errors. That's sure what it looks like anyway.

So, my question is, is this weird RGB behavior really what it looks like, and if so is there a work around that would allow the RGB values to remain in tack while at the same time using alpha?

Please let me know if this appears to be a real issue, or if I just overlooked something simple, or am missing a setting somewhere that resolves the odd alpha behavior mentioned above.

Thanks!

I've been looking over the Microsoft HLSL reference site you mentioned.

I'm glad I asked before investing a lot of time in trying to build a bunch of convolution stuff.

I've built a few shaders that are a bit more straightforward thus far, and I'm getting a feel for HLSL. (albeit rather slowly)

Do you know off hand if loops are unrolled at compilation? Or, likewise, if all the instructions in the branches of an "if" statement count as taking up instruction slots? It seems like they must, but I'm not sure what kind of optimization happens at compile time.

Thanks again.

I have a few question regarding effects coding, (which I'll number for ease of reference).

Q1: How much do I need to know about the pixel shader 2.0 limitations to code shaders that rely on convolutions?

Q2: Is there any good online reference for what you can and can't do in pixel shader 2.0.

I've read through the Construct Wiki page on shaders, and that helped with the Construct specific stuff, but it doesn't mention much about the actual language.

Q3: Is DirectX's "HLSL" language what construct shaders are coded in? (i.e. Will this Wikipedia page "http://en.wikipedia.org/wiki/HLSL" help me at all?)

While I'm familiar with a variety of image compositing and processing algorithms, I have no background in coding pixel shaders. I'm not even sure if "pixel shader 2.0" is a language or a target machine code standard, or what.

There are a number of effects I'm interested in building, and several rely on various forms of convolution, and particularly blurs.

After spending just a little time coding effects, I've run into a number of errors resulting from registry allocation, overflows, and illegal computation complexity. Which reminds me of my last question.

Q4: Is it possible to make shaders that distribute their computation complexity over multiple passes, if the algorithm is to complex for a single pass?

Okay, after doing a bit of analysis of Construct's interaction with the registry, I think I may have found out where the data is stored.

"HKEY_CURRENT_USER\Software\Construct\Construct\ProfUIS\Profiles\Construct"

There are three keys under that key named "ControlBar", "Customization", and "PaintManager". Each of those keys holds a block of data in the form of a list of binary values, but nothing human readable.

Construct writes to these blocks immediately upon closing, (which I assume is why if Construct crashes after you make changes to the preferences, but before closing it properly, all your changes are lost).

Because the data is in the registry, it should be simple enough to back up and restore, assuming it really is the customization data I'm looking for. It might even be possible to build a ".reg" file to automate that process.

That still doesn't explain why I keep losing my custom keys and such, but if I can restore them with a few clicks it will make the problem a bit more manageable.

I'll let you know how this turns out after I try it.

--------------------- Edit:

=== Success!

Backing up and restoring the three keys ("ControlBar", "Customization", and "PaintManager") do indeed back up and restore the Construct preference customization.

I've tested it several times, under a few different circumstances, and it seems to work perfectly.

=== How to do it:

• - Preparation:

Before doing anything, BACK UP YOUR REGISTRY!

Use the freeware tool "Erunt", or the built in Windows System Restore utility to create a restore point.

Needless to say,

don't fiddle with the registry unless you know what you're doing.

• - Backing up Preferences:

Construct stores this data in the registry, under the following key.

"HKEY_CURRENT_USER\Software\Construct\Construct\ProfUIS\Profiles\Construct"

You can use regedit, to export the "Construct" key as a ".reg" file. That exported ".reg" file is essentially a full backup of all your hotkeys and quick-bar preferences.

• - Restoring Preferences:

To restore your settings, simply navigate to the "Construct" key, and delete the three sub-keys, "ControlBar", "Customization", and "PaintManager". (Do NOT delete the "Construct" key.)

Alternatively, you can run a ".reg" file like the one below to remove the sub-keys.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Construct\Construct\ProfUIS\Profiles\Construct]

[-HKEY_CURRENT_USER\Software\Construct\Construct\ProfUIS\Profiles\Construct\ControlBar]
[-HKEY_CURRENT_USER\Software\Construct\Construct\ProfUIS\Profiles\Construct\Customization]
[-HKEY_CURRENT_USER\Software\Construct\Construct\ProfUIS\Profiles\Construct\PaintManager][/code:39nyml6m]

Now run the ".reg" file you made during the "Backing up Preferences" stage earlier.
All your preferences should be restored.
That's it!

Near as I can tell, all the persist files are 1KB xml files with a ".persist" extension. They can be opened in notepad and all appear to have an internal structure along the lines of the example below.

<?xml version="1.0" ?>
<persistence>
    <windows>
        <layout name="Layout 1" scroll-x="192" scroll-y="110" active="yes" />
    </windows>
</persistence>[/code:1u8x9blp]

So unfortunately, it doesn't look like the persist files are what I'm looking for. Thanks for the suggestion though.

I'm using v0.99.92.

It seems like every few days, I loose all my custom hotkeys. This just started happening within the last month or so. I have a lot of custom keys, so it's a bit of a hassle to reconfigure Construct every time my customizations vanish. This also happened with 0.99.91 at least once, (as I remember taking that opportunity to install 92.)

Is there a way to back up the hotkeys and other preferences? It doesn't seem like there is any built in save and load preferences system, but I figure the information has to be stored in a file somewhere, so perhaps I can simply back up that file.

The problem isn't that bad, as I have all my configurations written down in a text file, and it's just a matter of going through that list and setting everything up again. But if there's a way to avoid that, it would be nice.

Any advice would be appreciated. Thanks.

====== Edit:

Backup Solution:

I did try using RGB(rrr,ggg,bbb) expressions, and I got the same results. Interestingly, turning the opacity from 100 to 255, caused the points to display correctly for a few runs, but eventually I was back to only seeing the red channel. The "Draw line" and "Fill rectangle" actions seem to work fine for drawing points of any color though.

I might just be doing something wrong, but the "Draw Point" action for the Canvas object seems to treat the green and blue color components of the color parameter as zero, regardless of the color I pick.

That is, if I try to draw a white (255,255,255) point, I get a red (255,0,0) point.

Likewise a gray point (128,128,128), is drawn as a dark red (128,0,0) point.

A blue (0,0,255) point is drawn as a black (0,0,0) point.

It's as if the blue and green values are being discarded.

Am I just doing something wrong, or is this a known issue? I couldn�t find another mention of it in the forums.

Wow! "Grab Layout".

I can't believe I didn't see that.

Awesome. Thanks, I'm definitely going to try that out.

Thanks for the reply, I just noticed after posting that you can copy from a canvas object with the "Copy from sprite" action, but reading your response it sounds like you're saying you can get the color at an arbitrary point in the layout.

For the project I'm working on, getting color data out of a canvas object might be all I need, but I'm still curious if it's possible to get the color at an arbitrary point in the layout, as it would grant me quite a bit more flexibility.

You said you can use the canvas to "capture the point you're selecting". Does this mean there is a way to capture a point in the layout rather than merely pasting an object into the canvas? Or would you have to paste every object into the canvas and then get the resulting color at the desired point. If that's the case, I can see what you mean when you say it's slow. As it is, just moving an image from a canvas to the image manipulator seems to hit the CPU a bit hard.

Is there a way to get the RGB color value at a given point on the layout, or at a given point in a canvas.

I'm interested in getting the RGB color clicked, in the standard eyedropper fashion.

I know you can get this kind of information from the image manipulator, but I'm not sure if there is a way to get the layout or canvas graphical data into the image manipulator.

Hi Ashley, I did read the bug report procedure, I just wanted to be sure I had actually found a bug first before submitting something to the tracker. So I hope I didn't cause any problems. In any case, I just tried making a Source Forge account, and I have yet to receive the activation email. It has been about a half hour, so I think something went wrong. I have a screen capture of the registration page, so I know I typed the email address correctly, but there is still no email. I'll try contacting their tech support tomorrow.

Thanks for the suggestion PixelRebirth, however I actually get the same results when using the "Append text" action. I also get the same results when concatenating a string that contains a new line. Pretty weird...

In answer to your question David, I am currently running 0.99.62, which Construct seems to insist is up to date, but I see that there is indeed a 0.99.7 version listed on Source Forge. It says it has zero downloads though which is a bit odd. Is 0.99.7 stable?

At any rate, thanks for the feedback everyone, I'll see about getting the Source Forge problem straitened out, and try posting the bug tomorrow.