Page 1 of 2
Irrlicht 2D drawing (bug?)
Posted: Sun Oct 21, 2007 3:57 pm
by lawck
I've been using irrlicht version1.3.1, then 1.4b for my game, and both showed the following problem:
Any image that isn't 512x256 doesn't show up right (be it OpenGL or DirectX9...)
In this case I programmed a new game / load game / quit state, and used a random image to test it with.
Click here to see a proof
Has anyone experienced the same problem or knows how to fix this?
Thanks in advance.
Posted: Sun Oct 21, 2007 5:40 pm
by vitek
You left out the most important piece of information. How are you drawing the texture?
Posted: Sun Oct 21, 2007 6:02 pm
by lawck
Code: Select all
ITexture *image = game->gDriver()->getTexture("this.jpg");
game->gDriver()->draw2DImage(image, position2d<s32>(0,0));
I've also tried
Code: Select all
IGUIImage *image;
image = game->gGuiEnv()->addImage(rect<s32>(0,0,800,600));
image->setImage(game->gDriver()->getTexture("this.jpg"));
Posted: Sun Oct 21, 2007 6:24 pm
by belfegor
One tip:
put your "draw" functions in loop so it renders every frame.
something like:
Code: Select all
while(device->run())
{
driver->beginScene(...);
driver->draw...();
driver->endScene(...);
}
Posted: Sun Oct 21, 2007 6:33 pm
by lawck
I did put the drawing functions in game loop.
And as I said, if this.jpg is 512x256, it draws perfectly. Anything else, the image gets distorted. (I've also tried, bmp and png)
Posted: Sun Oct 21, 2007 6:41 pm
by belfegor
It depends of gfx card. Does your card support "not power of two" texture?
Try to clear buffer with other color then black:
Code: Select all
...driver->beginScene(true, true, RedColor);
because i think irrlicht fills rest of the pixels black to accomodate texture
to be "power of two".
Posted: Sun Oct 21, 2007 6:50 pm
by lawck
I tried to clear buffer with a random rgb color and well, the problem persists.
Posted: Sun Oct 21, 2007 6:52 pm
by Acki
You say it works only with 512x256, but what other resolutions you tried ???
I also think it's because of the 2^n thing...
Posted: Sun Oct 21, 2007 6:56 pm
by lawck
800x600, 1024x768, 513x257, 299x116...
And I just tried 800x400.
The problem persists.
Posted: Sun Oct 21, 2007 7:36 pm
by sio2
lawck wrote:800x600, 1024x768, 513x257, 299x116...
And I just tried 800x400.
The problem persists.
I'm not surprised. Not a single one of these are a power-of-two in
both directions. Plus, 513x257 and 299x116 are
very strange sizes from a texture point of view.
The one exception I've seen in an nvidia 8800 card which doesn't seem to care and will happily even mip weird sizes.
Posted: Sun Oct 21, 2007 7:49 pm
by lawck
Ahh, okay, so apparently the textures must be power of 2 indeed
.
Thx everyone.
Posted: Sun Oct 21, 2007 8:39 pm
by Acki
Right...
But even if your gfx card supports
non-2^n textures you should always use dimensions in 2^n, because you can not assume that every user has such a gfx card, too !!!
Posted: Mon Oct 22, 2007 1:16 am
by vitek
Honestly, I'm having trouble reproducing this with the 1.4beta distribution. The following code correctly renders the given texture with its top-left corner placed at (0, 0).
Code: Select all
// 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();
}
}
I found that it doesn't work with the Apfelbaum [EDT_BURNINGSVIDEO] driver type, but it seems to work just fine with all of the others. You can see screenshots
here.
Travis
Posted: Mon Oct 22, 2007 2:39 am
by lawck
In my case, OpenGL looks better then DirectX9, but even then, OpenGL didn't look very smooth .
The one that looked the best, was EDT_SOFTWARE.
But using power of 2 image width & height, worked pretty fine for both, OpenGL and DirectX9 (didn't test it with EDT_BURNINGSVIDEO)
Posted: Mon Oct 22, 2007 3:48 am
by vitek
I'm saying I can't reproduce the behavior that you're seeing [non-power of two textures appear wrong] when using the D3D or OGL drivers.
Travis
