A question or two
If a ship has both a weapon glow, and a engine glow, possibly even a running light glow, do they blend or does one lay over top of another? I am workin' on making a weapon glow for the Vell-Os Javelin, possibly the Dart and Arrow later, but that is beside the point. The Jav's engine glow would overlap with the weapon glow I am working on, and I was thinking about making the Jav pulsate a bit too (Running Lights). Would any of those interfer with another?
I believe that glows are combined over the base image by additive or screen (which is multiplicative but relatively to white) blending. Anyway, know that black pixels of glows won't modify the base image, everything else with only lighten the base image (i.e. you don't have to worry about black pixels around the lights being applied on top of the ship, leaving a ghosting effect, just check the Pegasus running lights). Also, you don't have to worry about the order with which they are applied, the blending algorithm always gives the same result regardless of order. The exception however is I think the alt image (for instance the central rotating part of the Thunderforge), which I believe is simply applied on top of the base one, masking pixels behind, then only are other layers applied with blending.
If you're on a Mac, you can use ViewRLE to get what I think is a reasonable preview of the in-game behavior (it uses additive blending just like NovaTools does, when I think the game uses screen blending, but the difference can hardly be spotted).
On another note, why is it that when you cloak a thunderforge, the alt image turns like light blue? Its really weird, but helpful in finding where you are on the screen 
How does screen blending work?
I don't know the official name (if ever there is such a name), that's how the GIMP calls it, at least. It's just 1-(1-intensityA)(1-intensityB), or also intensityA + intensityB - intensityAintensityB. I shall add that I have implemented this blending mode in ViewRLE, along with AltiVec and SSE2 version of the decoding engine for better performance (since screen blending, with its multiplication, is more processor-intensive), though it needs some more work before I release it.
That cloak question reminded me of an issue I once faced back when I was almost making a TC. For some reason, with my custom ships, cloaking transparancy wouldn't work quite right. For the most part, the ship would become cloaky like normal, but then there were always horizontal lines, usually 1 or 2 pixels thick, of varying length, that would go across the ship that were still normal, or lighter, and they would vary with each rotational frame (and I believe they would be consistent for each rotational frame, even afer re-loading the game and whatnot). Does anybody know a reason for that?
@pisketch, on Nov 26 2006, 10:31 PM, said in Of Glows and such:
While I can't really help with your question, I would like to just say that I would really love to see a nice weap glow for the Javelin. Man, it would be awesome.
Well, you might get to see one. Now, whether it is a nice one or not is another story... 
I have done the glow for the Dart and the Javelin, but have yet to do the Arrow. They way I am doing this is relatavely simple, but it looks quite nice, in my oppinion. The weapon glow will take a bit more work, and sence the work is from me, it will probably look fairly poor (when it come to creating graphics from scratch, you might want to look elsewhere, but it its modding graphics, I'm your man!).
@fnoigy, on Nov 27 2006, 03:55 PM, said in Of Glows and such:
<Snip> For some reason, with my custom ships, cloaking transparancy wouldn't work quite right. <Snip> Does anybody know a reason for that?
It might be that it was a particular color that was causing the issue, other than that I haven't the foggiest idea.
@fnoigy, on Nov 28 2006, 09:55 AM, said in Of Glows and such:
Does anybody know a reason for that?
Ooh, I can answer that - it's basically just a bug in Nova's RLE handling. MC's inferior RLE encoding actually means the issue is avoided while EnRLE's encoding may cause the problems. I'm not sure which method EVNEW uses. You can also avoid it by using higher detail on your sprites
@guy, on Nov 27 2006, 05:18 PM, said in Of Glows and such:
Ooh, I can answer that - it's basically just a bug in Nova's RLE handling. MC's inferior RLE encoding actually means the issue is avoided while EnRLE's encoding may cause the problems.
Is THAT all it takes to get rid of that blasted artifact?! :blink:
I can't believe I never tried just using PICTs for those graphics- if I had I'm sure I would have figured out that the problem was in the RLE handling, and that MC would likely be a valid work-around. If this works, EV:G and SoTC may yet be able to use color, and several other projects could get somewhat higher-quality graphics.
Edwards
@guy, on Nov 27 2006, 07:18 PM, said in Of Glows and such:
MC's inferior RLE encoding actually means the issue is avoided while EnRLE's encoding may cause the problems.
Irony of ironies...
Incidentally, what is the problem? I'm assuming it's improper handling of a token, but which one? Pixel data? Skip pixels? Solid color fill? Perhaps I could write an encoder that makes RLEs as efficient as possible without the possibility any artifacts. Right now I have a working decoder, and with a little effort an encoder wouldn't be too tough (almost easier than the decoder, actually).
@edwards, on Nov 28 2006, 02:56 PM, said in Of Glows and such:
Is THAT all it takes to get rid of that blasted artifact?! :blink:
Yeah, I talked to Zacha about it while we were testing those Quantum beams. I'm sure I emailed you and Q about the solution, though it may not have been until after it was released.
@orcaloverbri9, on Nov 28 2006, 03:07 PM, said in Of Glows and such:
Incidentally, what is the problem?
Solid colour fill. I was hoping EnRLE could be fixed if the source code became available but that may never happen so if you could write that encoder that would be awesome 
. Basically it just needs to make sure that colour runs are only used in transparent areas, ie. all the black around the outside can be compressed into runs but none of the actual sprite. The decoder would be great too since DeRLE suffers the same problem and you get black streaks on the decoded masks.
This post has been edited by Guy : 27 November 2006 - 09:29 PM
@guy, on Nov 27 2006, 09:12 PM, said in Of Glows and such:
Yeah, I talked to Zacha about it while we were testing those Quantum beams. I'm sure I emailed you and Q about the solution, though it may not have been until after it was released.
Solid colour fill. I was hoping EnRLE could be fixed if the source code became available but that may never happen so if you could write that encoder that would be awesome . Basically it just needs to make sure that colour runs are only used in transparent areas, ie. all the black around the outside can be compressed into runs but none of the actual sprite. The decoder would be great too since DeRLE suffers the same problem and you get black streaks on the decoded masks.
The decoder is actually part of a project I'm working on...the encoder will eventually be part of it too, but for now all it actually does is display the RLEs in a specific context.
It's actually a personal effort, but I'm not telling. It's something that OS X developers are conspicuously lacking (i.e. unlike some of my other apps, very useful :p).
