Having some issues with smooth alpha gradients in texture files resulting in bad banding issues.
I have a 2D XNA WP7 game and I've come up with a fairly simple lighting system. I draw the areas that would be lit by the light in a separate RenderTarget2D, apply a sprite to dim the edges as you get further away from the light, then blend that final lighting image with the main image to make certain areas darker and lighter.
Here's what I've got so far:
As you can see, the banding is pretty bad. The alpha transparency is quite smooth in the source image, but whenever I draw the sprite, it gets these huge ugly steps between colors. Just to check I drew the spotlight mask straight onto the scene with normal alpha blending and I still got the banding.
Is there any way to preserve smooth alpha gradients when drawing sprites?
Is there any way to preserve smooth alpha gradients when drawing sprites?
No, you cannot. WP7 phones currently use 16 bit color range system. One pixes got: 5 red bits, 5 blue, 6 green (humans see a wider spectrum of green color).
Found out that with Mango, apps can now specify that they support 32bpp, and it will work on devices that support it!
For XNA, put this line at the top of OnNavigatedTo:
SharedGraphicsDeviceManager.Current.PreferredBackBufferFormat = SurfaceFormat.Color;
For Silverlight add BitsPerPixel="32" to the App element in WMAppManifest.xml.
Related
I'm trying to render some label textures with transparent background using OpenTK in Xamarin. At first the labels seemed display properly (see picture 1) but when the view rotated, the some label background are not transparent any more (see picture 2).
The enabled BlendFunc is GL.BlendFunc(BlendingFactorSrc.SrcAlpha, BlendingFactorDest.OneMinusSrcAlpha).
My question is how can I always have labels transparency on despite of their positions?
The same code and shader can run properly on Android Devices by the way.
Ah yes, the good old transparency problem. Unfortunately this is one that a graphics programmer has to solve on his own.
For just a few labels, the most straight foward solution is likely to sort your labels by z-depth and then render them from farthest to closest. You'd probably need to do some matrix math on that label position to adjust for viewport rotation.
For the 3d game I'm working on I have chosen to implement the order-independent transparency method called WBOIT by Morgan McGuire, which is fairly simple to implement and yields relatively good results.
I need to draw a soft wide outline for my GDI+ GraphicsPath.
Something like this:
A path edge is shown in red. I'd like to use a wide pen which is smooth. I also need an ability to control smoothness of the pen.
I tried to use a gradient brush with the pen but couldn't find a solution that works.
I can achieve the desired result by drawing an outline with a black solid pen and applying a Gaussian smoothing filter on top of the result image, but I want to avoid this because it's slow when I have to process the whole image which could be quite large.
Is there a way to draw a smooth path outline?
There is no standard way in GDI+ that provides this functionality so you will have to create it.
You could track the line segments and draw a fuzzy, filled circle along the segments. By drawling the fuzzy circle once to a bitmap it should be fairly easy and fast to blit it continuously. By blending it slowly over time to the canvas you can also create a very nice effect and it would allow the user to control the intensity and maybe the size of the circle.
Commonly, techniques such as supersampling or multisampling are used to produce high fidelity images.
I've been messing around on mobile devices with CSS3 3D lately and this trick does a fantastic job of obtaining high quality non-aliased edges on quads.
The way the trick works is that the texture for the quad gains two extra pixels in each dimension forming a transparent one-pixel-wide outline outside the border. Due to texture sampling interpolation, so long as the transformation does not put the camera too close to an edge the effect is not unlike a pre-filtered antialiased rendering approach.
What are the conceptual and technical limitations of taking this sort of approach to render a 3D model, for example?
I think I already have one point that precludes using this kind of trick in the general case. Whenever geometry is not rectangular it does nothing to reduce aliasing: The fact that the result with a transparent 1px outline border is smooth for HTML5 with CSS3 depends on those elements being rectangular so that they rasterize neatly into a pixel grid.
The trick you linked to doesn't seem to have to do with texture interpolation. The CSS added a border that is drawn as a line. The rasterizer in the browser is drawing polygons without antialiasing and is drawing lines with antialiasing.
To answer your question of why you wouldn't want to blend into transparency over a 1 pixel border is that transparency is very difficult to draw correctly and could lead to artifacts when polygons are not drawn from back to front. You either need to presort your polygons based on distance or have opaque polygons that you check occlusion of using a depth buffer and multisampling.
I have sprites that when they overlap I would like them to 'add' their colors rgb values to (potentially) go white, the sprites also have changin alpha values which should remain unchanged. I've already tried using all the spritebatch options alphablend, additive etc...
Is this possible through spritebatch or will i need a shader?
Thanks,
Paul.
Using the Premultiplied Alpha scheme in XNA 4, you can do additive blending by having your texture drawn at 0 alpha. Because this means that there is 0 blocking done by the texture, and then the RGB is added to the pixels behind it, you get additive blending.
Just draw the texture with 0 alpha using the spritebatch mode 'Alphablend'. To lower the additivity, increase alpha. To make it less visible, lower RGB.
I highly suggest making sure any textures in your content have the option 'Premultiplied Alpha' ticked in their properties, if you use this.
I know that NES had 4-color sprites (with 1 usually being transparent Edit: according to zneak, 1 color is always transparent). How then did the original Final Fantasy have so many sprites with 4 colors + transparent? (Example sprite sheet -- especially look at the large ones near the bottom.)
I understand that you can layer sprites to achieve additional colors (For example: Megaman's layering gives him 6 colors: body=3+trans, face=3+trans). It's odd that these FF ones are all exactly 4 colors + transparent. If FF used similar layering, why would they stop at 4+1 instead of taking advantage of 6+1?
Is there another method of displaying sprites that gives you an additional color?
Also interesting is the fact that the big sprites are 18x26. Sprites are 8x8 (and I think I read somewhere that they're sometimes 8x16) but both 18 and 26 are [factor of 8] + 2. Very strange.
As far as I know, 1 isn't usually transparent: it always is.
As you noted, sprites are either 8x8 or 8x16 (this depends on bit 6 of the PPU control register mapped to memory address 0x2000 in the CPU's address space). Character sizes not being a multiple of 8 simply means there are wasted pixels in one or more of the constituting sprites.
For the colors, I beg to differ: the last sprite at the bottom, with the sword raised, has these 8 colors:
Final Fantasy sprite 8 colors: black, brown, beige, sky blue, navy, dark turquoise, turquoise, cyan http://img844.imageshack.us/img844/2334/spritecolors.png
I believe this is more an artistic choice, because each 8x8 block is limited to 3 opaque colors; maybe it just was more consistent to use fewer colors.
I found the answer. I finally broke down and downloaded the ROM and extracted the bitmaps with NAPIT. (btw: staring at extracted ROM bitmaps is really bloody hard on your eyes!)
I matched a few bitmaps and end-results here.
Each character has a color that is mostly relegated to top part of the sprite so I chased that idea a while. It turns out that's a red herring. Comparing the in-game sprites vs. the color masks, you can see that black and transparent use the same color mask. Therefore, IF a black outline is shown, then it must be on a separate layer. However, despite the black outlines on the sprite-sheet, I can't find any real examples of black outlines in the game.
Here's a video on YouTube with lots of good examples. When you are on the blue background screen (# 0:27), the outlines and the black mage's face are the blue of the background (ie: there is no black outline, it's transparent). In combat, the background is black. # 1:46 a spell is cast that makes the background flash grey. All black areas, including outlines and black eyes, flash grey. Other spells are also cast around this part of the video with different colors of flashes. The results are the same.
The real answer is that the black outlines on the sprite sheet don't seem to exist in the game. Whoever made the sprite sheet took the screenshots with a black background and scrubbed the background away.
You might want to check out Game Development StackExchange instead of here.
I've just had a quick glance at the sprite sheet, but it looks to me that sprites with more than 3 colors + 1 transparent either have weapons or use 3 colors + a black outline. Also, if you could show that sprite sheet with a grid separating tiles...
Maybe the extra 2 colors were reserved for the weapons.