Float-coords producing weird anti-alias

First the result when drawing one sprite at x=100 and one at x=100.5:



then the test-code:

SetGraphicsDriver GLMax2DDriver()
Graphics 800,600,0
Global Test:TImage =LoadImage("tvt_smeartestimg.png", FILTEREDIMAGE)



Repeat
	Cls
	SetColor 255,255,0; DrawRect(150,100,50,100)
	SetColor 255,0,255; DrawRect(200,100,50,100)
	SetColor 0,0,255; DrawRect(250,100,50,100)
	SetColor 0,100,50; DrawRect(300,100,50,100)
	SetColor 255,255,255;	DrawRect(100,100,50,100)
	DrawImage(Test,100,100)
	DrawImage(Test,100.5,150)
	Flip 0
Until KeyHit(KEY_ENTER)

And the testfile:



Why does this produce those jagged anti-alias outlines seen on the sprite drawn over the right rectangles (i know that white isn't as visible on the brighter rectangles ... but why isn't alpha-channel used there?).

Another thing is when drawing on a pixmap (I have all figure-sprites in one image, drawing player-colored sprites at the bottom) when now drawing them with integer-coordinates (120, 121 ...) everything is ok, but when using fractional coordinates (120.5,120.65,...) it's not only getting smeared/blurred (what's acceptable) but also blurred differently - so for example the dark skin-color used as face-border is drawn dark in one frame and brighter in the next and same for clothes etc.
This produces an akward visible defect (like blinking sprites).

Short: using non-fractional-coordinates everything works perfectly, using fractional-coordinates some disturbing effects are drawn. How to avoid?


bye
MB

edit: Ok, without filteredImage the effect would be gone, but also the smoothness of the movement.

your character pixels are merged with the transparent pixels, transparent pixels are alpha=0 rgb=255, you need to filter your image and set the transparent value to apha=0 rgb=0 to avoid this.

if its a png use Setblend Alphablend before drawing.

Ok, sorry, forgot to set AlphaBlend to make a short example for my problem, within my app I use the correct Blendmode but only the single-figure-sprites (one figure per image instead of all figures with all their frames in one big image) get drawn properly.

So I'm sorry for the bad example, but the problem stays the same. But don't matter with it until I can provide a short code example showing the problem I want to solve.

So thanks and until the next problem ;D

bye
MB

round the cords before drawing? I think this is correct behaviour when using non integer values as the engine is "mixing" pixels, isn't it?

This is incorrect. Transparent pixels should have their alpha set to zero and their rgb colors set to the same as any solid neighbors for hardware filtering to work correctly. Here is a blitz3d example of the process required:

KeyImage Edge Correction algorithm

If your drivers mip map settings are set to override stuff it can cause visual issues with textures.

Set to application preference if its the case.

oh well, but I think I'm right and the problem is that the transparent pixel is in white and that's why it has that ugly border, the method you mentioned is the best but to put it all to zero is less complex and takes out that white border.

Search for defringe. It's a neat little app that I use on all my graphics to solve that problem.

The figures are hand-drawn (pixels set manually), so no defringe is needed.

the easy (and embarrassing for me) reason for the problem was the fact, that I placed different SetBlend-Commands around my app to save some fps and in my tries to optimize more (more sprites on one image) I changed order and all figures got drawn with MaskBlend instead of AlphaBlend...

Because special figures got drawn way before others I only checked those ones and they were alphablended... thats why my problem occoured and now I have to blush ;D.


TY for your help.

Now I hope I just have to wait for Mark's update (DX9 and reflection) to see again some nifty speed improvement.


bye
mB

tada!