ITexture to IImage conversions are slow

[Ulf]

I know there is no perfect answer for this because it seems Irrlicht isn't fully implemented for 2D graphics.

I'm slowly working on a 2D game engine and I wanted to have the capability to scale (and rotate) 2D textures so I can create some extra effects.
So, it may not be used often, but it would be nice if it could be used often (without killing the FPS!)

I keep my sprite textures in a block texture that holds all the frames of the object, and simply draw the source rect that I need at the time (to draw a frame).

I am able to resize as follows:

Code: Select all

irr::video::ITexture* texture1 = driver->getTexture("F:/Coding/Current/Game Engine/Cross Platform Game Library - Irrlicht/media/fire.bmp");

irr::video::ECOLOR_FORMAT colorFormat1 = texture1->getColorFormat();
irr::core::dimension2d<s32> size1 = texture1->getSize();
void* data1 = texture1->lock();

irr::video::IImage* image1 = driver->createImageFromData(colorFormat1, size1, data1, true, true);
irr::video::IImage* tempImage1 = driver->createImage(colorFormat1, irr::core::dimension2d<s32>(128, 128));
image1->copyToScaling(tempImage1);

irr::video::ITexture* tex1 = driver->addTexture("Texture1_Resized", tempImage1);

texture1->unlock();

I am able to keep non-power of 2 textures. And resize them to any size. It works fine. That's what I want. (though I've only tried it with the OpenGL driver).

But my compiler warns me (in the output window) that the

Code: Select all

texture->unlock();

function is slowing down the application tremendously!

**EDIT** Actually, it specifically says that unlocking non-power of 2 textures is extremely slow.

Is there another way to do this?

At the moment I need to:
1. Lock the Texture. (slow?)
2. Create an IImage (the same size as the Texture!)
3. (then) I have to create an empty IImage of the appropriate Size & Color.
4. (and finally) I get to resize the image!
5. (and really FINALLY) I have to make a new texture again (of course! )
6. Unlock the Texture (slow as apparently?)

As an example, I made a loop, loaded 2 (TWO) textures and resize them in the render loop. BTW, the textures are very small.
It slows down from 70 FPS to 50 something..
Every single texture resize slows it down heaps!

I thought there is one way around it. Use more memory.
I'll have to keep the ITexture, and a copy of the original IImage.
Then I'll never have to lock/unlock the Texture.

I was worried about memory, speed,.. and everything. But man, you have to give up one of them. Memory isn't a problem when people have 4GB of RAM on their systems!

Speed matters!

If you keep the image, then you can create new textures from it, resize it, and never have to lock the main (standard sized) texture to do any of it.

But then, if an IImage must also lock itself when you create a texture from it with addTexture() function, then it may be same thing? God No! Please!
It seems not to.

[Ion Dune]

You may wish to consider using an orthographic camera with 3D quads instead, which allows very simple resizing and rotating without changing the actual texture.

I've got a scene node for this purpose, which you can download from here if you wish (ignore the license info at the top of the files, the license is just zlib, like irrlicht). It's not commented yet, but the functionality is pretty straight forward (I believe). There are also a couple of nodes in this forum which accomplish this as well, so you may want to look into those.

[Ulf]

You may wish to consider using an orthographic camera with 3D quads instead, which allows very simple resizing and rotating without changing the actual texture.

Thanks I've noticed several people suggesting that to others,
But, I want to do it 2D.
I've heard some people say that 3D has hardware acceleration and 2D doesn't, implying that it will be faster that way. But I don't see how that makes sense.

It SHOULD be faster to simply blit the textures than to represent it in 3D and draw it in 2d (flat) using camera etc.
I don't know but it should be if you think of the extra data involved in 3D, plus I only need to draw whats in the viewport.

Anyone have an opinion about that? (Am I wrong? Is 3D faster?)

Also, are 3D quads limited to power of 2 sizes?
This is bit confusing. Others have said that 2D textures should/must be power of 2 also, but it's not the case (though it slows down the lock/unlock).
In the documentation it says that if you want to use addRenderTargetTexture then it "SHOULD" be power of 2, but it doesn't say that for addTexture.

Code: Select all

virtual ITexture *  addRenderTargetTexture (const core::dimension2d< s32 > &size, const c8 *name=0)

Code: Select all

virtual ITexture *  addTexture (const c8 *name, IImage *image)

Why the difference between those 2 functions?

Also, how do you use addRenderTargetTexture?
It doesn't have a parameter for image or data. What texture is it adding? That confused me. (haven't tried it yet)

I don't get the point of giving the Texture a name, in addTexture().

Code: Select all

virtual ITexture *  getTexture (const c8 *filename) 

Does getTexture (as shown above) search the file structure and also search the loaded textures?
Because it actually says "filename" so I wasn't sure.
I don't really get the point or benefit of giving it a name (in addTexture or addRenderTargetTexture), as you want to reference it by the pointer you keep anyway.
The name is the filename isn't it? Why change it?

And I don't understand how to get a textures index when you create it. Otherwise what's the point of this function below?

Code: Select all

virtual ITexture *  getTextureByIndex (u32 index)

I couldn't see a function that returns the index on creation, and the texture doesn't keep the value.

And, how can getting the texture by index help anyway?
I don't see the case where you wouldn't already have a pointer to the texture anyway. I guess that's my problem!

So.. to me, all the IImage and ITexture creation functions are a bit confusing at the moment.

[BlindSide]

Seriously you should just use something like, http://irrlicht.sourceforge.net/phpBB2/ ... 077#183077, which is a sprite that supports scaling, etc. You can even use it with burning's video if you don't want to use 3D acceleration.

What you're doing is nothing short of insane IMO.

[Ulf]

What you're doing is nothing short of insane IMO.

This question below is important to me:

Why? (is it insane)

A. Because it's not as effective or fast as 3D?

B. Or just because it's harder to implement?

If it's B, that's not insane.

[BlindSide]

Because it's slow.

[Ulf]

Oh ok.
So Irrlicht is no good for 2D then?

I'm gonna stick with it for now anyway and see how it goes.

At the same time I'll look around for 2D renderers that are fast and check them out.

I really thought that 2D should be faster than 3D.

[BlindSide]

Most 2D renderers these days work the same way I suggested.

[Dorth]

They do, because graphic cards are optimized for vertex and texture space manipulation. You CAN bypass the vertice steps. Do really good shaders. Or just use friggin quads...

[Ulf]

Ok. Blindside,

I read up a bit.. I'll lay it down:

I got this from the Internet.

Advantages of 3D

3D is very flexible in three very important ways. The first way is the way in which the player sees the world presented. 3D games can draw the world at any angle and can have the player walk in any increment of steps they choose. Obviously, this can not be done from 2D images alone as there can be millions of possibilities in just a small area. Games such as Quake have shown the possibilities of drawing environments where you can move anywhere.

The second way that 3D's flexibility can be seen is also demonstrated by Quake, in the animation of 3D objects. To animate 2D objects in such a way would be very limiting in the angles they could be viewed from and the space for storing all of the animations could grow quite prohibitively. 3D animations also have the ability to be done on the fly. 3D objects can be given rules for deformation or movement that allow possibilities for being drawn that were not inherently programmed in to the game. This freedom is a major advantage over 2D games but has not been used very much in games currently.

The third way that 3D is flexible over 2D games is that objects can be created very simply by using mathematical equations or by placing primitive objects together to create new objects on the fly. This is the direct opposite from the way 2D works, however this advantage of 3D has never been used during the gameplay of any game that I am aware of. Game editors allow this in creating new levels or items but it has never been implemented in gameplay as of yet. Look out for this in the future though as it holds a lot of possibilities, most easily visualized in worlds such as 3D MUD's (Multi-User Dungeons).

My Summary on 3D:
Flexible.
Draw World at any angle.
Rotate and Scale easily on the fly.
Animation and Deformation.
Creating objects from primitives (though hardly used!).

Where 2D fails:
Cannot view the world at different angles.
Scaling and Rotation requires lots of memory to keep all the different copies with different sizes and orientation. (can still be done if necessary).
lock/unlock is slow. BUT If the image is kept, it's not so bad


Advantages of 2D

2D holds some advantages of its own over 3D displaying methods. The first advantage of 2D is that 2D images can currently be drawn in more detail than 3D images can be displayed. Objects can be drawn with more curves, faces and points than could be possibly for a 3D display system to currently handle. This can be a very large advantage as it makes better looking screens if your game does not require rotating views.

The second advantage of 2D is that it is relatively very fast to draw and process. Because all of the graphics have been pre-made all you must do is draw them to the screen and video cards have become very efficient at doing this. You can get the 20 to 30 frames per second that are required for real time video games easily. This leaves a lot of processor time left over for doing other behind-the-scenes calculations that a game using 3D displaying method would not be able to. For games that want to have a lot of processor power to use for the computer player's artificial intelligence this is a good way to go. 3D cards are becoming faster and faster but there are still calculations in a 3D world that may never be implemented in hardware, so 2D will be faster for a few years at least.

The third advantage of 2D is that it is currently faster to develop 2D display engines than it is to develop 3D ones. This may not stay a constant as 3D engines will eventually become standardized, but with their current rate of change, this is currently the case.

There is another advantage that the 2D often has over 3D, although this is not a black and white issue as 3D games can be made to display in the same way as 2D games are and then there is no advantage. In the case of a first person 3D display compared to an overhead or otherwise non-rotating 2D display many novice players or non-gamers find it easier to play in, understand and control the 2D interface better. Games like Descent and Quake take a level of control that more experienced players or gamers will have no problems with, but non-gamers often find it impossible to navigate through the world or aim and bump in to walls until they give up. The level of freedom that can be given in 3D games can often just be too much for novices or non-gamers so this needs to be taken into consideration as well. However, games such as MechCommander (Microprose) are displayed in the same format as a 2D game would be displayed, so in that case there is no advantage for 2D in this area.

My Summary on 2D:
Sharper Images (2D can be drawn with more detail) if you don't need rotating view.
2D is relatively very fast to draw and process. (that's a doozy!)
This leaves a lot of processor time left over for doing other behind-the-scenes calculations that a game using 3D displaying method would not be able to.
Shorter Development time! (now that's a doozy!)

If you do not need some of the areas of flexibility and want the ability to produce crystal sharp images and display them quickly and have a shorter development time then a 2D display method can be the way to go.

This is what I thought before, but everyone using Irrlicht says the opposite, but I don't think they actually know, or have tried 2D. So.. not too sure there..

I have a question:
Is 2D hardware accelerated in Irrlicht? (is that a noob question?)

Most 2D renderers these days work the same way I suggested.

They do, because graphic cards are optimized for vertex and texture space manipulation. You CAN bypass the vertice steps. Do really good shaders. Or just use friggin quads...

Yes, but Dorth, that doesn't mean that 3D is faster just because graphics cards are optimised. You gotta think, 3D has heaps more data involved to start with. In 2D it's just 2D Textures and Blit.

[BlindSide]

I refuse to answer because you misquoted me as Dorth

Jk, to answer your question:

Is 2D hardware accelerated in Irrlicht?

If you use the thing I linked you to then yes, but it would be good to do some batching etc.

Did you know that IVideoDriver::draw2DImage, etc, just does the same thing and places a quad in front of the screen?

[xDan]

> I got this from the Internet.
That does not reassure

> Is 2D hardware accelerated in Irrlicht? (is that a noob question?)
As far as I am aware, all HW accelerated graphics are 3D. Hardware accelerated 2D is using "3D" but with the ortho camera as said.

> In 2D it's just 2D Textures and Blit.
When it comes down to drawing a 3D triangle, transformations etc.. happen only per vertex (3 per triangle), and the "blitting" is not much more than for 2D. (maybe you interpolate an extra Z value per pixel or something). But it's really not that much different. Rendering 2 triangles for a 2D sprite on dedicated (3D) graphics hardware is FAST.

> "The second advantage of 2D is that it is relatively very fast to draw and process. Because all of the graphics have been pre-made all you must do is draw them to the screen and video cards have become very efficient at doing this"
Notice it says using the video card? I.e. it is "3D".

I think you are confusing the issue of software VS hardware rendering with 2D vs 3D, which is different. 2D can be done using hardware rendering (what you seem to call "3D"). Using ortho sprites, you can get all the apparent benefits of 2D.

> This leaves a lot of processor time left over for doing other behind-the-scenes calculations that a game using 3D displaying method would not be able to.
Assuming you use the videocard, neither have any differing affect on CPU as the graphics card is doing it all in both cases (mostly).

> Shorter Development time! (now that's a doozy!)
Yeah, if you were using an actual 2D engine, like Allegro or SDL. But you're using Irrlicht ,and Irrlicht does all the complex stuff for you anyway, so this is meaningless.

Using a proper 2D engine (with software rendering) does have benefits though. Like you can have very large textures (in HW there are texture size limits and you might have to chop up your 2D scenery into tiles) and non-power-of-two textures.

[BlindSide]

xDan said everything I would have said if I bothered typing for longer.

[Dorth]

Also, you misunderstood a lot of what you quoted. It compares using pre-rendered graphics (2d) vs real-time render (3d) and similar solution. It doesn't compare rendering the same texture in 2d from a quad, a pixel shader, a fixed pipeline or whatever.

[Ulf]

I refuse to answer because you misquoted me as Dorth

sorry mate
I knew it was you. I just can't spell.

Did you know that IVideoDriver::draw2DImage, etc, just does the same thing and places a quad in front of the screen?

No. I should have really looked there too before posting. But I did want a bit of discussion to get ideas (possibly different).

Rendering 2 triangles for a 2D sprite on dedicated (3D) graphics hardware is FAST.

Ok. I can see that. So, forgive my naivety but, when rendering with an orthographic camera with 3D quads, does that mean that only the plane facing the camera will be rendered (2 triangles per sprite)?

2D can be done using hardware rendering (what you seem to call "3D")

C'mon, don't mock me.

Yeah, if you were using an actual 2D engine, like Allegro or SDL. But you're using Irrlicht ,and Irrlicht does all the complex stuff for you anyway, so this is meaningless.

Hehe. I get your point. But I meant that making a 2D game engine with a 2D renderer requires less than a 3D game engine with a 3D renderer. Just purely that a 2D game engine is simpler.

Using a proper 2D engine (with software rendering) does have benefits though. Like you can have very large textures (in HW there are texture size limits and you might have to chop up your 2D scenery into tiles) and non-power-of-two textures.

I want non power of 2 textures.

I am using non power of 2 textures with IVideoDriver::draw2DImage.

So what's the go there? If Irrlicht isn't a proper 2D engine as you implied xDan.

Yeah, if you were using an actual 2D engine, like Allegro or SDL.

I'll look at the IVideoDriver::draw2DImage functions. As I should have.