pvrtexlib CPVRTexture question

This topic contains 4 replies, has 2 voices, and was last updated by  Sniffy2 5 years, 8 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #30790

    Sniffy2
    Member

    Using the 2.10 sdk, I’m trying to create a CPVRTexture from a raw set of RGBA8888 miplevels stored in memory.   The interface below seems like the one  I want, but what exactly pData is is very vague.  Is it even possible to do what I want with this interface?   Should I simply concatenate the miplevel data, and if so do I worry about inter-level padding/alignment?  It’s not clear.

            /*!***********************************************************************
             @Function        CPVRTexture
             @Input            sHeader
             @Input            pData
             @Return        CPVRTexture A new texture.
             @Description    Creates a new texture based on a texture header,
                            pre-allocating the correct amount of memory. If data is
                            supplied, it will be copied into memory.
            *************************************************************************/
            CPVRTexture(const CPVRTextureHeader& sHeader, const void* pData=NULL);

    Sniffy22012-03-22 23:41:10

    #35595

    Hi Kris,

    pData is a single block of memory that in the same order that a PVR3 file expects (see the documentation for exact ordering, but it’s basically in order of descending MIP Level sizes). So if you have one chunk of data with all your MIP maps stored within it in order, then you can just pass it through to this. If your data is in a different order then you should instead create it with NULL, and then use “getDataPtr()” to copy your data into the texture.

    Hope this helps, please let me know if you need further clarification 🙂

    Thanks,

    Tobias

    #35596

    Sniffy2
    Member

    I think a CPVRTexture::saveToBuffer(void *pBuffer, int nMaxSize)   would be helpful.
    I think the only other way to do this is to grab the header and miplevels individually using getHeader() and getDataPtr(), and copy them all out into a continguous region  (or call saveToFile, and read the file you just wrote back into memory–kinda of a waste of IO)

    Actually, if you just added these simple accessors, it would probably be sufficient:

    class CPVRTexture
    {
         const void *getAllDataPtr(void) const { return m_pTextureData; }
         size_t getAllDataSize(void) const { return m_stDataSize;}
    }

    Sniffy22012-03-27 05:03:56

    #35597

    A save to buffer could make sense, I’ll consider adding this for the next release. Out of curiosity, what would be your use case for this?

    The main problem with the getHeader/getDataPtr approach is the metaData, which is a bit of a problem as it’s stored in a map class, so lots of pointers to pointers. I’m planning on extending the meta data access later. However in the meantime this would probably be a suitable approach – the meta data is not necessary for using the texture.

    If you call getDataPtr() with no arguments, it returns what you’re expecting for “getAllDataPtr” anyway. The same is true for getDataSize().

    #35598

    Sniffy2
    Member

    >Out of curiosity, what would be your use case for this?

    Saving out to a custom ‘package’ stream file that contains other types of data as well.  The d3d9 D3DX library contains a similar function, D3DXSaveTextureToFileInMemory.  I know I can call CPVRTexture::saveToFile and read the .pvr file back in to do this, but this feature would avoid the extra disk i/o.

    >If you call getDataPtr() with no arguments, it returns what you’re expecting for “getAllDataPtr” anyway. The same is true for getDataSize().

    Thanks, I didn’t notice the PVRTEX_ALLMIPLEVELS default for getDataSize

Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic.