Messages

Sorry for the delay.

While implementing the blend mode in glsl, I noticed that I had the calculation wrong after all.
So I started from scratch. Here's the important snipped from the final code:

	vec4 resFrag;

	float ab = opacity; // blend opacity
	const float as = srcFrag.a;
	const float ad = dstFrag.a;

	const float at = ab*as;
	resFrag.a = at + ad - ad*at;

	resFrag.rgb = mix(dstFrag.rgb, srcFrag.rgb, ab*as);
	resFrag.rgb = mix(srcFrag.rgb, resFrag.rgb, ad*resFrag.a);

	gl_FragColor = resFrag;

It's unfortunately not 100% pixel perfect like I had hoped for. It is only accurate for a_d = 0 and = 255,
the values in between are linearly interpolated but in RMXP they change in a more "square" way.
But that's good enough for my needs I guess.

I'm as familiar with OpenGL as I am with DirectX. Essentially they are very similar, except that some of the logic is different (e.g. setting the current modelview matrix or left-handed vs. right-handed vertex rendering).

Yeah, and the whole C++ object oriented stuff ^^ I also heard handling of offscreen
rendertargets is heaps easier compared to OGL.

I know that you can't accurately replicate it, but getting close is better than nothing. Lol, good that I gave up back then. I would have gone insane if I had kept working on it.

Actually, going this (performance-wise) hard route means I get to replicate it pixel-perfectly ^^

EDIT: Have you thought about using 2 passes and premultiplied alpha? If your first pass would calculate only the final alpha for the source with the same color and then use the result as source for a second operation, you could keep the alpha and use that alpha in the second pass.

I was doing something similar to what you described (rendering alpha and color separately in two passes),
but after finding the proper blend algorithm it turned out that this won't cut it.
The problem is the division (2nd equation). a_r is unfortunately the divisor
meaning I can't even do cute tricks like substituting a multiplication with the inverse.
I'm not sure how familiar you are with OpenGL, but none of the offered blend functions
offer anything that would make this doable (and I'm sure OpenGL already offers everything
the hardware offers).

I'm currently thinking about just biting the bullet and doing a copy of the destination buffer
to do the blending myself. As long as I reuse the same auxiliary buffer for it and don't do
any copies to RAM, maybe it's not the end of the world after all.. gotta profile stuff as always ;D

Did you try tinkering with SetTextureStageState() with D3DTA_TFACTOR?

Sorry, I'm not familiar with Direct3D at all =/ (I work with OpenGL), but from the bit of googling
I just did this seems to be part of the fixed function pipeline that was deprecated in favor
of programmable shaders, so I don't think it could help us.

Yes, I didn't express myself properly. What I meant is that you don't need a frame buffer value for that. It's possible to use separate blending for alpha and for color values, but I'm not sure if that would be enough now that I think about it.

Okay. Yeah, I don't think it's enough (read the Edit to my previous post).

Yeah, otherwise it wouldn't work well,

That's not how shaders work.

You're contradicting yourself ^^

Anyway, I know how shaders work (I sure as hell wouldn't have been able to implement
sprites in my engine otherwise =P), and I'm also sure that current graphics hardware is
unable to do destination framebuffer readbacks, so using shaders doesn't really solve anything..

Edit: Remember that you need a_c to calculate the final color, which depends on a_r,
which in turn depends on a_d. So you need the destination alpha to calculate the correct color.

Um, okay, but where in your sprite shader are you reading values from the destination framebuffer??

Don't worry about it being implemented in ARC. Yes, you can't just implement it with th default functions, but you can when using a shader which ARC already is using.

=O How would you implement this in a shader? Does Direct3D allow readback from the framebuffer
you're writing to in its shaders?

[cleared]

Hey,

so I hit this really stupid problem with text rendering: If text is rendered on a bitmap,
what happens in my engine is that I first render it in software (using SDL_ttf), upload it to VRAM
and then simply render it ontop of the Bitmap like any other blending operation.
The problems start when drawing text with opacities <255. What I did until know was
render the text as usual, then draw it as a quad with the specified opacity. However, what happens
when I do this ontop of a cleared bitmap (as window contents always tend to be) is that the text
color is rendered at this opacity, and the resulting pixel itself also carries the opacity! This means
that what I see on the screen is actually at opacity^2, because the same opacity is reapplied during
the final render of the window contents sprite. (I'm sorry if this is hard to understand, I'm really bad
at explaining stuff..).
Anyway, this prompted me to look into how exactly the text drawing works in RMXP. Turns out it's
mostly the same process, except the text is blended using the same algorithm that blt and stretch_blt
employ (so probably the same DirectDraw functionality). The way this algorithm works makes the
"double opacity" problem never come up. Ok, enough blablah, here's what I got:

[Removed wrong algorithm]

(Would be cool if someone played with it a bit more and verified my results! :D)

And here's my giant problem with it: While the above is fairly easy to implement in software
(which I'm pretty sure is what DirectDraw does), it's really damn hard to do it in hardware because
at least with current gen GPUs, the blending stage is wired in fixed function hardware, and
it doesn't even look like that's going to change in the coming future. (On another note,
programmable blending is implemented on some mobile GPUs, but that's irrelevant).

This is a bit of a dilemma. I don't really want to keep around a shadow texture for each and
every Bitmap (to do the destination pixel reading from), so I'm thinking about how this could
be realized using other hacks. I know you guys use Direct3D, but we both use the same hardware
in the end so I'm pretty sure we're in the same boat here. The biggest problem is that I have
to somehow supply a "third" (uniform) alpha value (a_b), but I can't use the source pixel
alpha because that would screw up the remaining color blending.
At least with text rendering I think I can salvage the situation because SDL_ttf provides me
with a software surface anyway, so I'm thinking about simply duplicating it, setting rgb to a_b
and basically blending alpha and color components in two separate passes.

But as for the (stretch_/)blt situation, I have no fucking clue... I think I'll leave it aside for now as for
most games wrong blending doesn't seem to have much impact (most blt's are done with full opac).