NewsForumsCodeLogsGallerySpecsSearch

Inconsistent image quality between DX7 and DX9

Archives Forums/BlitzMax Bug Reports/Inconsistent image quality between DX7 and DX9

Tachyon(Posted 2009) [#1]
I am seeing a seam appear between some images in DX9, that I do not see in DX7. Here is sample code. Switch between the two "SetGraphicsDriver" commands to see what I mean.

SuperStrict

'// To see the seam, switch between these two commands
'SetGraphicsDriver D3D9Max2DDriver()
SetGraphicsDriver D3D7Max2DDriver()

Graphics 640,480

'// Make some garbage, then grab a couple images
For Local n:Int = 1 To 500
    SetColor Rand(255),Rand(255),Rand(255)
    DrawRect Rand(-100,540), Rand(200), Rand(-100,380), Rand(200)
Next
Local p1:TPixmap = GrabPixmap(50,50,200,200)
Local p2:TPixmap = GrabPixmap(250,50,200,200)

'// Convert Pixmaps to Images
Local i1:TImage = LoadImage(p1)
Local i2:TImage = LoadImage(p2)

'// Scroll the images
Local x:Float = 300.0

SetColor 255,255,255
Repeat
    Cls
    DrawImage i1, x, 50
    DrawImage i2, x + 200, 50
    x = x - 0.1
    Flip
Until GetChar()



Tachyon(Posted 2009) [#2]
I want to add: This is seen on both nVidia and ATI chipsets, under Windows Vista and 7 (haven't tried XP). All drivers up-to-date.

Also, I am really surprised this has not been brought up before because I am seeing it in several placing in the game where I need two moving images to align seamlessly up with each other. The artifact is not present in OpenGL or DirectX 7. Certainly it is not just my game suffering from this?!


degac(Posted 2009) [#3]
Well, just tested your program and I have a little problem to run it.
I cant' see any grabbed-image (under DX9)!

The pixmap exists (I just checked and drawed it via DrawPixamp - and this works), while the image is 'void / empty'



TaskMaster(Posted 2009) [#4]
Bug confirmed here.

Desktop PC with XP, latest SP, ATI Radeon x800 with latest drivers.


TaskMaster(Posted 2009) [#5]
I can also tell you, if you grab a pixmap that is 128x128 (or any other power of 2 size) the bug goes away.

This is a symptom of a bug in the way BlitzMax handles images that are not a power of 2 in size. Read more about this in this thread:

http://www.blitzmax.com/Community/posts.php?topic=85478#969578

Post #12 by me...


degac(Posted 2009) [#6]

I can also tell you, if you grab a pixmap that is 128x128 (or any other power of 2 size) the bug goes away


...mmmh
Using GrabPixmap(50,50,128,128) doesn't change the thing: I can't see any image.


TaskMaster(Posted 2009) [#7]
degac, you I believe you have a different problem than the one being discussed. :)


marksibly(Posted 2009) [#8]
Hi,

Fixed for next update.

And it's not actually a 'bug' in the way Max2d handles non-pow2 of 2 images, it's more a 'work around'!

The problem is that when dealing with non-pow2 images, you can't always just draw a subrect of a texture, as rot/scaling/filtering etc can cause 'bleeding' where the odd texel outside the subrect gets drawn. This is what's happening above.

In fact, with the above demo change the 'LoadImage' flags param to 0 and it starts working, although it also starts 'clunking' along due to lack of filtering. And it's the filtering causing the misfired fetch in this case.

So what Max2d does is 'smear' the left/bottom edges of non-pow2 images by a column/row so that any accidental fetches outside the image rect end up getting the correct texel.

This was the only way I could find to deal with the bleeding texel issue in a completely generalized way (ie: works with all Max2d effects).

It also makes texture packing/atlases etc a little tricky to do (in a generalized way; specific special cases can be made to work) although I have more or less decided to add auto texture-atlasing soon along with a 'user beware - add a border pixel (or more)' caveat!