Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Exponent]

It would be nice if alpha blending were turned on in OpenGL, even in the current case where the image loader doesn't recognize partial transparency and therefore all texture pixels are either fully opaque or fully transparent.  This would hopefully be a very basic addition; optimistically it would merely consist of adding the two following lines of code in the proper location, if I looked up my OpenGL stuff correctly (sorry, I'm primarily a Direct3D person):

Code: [Select]

glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
Assuming that all objects are already drawn in the correct order for alpha blending (back to front), no other changes would need to be made that I can think of.

Now no benefit will come from this for normal character sets that are drawn at their native size.  However, if the TEXTURE_PARAM setting in init.txt were set to LINEAR, and a person were to use a character set with tiles that are natively twice as large in each dimension as they are when drawn on the screen, then pixels could automatically take on partial transparency when some but not all of the 4 texels that map to one screen pixel were magenta when the character set was loaded.  (Granted, this would still be limited to 25%, 50%, and 75% partial transparency, but it would still be useful.)

Use of this partial transparency would allow character set makers to provide some nicer looking characters that blend more effectively with the background color.  For one, letters and objects could be made to look smoother against all backgrounds, not just dark ones.  Other nice effects could be made as well, especially regarding tiles 176-178.  And gems and gem ores could have some partially transparent pixels as well, which might be a cool effect.

The drawbacks:  One, it might slow rendering down, but I really doubt it, except on the absolute crappiest of computers; nonetheless, a new init.txt setting might be appropriate, and the addition of an init setting is always more work (though I don't know how much more work).  Two, if rendering is currently done front-to-back (likely in order to take advantage of the z-buffer), then it would have to be reversed, meaning more code changes and further loss of (hopefully negligible) performance.  Three, I'm making some assumptions about the code based on limited observations of how the game draws 32x32 texture tiles onto 16x16 screen tiles with linear texture filtering turned on; if some of those assumptions are wrong, then my hope that it is an easy change might be unwarranted.  But if it turns out that performance is not noticeably affected (which I think is likely), and if indeed the two lines above are all that are needed, then I think it'd be a welcome addition with a very low cost of implementation.

[G-Flex]

Right now, I just wish DF didn't use such a limited color palette. It would be nice to define a stone/metal as being a particular 24-bit color using hex triplets, so that rose gold isn't shocking fuchsia and so forth.