I was looking the textures of Muramasa The Demon Blade and the edges are like pixel art with some pixel almost invisible in side.
And in Odin Sphere the edges are much more complex and doesn't appear to have been cut.
They managed to paint this directly without editing the edges or any mask? o.O
The way that the images of spineboy is made seems different (vector masks?).
How exactly can I make painted sprites avoiding alpha issues and aliasing?
Have you tried exporting your files with premultiplied alpha?
Alpha issues like horrible black/white borders happen when you pair a shader with the wrong alpha/RGBA channel format.
If this wasn't what you were running into, sorry. I hope it helps someone else. : p
Where did you get these sheets? XD
I'm pretty sure sprites from those game use an alpha channel. You can use a 24-bit PNG format (for example) to save your pictures and you can have an alpha channel that allows you to have antialiased borders like those ones.
If you are trying to reconstruct those sprites with spines though I must warn you that almost all the the animations in Muramasa Blade have deformations, and they some of them are pretty complex they doesn't seem to be simple change in the position of each corner of the texture. I didn't check that on Odin Sphere but I'm planning to (I'm a huge fan of games from that team).
You mean the main sprite and an separated alpha map?
But this mean increase the game size and this is not really necessary since PNG already have an alpha channel.
Yeah, Vanillaware uses a lot of vertex deformation in their animation but what I want know is understand how they paint that hi-res 2d without mess up the edges.
In Muramasa they seem indexed the colors (simplified the color palette) but in Odin Sphere this not happen.
Where did you get these sheets? XD
Internet is an extensive place. :giggle:
There isn't anything special with making images, just make the edges so there is only alpha and no mask color. For specific techniques it depends on what image editing software you use.
There are other issues when it comes to drawing at runtime.
Spineboy with non-premultiplied alpha:
Spineboy with premultiplied alpha:
The premultiplied tends to look dirty around the edges, but this isn't seen when blended correctly. Look at the eye images, you might need to open 2 browser tabs and switch between them.
With OpenGL blending you blend non-premultiplied alpha using GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA:
rgba = src.rgba * src.a + dst.rgba * (1 - src.a)
This is "traditional" blending. The reason this is problematic is looking at just alpha:
a = src.a * src.a + dst.a * (1 - src.a)
The first term is a*a, which isn't what you want. You'll see this is a halo around your images that should have clean edges. You can fix this with glBlendFuncSeparate, which lets you have separate blending for rgb and a. You would use GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA for rgb and GL_ONE, GL_ONE_MINUS_SRC_ALPHA for alpha:
rgb = src.rgb * src.a + dst.rgb * (1 - src.a)
a = src.a * 1 + dst.a * (1 - src.a)
Now your alpha doesn't get hosed.
With premultiplied alpha you do "src.rgb = src.rgb * src.a" either by processing the image file beforehand, at image load time, or at runtime (eg using a shader). Then you blend using GL_ONE, GL_ONE_MINUS_SRC_ALPHA:
rgba = src.rgba * 1 + dst.rgba * (1 - src.a)
This avoids the src.a * src.a problem and the result is the same as with glBlendFuncSeparate, because the src.rgb * src.a has already been done.