Thread: I do not want to belive this!

  1. #1
    Hail to the king, baby. Akkernight's Avatar
    Join Date
    Oct 2008
    Location
    Faroe Islands
    Posts
    717

    I do not want to belive this!

    Well, me and Elysia are kinda 'arguing' about game programming and how to load textures... And since Elysia is always right, I can not say anything else than I do not want to belive!
    Well, to the case, Elysia claims that we should make a class for each texture, we're talking about 100+ textures here, since it's a game! :O
    Now, it's also good practise to make files for each class, that's 100+ files for textures, maybe 200+ since they might need .h and .cpp files (very unlikely tho)
    So I want your suggestions, do we really need to do it this way? I personally have no other flexible way, except making some kind of array/vector to hold the textures, but there's no way you can keep track of the textures that way since, texture[76] would be a headache to remember which one it was...
    So again, what do you people think we should do?

    SOLVED!
    On it's own :O
    Last edited by Akkernight; 03-31-2009 at 04:08 PM.
    Currently research OpenGL

  2. #2
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Code:
    GetTextureByName( "Stone Wall 1" );
    So what was the argument for making a different class for each texture?


    Quzah.
    Hope is the first step on the road to disappointment.

  3. #3
    Registered User
    Join Date
    Mar 2007
    Posts
    416
    My opinion is the same as Elysia's. In my game I somewhat still work on I have a class that loads all the required data for a mesh, including the texture. So essentially I have a class that holds the mesh vertices, frame animation, texture, texture coordinates, UV coordinates, and other variables I need. It helps keep things organized, self contained/monitored, and cuts down on extras.

    For what it's worth, I use to load textures without classes, and loaded them as I needed them by hand in to variables (vs loading them when the mesh is loaded/closed and storing it in a class). This was hard to handle once I started to hit a certain number of textures.

  4. #4
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Although, currently, we used a somewhat different system. Each object is represented by a class of its own; though textures are not.
    The idea is simple: each object can be unique, and we'd have to write the code to load and initialize the object somewhere anyway, so why not a different class?
    Textures aren't represented by objects, though. It is represented by one class, Texture, that contains all then necessary data for a loaded texture.
    The idea here is that textures aren't unique. The have a filename, coordinates and dimensions, and that is all. Keeping an instance of every texture in memory would be bad, too, since it would eat up all memory available. Instead, I abstracted it by storing the necessary data to load a texture into a struct and pre-defined it.
    An object can use one or more textures, so the object (which is its own class) will load the textures themselves.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    Registered User
    Join Date
    Oct 2008
    Posts
    1,262
    Here's the general rule:
    If classes are pretty much identical, except for a filename or some string or integer, it should generally be a single class.

    Textures only differ in filenames, so should be used in the same class. Simply specify a filename, and it's loaded. Maybe a single texture-library class the way quzah suggested. Or maybe just a class instance with the a readable name, if possible. But for 100+ textures, quzah's method is probably best.

    Objects... Well, it depends. Objects are generally loaded from files that describe the objects. In that case, a single class should do (for instance a Model3DS class). If the objects are described inside the source code, you should use a single class per model. And for some special models, this could be really useful.

    Of course, if you extend those types, all types should be inherited from a single type, like Model.

  6. #6
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Textures can be a single class but it may be overkill especially in Direct3D. Direct3D already has textures wrapped into IDirect3DTexture9 so a hash map of string or unsigned int to IDirect3DTexture9 would suffice.

    If you do not want to use a hash map you can use a std::map.
    typedef std::map<unsigned int, IDirect3DTexture9 *> TextureMap;

    The texture manager should wrap the D3DXCreateTextureFromFile() family of functions inside it's create or add function. This way the behavior of the entire texture system is encapsulated in the texture manager.

    In Elysia's favor there is one advantage to wrapping textures. It would allow you to use boost::shared_ptr when you return the textures. This would enable you to return an actual pointer to the texture. Trying to use a boost container on a pure COM object would be a bad idea. If you do not wrap IDirect3DTexture9 then you cannot use boost.

    Returning a raw pointer and/or a raw COM interface pointer would not be the best practice but if you are the only one using this code you might get away with it. I've written several Direct3D texture managers that utilize either a hash map or an STL map and they have all worked just fine. It is very nice to be able to cleanup and create the textures in a central place as well as hand the textures out to any objects needing them. It allows efficient use of video memory by only loading each texture used in the system one time but allowing multiple users of the texture.
    Last edited by VirtualAce; 04-01-2009 at 04:30 PM.

  7. #7
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Ah, but we don't use D3D. We use a custom engine, really.
    (If this is going to become a game or not in the end, I don't know, but it's still fun trying to mess around with things even if it doesn't become anything.)
    And the main reason for a texture class is due to the poor engine system, which uses LoadTexture and UnloadTexture functions. So the class wraps a texture and calls LoadTexture upon construction and UnloadTexture upon destruction. Simple RIIA technique.

    I don't really see a problem with using shared_ptr's with raw COM objects, since you can use a custom deleter, and if you keep the chain (ie, not using any raw instances of the COM object), then there is nothing to fear.

    The original problem was perhaps misworded. I don't know exactly what Akkernight was thinking, but the problem wasn't about storing the textures (ie using a map), but rather how to create the textures in the first place, in which each texture might have had a different class. Now, this isn't necessary since no texture is unlike the other (they are all the same). Objects that use these textures can vary significantly, however, which is usually why most of them should have a different class.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #8
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    I don't really see a problem with using shared_ptr's with raw COM objects, since you can use a custom deleter, and if you keep the chain (ie, not using any raw instances of the COM object), then there is nothing to fear.
    You just contradicted yourself.

    ...in which each texture might have had a different class
    But each texture should not have a different class. Each texture should be a unique instance of the texture class.

  9. #9
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by Bubba View Post
    You just contradicted yourself.
    Not really...
    Code:
    MyCOMThingy COMmy;
    boost::shared_ptr<MyCOMThingy> ptr(COMmy, &ComDeleter);
    // Don't use COMmy anymore and all will be fine.
    Quote Originally Posted by Bubba View Post
    But each texture should not have a different class. Each texture should be a unique instance of the texture class.
    My sentiments exactly.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #10
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Quote Originally Posted by Akkernight View Post
    Well, me and Elysia are kinda 'arguing' about game programming and how to load textures... And since Elysia is always right, I can not say anything else than I do not want to belive!
    Well, to the case, Elysia claims that we should make a class for each texture, we're talking about 100+ textures here, since it's a game! :O
    Yeah ... While you are at it why not make a phone book for each phone number.

    Class per model is good, but class per texture seems a bit cumbersome and inelligant.

  11. #11
    Registered User
    Join Date
    May 2007
    Posts
    147
    I've seen and worked with several designs.

    Consider this one:

    class Material
    class Texture

    Material uses a texture, and includes instructions about how the texture is applied. This includes opacity, perhaps, shininess, and other ideas.

    Descendents of Material allow for various multi-texture concepts, including reflective textures, blended textures, various light baking maps, etc.

    That is, we have:

    class ReflectiveMaterial : public Material
    class ShinyMaterial : public Material
    class ComboMaterial : public Material
    class TranslucentMaterial : public Material
    class Glass : public Material

    Perhaps others, including special effects for fire, smoke, water, etc.

    Material make use of textures, which may be a texture library. That is, one texture may have many textures in it, such that material may identify instructions that 'select' a portion of the texture of use in a specific context, including, perhaps, animated materials.

    A twist on the design may allow for combinations of material types - shiny wood, matte glass, refractive glass, shiny-reflective-translucent-animated material.

    I implemented this in OpenGL (of one flavor or another).

  12. #12
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Last post here was 18 days ago. Closed.
    Please do not bump old threads.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. God
    By datainjector in forum A Brief History of Cprogramming.com
    Replies: 746
    Last Post: 12-22-2002, 12:01 PM
  2. Do you belive in magic
    By datainjector in forum A Brief History of Cprogramming.com
    Replies: 21
    Last Post: 09-16-2002, 03:42 AM