EDT_BURNINGSVIDEO image drawing issue

vitek · Post by **vitek** » Sun Oct 21, 2007 10:55 pm

This is an issue with 1.4beta.

// image is 512x385
video::ITexture* t = driver->getTexture("../../media/dotnetback.jpg");

while(device->run())
if (device->isWindowActive())
{
   if (driver->beginScene(true, true, video::SColor(0,200,200,200)))
   {
      smgr->drawAll();

      driver->draw2DImage(t, core::position2di(0, 0));

      driver->endScene();
   }
}

This is the result with the EDT_SOFTWARE driver...

This is the result with the EDT_BURNINGSVIDEO driver...

The driver correctly attempts to maintain the OrigSize, but that isn't enough. In CSoftwareDriver2::draw2DImage(), there is a call to CImage::copyTo() or CImage::copyToWithAlpha(). The problem is that the image knows its own physical size, but it doesn't know the images 'original size'. You can see this by setting a breakpoint inside Blit() and looking at the source image. It will have the dimensions 512x512, which is wrong.

Ideally, all npot code should be removed from both of the software drivers. This problem does go away if you do this.

Travis

vitek · Post by **vitek** » Sun Oct 21, 2007 11:04 pm

In case anyone is interested, here are the results with the other drivers...

The EDT_DIRECT3D8 driver gives us this [very blocky]

The EDT_OPENGL driver gives us this [smoothed]

Travis

lester · Post by **lester** » Mon Oct 22, 2007 12:50 pm

Why does irrlicht need such a driver? It segfaults everytime I choose it and now it doesn't show images properly. Why not to leave one stable and fast software driver which was primarily in irrlicht?

vitek · Post by **vitek** » Mon Oct 22, 2007 3:25 pm

I can't explain the crashes that you are getting, but it works quite well out of the box [tested with 1.4beta]. Well, with the exception of this particular bug. If you don't like the driver, you should be able to compile it out quite easily by modifying IrrCompileConfig.h.

christianclavet · Post by **christianclavet** » Thu Oct 25, 2007 2:26 pm

Hi. Vitek.

How does it look over DirectX 9? Is it ok?

I had a similar problem with pictures with 1.31. with the burning driver. I had to have my picture with a power of 2 resolution (example: 512x256). But I'm sure you've tried this already.

vitek · Post by **vitek** » Thu Oct 25, 2007 4:15 pm

How does it look over DirectX 9? Is it ok?

DX9 looks just like DX8, blocky.

I had to have my picture with a power of 2 resolution (example: 512x256).

There is the problem. You shouldn't have to make your images in power of 2 sizes. The texture creation code should allocate an appropriately sized texture to store the image data. The draw code should be careful to use the appropriate 'size' when accessing the texture so that it displays correctly.

When the texture coordinates are calculated, as they are when using draw2DImage, there is really no reason to not display a texture incorrectly.

If you had a mesh that has texture coords in it, then I can see why you would have a problem when the bottom and right of the texture did not have image data.

Travis

christianclavet · Post by **christianclavet** » Fri Oct 26, 2007 10:20 pm

Ok. Do you know what could cause that "blocky" look in DX8 and DX9? (Mipmapping?)

I've tested under Software and Burning Video.

The GUI rendering is ok in Burning Video but is awful in Software.

If i'm using a power of 2 picture in Burning video, all is ok including the GUI rendering. But if something could be done in the driver so that we could load directly it would be great.