Results 1 to 2 of 2

Thread: ClanLib 0.9 - CL_Texture vs CL_Image vs CL_Sprite

  1. #1
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default ClanLib 0.9 - CL_Texture vs CL_Image vs CL_Sprite

    I have a general query in relation to Textures, Images and Sprites

    We currently have:
    CL_Texture:
    This contains the image held on the graphic card

    Basic Attributes:
    Level Of Detail control (for mipmaps)
    Magnification filter
    Wrapping mode
    CL_PixelBuffer:
    This contains the raw image held in cpu memory
    CL_TextureGroup:
    This is group of CL_Texture's, with the ability to allocate "free space" within the texture

    When you allocate free space, it is returned via CL_Subtexture
    CL_Subtexture:
    This contains an image within a texture

    Attributes:
    Texture - usually a reference to the texture in CL_TextureGroup
    Geometry - The rectangle of the image
    CL_Image:
    This contains an image within a texture

    Attributes:
    Texture - The CL_Texture
    Geometry - The rectangle of the image
    Color - Not implemented
    Scale - Not implemented
    Translation hotspot / origin - Not implemented
    CL_Sprite:
    This contains an image within a texture or multiple textures

    Attributes:
    Texture - The CL_Texture
    Geometry - The rectangle of the image
    Color
    Scale
    Translation hotspot / origin
    Rotation
    This leads onto a few design questions:

    What attributes should CL_Image contain?
    At the moment, most of them are currently unimplemented

    I believe that the intention is to keep CL_Image simple (for speed reasons)

    But we can still have: "if (rotation_is_set) { calc_rotate(); }"
    ...but if we do, would the extra bytes used and calculations required outway the advantages of having it

    Rotation/Scale/Translation can be done externally to this function using:
    CL_Image::draw(CL_GraphicContext gc, const CL_Rectf &src, const CL_Rectf &dest);
    Should CL_Image base class be CL_Subtexture?
    Note: if the CL_Image attributes are removed, then CL_Image is CL_Subtexture - So maybe CL_Subtexture could be removed?
    Should CL_Sprite be built using multiple CL_Image's
    So CL_Sprite_Impl::SpriteFrame contains CL_Image, instead of CL_Texture

    It CL_Image attributes exist, what about the attributes like scale, would CL_Sprite still require it's own scale (for finer control)

    With this, it should be easier to have animated controls in the gui:
    Code:
    pushbutton.set_image( mysprite.get_current_image() );
    (controlled by the user application)

  2. #2
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    After a discussion, I now understand why ClanLib uses the current method.

    The reason CL_Image was created (and why it should be kept separate) is for code simplicity. CL_Sprite does everything, although it is fast, it is not very fast.

    CL_Image contains just what is required to display a rectangle texture, thus when drawing 1000ís of images, there is a very little overhead.

    You can still have animated textures in the GUI - an example demonstrating this, may be made in the future (if required).

Similar Threads

  1. CL_Sprite animation control in Clanlib 8.1
    By mcgregor927 in forum Official ClanLib SDK Forums
    Replies: 1
    Last Post: 03-29-2009, 09:58 PM
  2. CL_Sprite mouse cursor
    By AlfaRed in forum Official ClanLib SDK Forums
    Replies: 2
    Last Post: 02-11-2009, 09:29 AM
  3. cl_sprite with multiple frames
    By dwune in forum Official ClanLib SDK Forums
    Replies: 7
    Last Post: 08-29-2008, 08:49 AM
  4. CL_Sprite problems
    By gmatt in forum Official ClanLib SDK Forums
    Replies: 0
    Last Post: 06-29-2007, 05:38 PM

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •