Page 1 of 1
Blue shadow
Posted: Fri Oct 21, 2016 21:58
by Blue Shadow
(Sorry. I couldn't resist!)
Tested with: 0.2pre-30-g9cf9cc1 (64-bit)
Specs:
- Windows 10 Home Single Language 64-bit (10.0, Build 14393)
- Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz (8 CPUs), ~2.4GHz
- AMD Radeon HD 7600M Series
Using the true color renderer, the Shadow renderstyle appears blue instead of black. You can test this on spectres by setting the fuzz effect to "Shadow" from the Display Options menu.
- blue_spectres.png (283.5 KiB) Viewed 3801 times
Re: Blue shadow
Posted: Fri Oct 21, 2016 22:14
by Rachael
You really weren't kidding with that title...
I'll look into this, but I haven't seen it before. Would you mind posting your config?
Also, your startup log as well - (same as it is for GZDoom, just +logfile startuplog.txt).
Re: Blue shadow
Posted: Fri Oct 21, 2016 22:21
by dpJudas
Pinky got the blues.
Re: Blue shadow
Posted: Fri Oct 21, 2016 23:22
by Blue Shadow
Both the config and startup log are here:
I also tested it with a fresh ini while keeping default engine settings - I get the same thing.
Re: Blue shadow
Posted: Fri Oct 21, 2016 23:25
by Rachael
Hmm - another Ivybridge problem - but this one's not crashing.
I'm starting to think LLVM doesn't know what the hell to do with that CPU. Perhaps a directive should be put in place to force LLVM to compile for an older CPU?
While we're on the subject - what does QZDoom do when you view other transparent effects? I'm particularly interested in GZDoom-type maps, like Stronghold's MAP99.
Re: Blue shadow
Posted: Sat Oct 22, 2016 0:26
by dpJudas
The ivybridge crash on this forum actually crashed before reaching the LLVM part (he quoted a crash in DrawColumnHorizRGBACommand, which is plain C++).
Adding a directive that can override the target CPU should be easy - we just need some way to specify a custom string to
https://github.com/raa-eruanna/qzdoom/b ... s.cpp#L480.
I really hate that I had to add that vectored exception handler because it makes it write drawer errors for 9 out of 10 ZDoom rendering bugs. Usually ZDoom calculates some garbage, then the drawer dies trying to do as instructed. Even though I did add some checks, not all cases are covered because ZDoom loves to pass around pointers. Checking if a pointer is valid and in the right range is a bit tricky when its a texture source.
On the subject of the blue pinky, what's probably going on is that somehow something got alpha in the blue channel. What happens is that ZDoom's renderer picks a rendering style (drawer function). Let's say in this case it picked a solid fill of some sort. That makes ZDoom call R_FillAddColumn_rgba via a call to colfunc.
That function then creates a FillColumnAddLLVMCommand, which inherits from DrawColumnLLVMCommand. The constructor of DrawColumnLLVMCommand copies the solid color to fill with from dc_srccolor_bgra into a srccolor field in the DrawColumnArgs structure. That structure contains all the data passed on to the codegen'ed drawer. For the fill column version, that means it eventually ends up in
DrawColumnCodegen::ProcessPixel with DrawColumnVariant::FillAdd:
Code: Select all
SSAVec4i DrawColumnCodegen::ProcessPixel(SSAInt sample_index, SSAVec4i bgcolor, DrawColumnVariant variant, bool isSimpleShade)
{
SSAInt alpha, inv_alpha;
switch (variant)
{
...
case DrawColumnVariant::FillAdd:
alpha = srccolor[3];
alpha = alpha + (alpha >> 7);
inv_alpha = 256 - alpha;
return blend_add(srccolor, bgcolor, alpha, inv_alpha);
...
}
}
SSAVec4i DrawerCodegen::blend_add(SSAVec4i fg, SSAVec4i bg, SSAInt srcalpha, SSAInt destalpha)
{
SSAVec4i color = (fg * srcalpha + bg * destalpha) / 256;
return color.insert(3, 255);
}
So in this case we can see a that it does a normal alpha blend using both color and alpha from the dc_srccolor_bgra variable. Note that in this case, it is probably not using FillAdd for the blue pinkies, unless dc_srccolor_bgra is not being assigned at all and happens to have a left-over blue color in it.
Okay, that was a long description. Hopefully I didn't skip over too many parts or scare you with this. Understanding the full codegen part in one go can be a bit daunting.
Re: Blue shadow
Posted: Sat Oct 22, 2016 2:50
by Blue Shadow
Eruanna wrote:While we're on the subject - what does QZDoom do when you view other transparent effects? I'm particularly interested in GZDoom-type maps, like Stronghold's MAP99.
I don't seem to be having transparency issues. I ran through that map. Nothing looked out of the ordinary except for one thing: the sky/skybox (it's not rendering). But that's a different issue entirely.
And back to the spectre; the other fuzz effects (fuzz and translucent) work fine.
Re: Blue shadow
Posted: Fri Oct 28, 2016 1:51
by dpJudas
Fixed pinkie having the blues.
Re: Blue shadow
Posted: Fri Oct 28, 2016 2:20
by Rachael
Can't ... resist ....
Re: Blue shadow
Posted: Fri Oct 28, 2016 3:41
by dpJudas
With a song like that pinkie might get the blues again!
Re: Blue shadow
Posted: Fri Oct 28, 2016 3:52
by Rachael
Oh, now we have to intentionally recreate the effect. >_> After all that time you spent fixing it!
Well, stencil mode is possible in ZDoom, but I don't know if you can make it transparent or not. However, you can make it additive, which is enough
Re: Blue shadow
Posted: Fri Oct 28, 2016 4:07
by dpJudas
a mod where eiffel 65 plays each time you see a blue pinkie! Not sure if it would be classified as a terrywad tho
Re: Blue shadow
Posted: Fri Oct 28, 2016 4:41
by Tiger
dpJudas wrote:Fixed pinkie having the blues.
NOOOOOOOOOOOOO!!!!! The best feature - gone for ever, this is truly a depressing day for us all....
Re: Blue shadow
Posted: Fri Oct 28, 2016 5:16
by Rachael
No. Never gone.
Bonus: It works in GZDoom!
Re: Blue shadow
Posted: Fri Oct 28, 2016 8:30
by Tiger
Best feature - ever!