Some questions, downsampling, sprite animation.

Guest · Post by **Guest** » Sat May 08, 2004 1:46 am

Good evening,
Thanks for an excellent engine. I have been using it for some time now and I just have a few questions. I have a few high quality textures (24 bit color) in BMP format that when I load them using getTexture(..) they display horribly downsampled. What is the reason for this? I tried to converting them to jpeg format, but same result. In photoshop they display beautifully but in IrrLicht they are significantly downsampled and looks very ugly. I tried ->setTextureCreationFlag(irr::video::ETCF_ALWAYS_32_BIT, true); because I thought maybe that would take care of it, but no such lucj.

I just resently started with the graphic intensive programming part of my "program" and so several issues are arising.

The next questions is sprite animation in 2d. I have a bitmap with frames of a sprite animation. Does IrrLicht support sprite animation and if so are there any timing options? Ideally, of course, all sprite animations should be framerate independent. Anyone have any tips on how this is done?

Lastly, I try my programs on several different operating systems and on Windows 95/98 I have a problem where the mouse pointer is "shivering", i'e' moving rapidly around offset by 1-3 pixels. It does not affect the framerate in any way and using a sprite as a mouse pointer and hiding the regular pointer this problem is not evident. Any ideas what could be causing such a quivering mouse pointer? This problem as so far not appeared under Win2000 or any other operating system.

Thank you for your attention. Feedback greatly appreciated.

Ken V. Nordberg

Acki · Post by **Acki** » Sat May 08, 2004 2:36 am

I have a few high quality textures (24 bit color) in BMP format that when I load them using getTexture(..) they display horribly downsampled. What is the reason for this?

Well, I had the same prob...
It's an elementary fault of you, I think !!!

The grafics height and width have to be a potenz to the base 2...

2^0, 2^1, 2^2, 2^3, and so on...
in pixel: 1, 2, 4, 8, 16, 32, 64, 128, a.s.o...
a good size for textures seems to be 256 * 256 pixel...

If one size is not so, Irrlicht will scale these size to the next possible value...

CU, Acki

Guest · Post by **Guest** » Sat May 08, 2004 5:03 am

That sounds terribly limiting to me... So if I want to display a texture of size; let's say 640 x 144 or 192 x 768 I am out of luck? If that's the case it would be absolutely unacceptable. To clearify what I am trying to do: I want to blit a status overlay around a 3d graphic area. Can someone confirm that such a limitation exists in the IrrLicht engine? I can accept that a sprite will in most cases inherit a quadratic shape and thus be able to fulfill the limitations given, but any GUI elements, overlays or other static 2d elements would not be supported by IrrLicht if Acki is correct.

Again, any feedback would be greatly appreciated.

Ken.

Guest · Post by **Guest** » Sat May 08, 2004 5:09 am

Just to clearify: the texture DOES show up on the screen in it's correct size so it does not seem to me like any scaling has taken place. I.e. I loaded a 640 x 144 size bitmap and rendered it to the scene and it displays in the right location and with the right size in pixels, but the quality is no where close to that of the original. It seems to me like a downsampling of quality, rather than a scaling has taken place. Why such a behavior?

Thanks,
Ken.

Domarius · Post by **Domarius** » Sat May 08, 2004 6:56 am

So if I want to display a texture of size; let's say 640 x 144 or 192 x 768 I am out of luck

Yep.

And you're going to find that's the case with pretty much every 3D engine out there, without some kind of additional layer that processes your image before it gets to the video card.

Because; texture memory on video cards is designed to work with image dimensions that are multiples of 2. It's the fastest and most memory efficient way to do it.

You should have no problem conforming to that 'limitation' - every single commercial game does. You just have to design your bitmaps to conform to those types of dimensions.
If you don't beleive me, check out the textures folder of any of your commercial 3D games (provided they don't have them archived in some proprietry format), and look at the image dimensions.

Keep in mind - it doesn't have to be a uniform size - you can have a 64x256 size texture, anything as long as the dimensions individually are multiples of 2.

?...any GUI elements, overlays or other static 2d elements would not be supported by IrrLicht if Acki is correct.

Maybe you should take a look at the examples folder in the Irrlicht download. Irrlicht has a very good built in windows style GUI interface, that emulates practically every standard windows control, but using 3D hardware, so the GUI can be semitransparent, scale to any dimension, etc.
Check the GUI example.

...it displays in the right location and with the right size in pixels, but the quality is no where close to that of the original...

This is because the 3D object that has your bitmap on it, is being displayed at the exact pixel dimensions you specify, however, the texture is being resampled to conform to the nearest dimension sizes to the power of two - I am not sure if Irrlicht is doing this or the video card, but it must be done somewhere along the line for it to even be displayed at all.

Maybe you should check out the TechDemo, it displays the Irrlictlogo.bmp at the top left hand corner of the screen the whole time, and it is a non-standard size of 88x31. It is done by drawing it as a 2D image on the display, after the 3D world has rendered for that frame.
Variable is initialised like this;
video::ITexture* irrlichtLogo = driver->getTexture("../../media/irrlichtlogo.bmp");
and in the loop, after the 3D world is drawn, this line draws the logo;
driver->draw2DImage(irrlichtLogo, core::position2d<int>(10,10));
That's probably the kind of thing you want to do.

Domarius · Post by **Domarius** » Sat May 08, 2004 7:07 am

Anonymous wrote: The next questions is sprite animation in 2d. I have a bitmap with frames of a sprite animation. Does IrrLicht support sprite animation and if so are there any timing options? Ideally, of course, all sprite animations should be framerate independent. Anyone have any tips on how this is done?

There is a 2D game example in the examples folder. Pull it apart, and post back here when you run into something you don't understand.

Acki · Post by **Acki** » Sat May 08, 2004 11:27 am

So if I want to display a texture of size; let's say 640 x 144 or 192 x 768 I am out of luck?

Well you could take a greater size with the right dimensions and get the whanted image out of this great texture...
There exists a funktion for that (don't know the functions name, yet)...
Than you can also use other sizes for your textures (e.g. 123 * 333)...
Only the loadet texture has to be in this limitation, what you get out of it doesn't matter....

CU, Acki

guest1 · Post by **guest1** » Sat May 08, 2004 11:59 am

I know that OpenGL does not allow any other size accept for powers of 2, and I think DirectX resamples them for you like Domarius said. The most common way of fixing this "problem" is to do something like this...

You wanted a 640x144 texture. Well, you cannot fit that on a 512x512 texture, so you'll have to upgrade that to a 1024x1024 texture. Then, to display it correctly you be sure your UV's are calculated correctly. You can find those out easily by doing something like this:

640 / 1024 = 0.625
144 / 1024 = 0.140625

so, that means your UV coords will be:
0,0
0,0.625
0.140625,0
0.140625,0.625

pretty simple

You are, of course, wasting 91% of your texture though, so you may want to either put multiple interface elements on a single texture or consider the power of 2 rule.

Just for a sidenote: There was an engine that accepted non-powerof2 images, and it was Half-Life, but what you didn't know is when HL was loading the level it was loading all of these images and putting them into a bunch of different 256x256 textures. This made it so that incompatible voodoo cards could display the 256+ textures (by splitting them) and merging all small textures into memory efficient 256x256 images. I'm pretty sure Irrlicht doesn't have that, even though it'd be nice... Anyone want to write some code like that? It'd be a huge memory saver for sprite based games and other things that use a lot of non-square textures...

hehe

guest1 · Post by **guest1** » Sat May 08, 2004 12:06 pm

I have a bad habit of pressing "submit" before verifying my information...

Aparently, Half-Life (dunno about OpenGL) works ok with sizes like 512x128 (according to the article below) which I will try out a little later, because I never even thought of that when I was developing on OpenGL... I just figured they had to be square...

Anyway, here's the article... it's a good read. Very informative,

http://www.slackiller.com/tommy14/tex-dimensions.htm

Guest · Post by **Guest** » Sat May 08, 2004 3:26 pm

I thank everyone for their very informative help. I did pick apart several samples and did exactly the same as those demos did. Let me ask you this... I can make my 640x 144 texture conform to the power-by-two limit (by increasing it's size) and then just pick out a rect of the size I want and then blit that to the screen? This seems to be what TechDemo is doing. I will definetly try it and post the result here. It seems like a waste to load those texture into video memory though. I know other engines (such as CDX, which by the way is terrible on 3d, which is why I canned it) lets you choose wether or not to use regular memory or video memory for textures. CDX allowed any size textured for 2d and GUI elements by enabling them to load in regular memory. I am little bit out on thin ice here because I was blissfully unaware of this limitation in the first place. Is it possible to make IrrLicht behave in this manner? And would such a memory mixing have any effect on the framerate? It just seems like a waste to load such a big texture and just using a small part of it.

Anyone have a few tips on the sprite animations and quivering cursor that I mentioned in my first post?

Thanks yet again for your help,
Ken.

Guest · Post by **Guest** » Sat May 08, 2004 4:35 pm

I padded the textures with pixels in the transparent color until they conformed to the limit and it worked fine. The bitmaps displayed in their full 24 bit glory, but I still think it seems like a waste of memory. Unless of course it's possible to add those multiples of 2. If I can add lets say 64 to 128 and get 192 and that being a legal value for a texture, then we're talking a whole different tune and it may not be so horrible afterall. I will test with various multiples of 2-4-8-16-32-64, etc. I'd still like to see 2d elements that do not have to conform to this limit though. Is this at all possible or am I just ignorant?

Ken.

Tyn · Post by **Tyn** » Sat May 08, 2004 5:15 pm

It isn't possible to have textures not applying the power of two rule due to limits of the video card, not Irrlicht. Using 192 will still have a drop in texture quality due to it not being the power of two. It's something every 3D programmer has accepted and unfortunatly we will have to do the same.

Domarius · Post by **Domarius** » Tue May 11, 2004 3:38 am

Tyn wrote:It isn't possible to have textures not applying the power of two rule due to limits of the video card, not Irrlicht. Using 192 will still have a drop in texture quality due to it not being the power of two. It's something every 3D programmer has accepted and unfortunatly we will have to do the same.

Yeah, like I said before

Anonymous wrote:...I can make my 640x 144 texture conform to the power-by-two limit (by increasing it's size) and then just pick out a rect of the size I want and then blit that to the screen? This seems to be what TechDemo is doing...

Not in the code, no. Like I said before, if you look at the TechDemo, all it is doing is loading the image;
video::ITexture* irrlichtLogo = driver->getTexture("../../media/irrlichtlogo.bmp");
and then pasting it on the screen, as a 2D bitmap, after the 3D stuff has been drawn;
driver->draw2DImage(irrlichtLogo, core::position2d<int>(10,10));
The irrlicht logo is a non-standard size of 88x31, and no padding is nessecary by you.

Irrlicht Engine

Some questions, downsampling, sprite animation.

Some questions, downsampling, sprite animation.

Re: Some questions, downsampling, sprite animation.