programmatically get size of texture

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
Post Reply
Cube_
Posts: 1010
Joined: Mon Oct 24, 2011 10:03 pm
Location: 0x45 61 72 74 68 2c 20 69 6e 20 74 68 65 20 73 6f 6c 20 73 79 73 74 65 6d

programmatically get size of texture

Post by Cube_ »

currently I'm attempting to play a bit with textures, specifically I want to iterate over every pixel - simple enough, I just use two nested for loops, one for rows and one for columns.

Problem is, I'm not sure how I'd get the size of the image - it can be of n size, I can't know the size ahead of time.

So, how would I do this?


current state of the function (mostly borrowed from http://irrlicht.sourceforge.net/forum/v ... 11#p169211 )

as is evident I just need to programmatically get the texture size and I can iterate over the pixels.

Code: Select all

void loadmap(std::string input)
{
    ITexture* texture = driver->getTexture(input);
 
    video::ECOLOR_FORMAT format = texture->getColorFormat();
 
    if(video::ECF_A8R8G8B8 == format)
    {
        u8 * pixels = (u8 *)texture->lock();
 
        u32 pitch = texture->getPitch();
        for(int row = 0; row != 1; row++)
        {
            for int(column = 0; column != 1; column++)
            {
                SColor * pixel = (SColor *)(pixels + ((row * pitch) + (column * sizeof(SColor))));
                (void)printf("R %d, G %d, B %d\n", pixel->getRed(), pixel->getGreen(), pixel->getBlue());
                //I'll do other stuff here
            }
        }
    }
    else
    {
        (void)printf("Wrong color format for map %s\n", input.c_str());
    }
 
    texture->unlock();
}

also: I want to actually use the SColor of the pixel in question, but I can't figure out a good way to do that - perhaps casting to string and then doing string comparison (I'm looking for the exact hexadecimal color value - that's really just a getRed, cast to hexadecimal, getBlue, cast to hexadecimal, getGreen, cast to hexadecimal etc - then treat it as a space delimited string, such as FF 0B FC - compare to master list, decide what to do) - if this is a solid enough plan, then ignore this subheading - if it's a terrible idea, please elaborate as to why and what would be a better solution. This step does not have to be fast, it happens during level loading (levels are stored as png images in this project - this is so that content creation is very fast).
"this is not the bottleneck you are looking for"
CuteAlien
Admin
Posts: 9734
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: programmatically get size of texture

Post by CuteAlien »

Always check the docu: http://irrlicht.sourceforge.net/docu/cl ... xture.html
ITexture::getSize to get the size.

But one note - ECF_A8R8G8B8 is in memory in BGRA order - not ARGB as one might expect. It's also documented, but people tend to miss it. Reason is historical (and goes back to DirectX which called it like that once... was something that allowed them to load certain ARGB files into memory faster)
And I think SColor is in ARGB - so just casting won't work. You have to get 4 bytes and set SColor from that (or use the bytes directly).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Cube_
Posts: 1010
Joined: Mon Oct 24, 2011 10:03 pm
Location: 0x45 61 72 74 68 2c 20 69 6e 20 74 68 65 20 73 6f 6c 20 73 79 73 74 65 6d

Re: programmatically get size of texture

Post by Cube_ »

I was just going to use a stringwriter and write the output of int red, green, blue = pixel->getRed,Green,Blue respectively (mainly because I don't know the structure of an scolor and it should be fast enough for getting a bunch of pixel colors - especially since I want to format them to hexadecimal first)

As for ITexture::getSize, huh. I expected google to find it, hence why I asked here (site:irrlicht.sourceforge.net get texture size didn't give any obvious results off-hand) - thanks anyway, with that information I can skip my ugly hardcoded hack (which works for the test image I'm using, no guarantee about anything else though).
was something that allowed them to load certain ARGB files into memory faster
iirc BGRA is more cache friendly for some encoded files - it hardly matters on modern hardware.

as for:
ECF_A8R8G8B8 is in memory in BGRA order - not ARGB as one might expect. It's also documented, but people tend to miss it.
I'll keep that in mind, probably should write it down. Although it doesn't matter at this point because I don't directly read the color, I fetch each channel individually from an SColor which more or less means I can ignore the implementation details - it's not a performance critical module anyway, unless it takes more than 10 seconds on this machine at which point it needs optimizing (10 seconds to load a level is the max I find acceptable for a 5400rpm hdd)
"this is not the bottleneck you are looking for"
Post Reply