Associate a texture to an object (from a data-model, not graphical point of view)

Raveline
  • Associate a texture to an object (from a data-model, not graphical point of view) Raveline

    I'm writing a roguelike where objects and floor can be made of different materials. For instance, let's say we can have a wooden chair, an iron chair, a golden chair, and so on.

    I've got an Object class (I know, the name is terrible), which is more or less using a composite pattern, and a Material class. Material have different important properties (noise, color...). For the time being, there are 5 different instances of materials, created at the initialization of the game.

    How would connect an instance of Object with one of the 5 instances of materials ? I see three simple solutions :

    • Using a pointer. Simple and brutal.
    • Using an integer material-id, then get the materials out of a table when engine manipulates the object for various purposes (display, attack analysis, etc.). Not very beautiful, I think, and not very flexible.
    • Using an integer material-id, then get the materials out of a std::map. A bit more flexible, but still not perfect.

    Do you see other possibilities ? If not, what would you choose (and why) ? Thanks in advance !

  • It seems you want new types of Materials to be able to be created at runtime. Then I don't see the problem with having a pointer to the Material of the object; it's how I would do it. Perhaps elsewhere in the program (e.g. in the factory class which creates these Object instances) you would have an array of all the Materials, to keep track of them and allow for choosing between them. Also you would need to either never delete a Material once it's created, or keep track of the references to a material so that if you want to delete the material then you reassign new materials onto all the objects which were previously using that material. You certainly don't want to delete a Material in memory, only to have Objects still pointing to that memory location which is now invalid!

    The problem with the integer ID which is a position of an array, for example, is if that array is manipulated, for example if a material is deleted, then you need to either put a 'null' in that position and never use it again, or you need to loop among the objects and change their material ID when you change the array. So for example if you have three materials, and an object points to material 1, then if you delete material 1 you need to either put a null in that place, or change the object id to e.g. -1 before you allocate a new material in position 1 (or else the object is magically given a new material!).

    Also an std::map seems like unnecessary overhead in this case. It seems to me that you don't really need the map when you could use a pointer and reference counting as mentioned above. You could certainly use it though, keeping in mind similar downfalls such as mentioned in the previous paragraph; e.g. you still need to make sure the IDs are unique among all materials deleted or not, or else you could get objects whose materials get reassigned just because the material gets deleted and a new one gets put in with the same ID as the old one.

    If however Materials can't change at runtime, you could of course make an enum with the material type, and the object would have an element of that enum (or a pointer to that element; my c++ is rusty).

  • From my point of view, array indices and pointers are two flavors of the same thing -- and both are simple and direct, which is good for a game.

    You could introduce an abstraction layer, and make this more complicated, but you have not identified any requirements to help design such a layer.

    In fact, as near as I can tell, you only have 5 materials, and they will not change.

    Anyways, I see nothing wrong with using a pointer, and I see nothing wrong with using an array index. If you do see something wrong with either of those, I think that that means you have requirements which you have not expressed here.

  • Use the pointer. You haven't identified any requirements of the system beyond that you should be able to go from Object to Material, and the pointer is the simplest and most direct approach by some way.

  • The OO way to do it is to create each new object with a material and colour as properties by instance passing. For example in Python:

    class Chair(Object):
        def __init__(self, colour, material, position):
            self.colour = colour
            self.material = material
            self.position = position
        ...
    

    You would then create the object with those properties:

    chairmaterial = Material("wood")
    mychair = Chair(COLOUR_GREEN, chairmaterial, (0,0))
    

    Rendering could then just be dependent on the Chair class for shape, and the material and colour for colour and texture.

Tags
c++ data-structure
Related questions and answers
  • with different types of objects in the same scene. I was also thinking about making a MeshNode class and then make a Mesh object that contains them, but then I have some conflict on where to store some data... for my needs. Ah and I forgot to mention that nodes can have hierarchy, but this is not a problem if the frame data is reduced. The structure instances don't get duplicated unless any value changes. When... them to be attached to the node in most cases, even if I allow setting global lights to the scene. @Nicol: Yes that's what I'm trying to figure out. You can see the code doesn't rely on any hardware

  • What tools, patterns, or best practices would you recommend to implement the quest mechanics given below listed requirements? I am talking about software architecture (how generic should you be) and choices for object wiring, event subscription, and representation of conditions. Mentioning of tools / libraries you have successfully used are welcome. Edit: If you are using scripting, what setup... with arbitrary conditions quests would range from simple: talk to A - kill 5 B - talk to A - permanently increase health to quite involved: use item in area X - go to area Y - a bot will spawn - kill bot

  • Dear all, this is going to be tough: I have created a game object factory that generates objects of my wish. However, I get memory leaks which I can not fix. Memory leaks are generated by return... vector container. I have chosen this way because I parse an object map file. I have object type IDs (integer values) which I need to translate them into real objects. Because I have over 100 different object data types, I wished to avoid continuously traversing very long Switch() statement. Therefore, to create an object, I call vFactoriesnEnumObjectTypeID via CGameObjectFactory::create

  • GameSubsystems) can implement registerComponent(Component*). pro. Components and GameSubystems know nothing about each other. con. In C++ it would look like ugly and slow typeid-switch... pointers to some of Components. GameSubsystem is a very powerful and flexible abstraction: it represents any slice (or aspect) of the game world. There is a need in a mechanism of registering..., GameSubsystemParticleEmmiter can be merged into GameSubsystemSpatial (to place all audio, emmiter, render Components in the same hierarchy and use parent-relative transforms). con. Every-to-every check. Very

  • I'm writing a game engine which is going very fine. However, I'm now posed with handling textures. My Engine is in 2D, for simplicity reasons mostly to get a good idea of how to work with OpenGL. I do this in C++, and I have a hierarchical set-up when it comes to classes. There's a base class and some other classes derive from that. So now I'm onto the part where I want to load up some textures..._interior_cave1.xml, which contains all the information on what textures are used. It loads the textures as said by the tileset-XML-file, it gives them an ID and then the SceneManager-class knows how to lay out

  • controls easy to set up (i'm using SFML and Box2D at the moment) I don't want to re-invent things like buttons, arrows being placed wherever the mouse is located, and more game specific items... that.... Allows easy setup of controls for a game Makes events like clicking and holding on an object easy to setup, as so objects can be dragged around afterward Are there any simple libraries or resources out there that i can use to avoid spending much of my time coding these now standard input devices/tecniques?

  • over-thinking it. If anyone thinks they can help, please take a look at the code below and help me try to improve on this if you can. I would like to refrain from using a library to handle this (as I... be crucial, let me know and I'll provide the necessary information. Finally, for anyone who can help, providing code would be very helpful and much appreciated. Thank you again for your help! Edit: I...I am trying to create a 2D platformer (Mario-type) game and I am some having some issues with handling collisions properly. I am writing this game in C++, using SDL for input, image loading, font

  • After careful consideration to use middleware, I have decided on creating my own 3d file format format to export meshes from 3D authoring application (Softimage) into my game. I will need to export the following: Vertices Indices Normals UVs Material Information Animation information (no clue, how to import it) Collision mesh Game Properties defined within 3D authoring tool (object intelligence, aggressivity, etc..) ..another assets.. Can I kindly ask for a hint, how to construct my custom file format. How to organize data within my files, please? Does anoybody have a good adivce

  • I am quite new to OpenGL, I have managed after long trial and error to integrate Nehe's Cel-Shading rendering with my Model loaders, and have them drawn using the Toon shade and outline...? Something unnecessary that maybe you guys could spot? Both MD2 and 3DS loader have an InitToon() function called upon creation to load the shader initToon(){ int i... by material and draw them for (int j = 0; j < Objects[i].numMatFaces; j ++) { // Use the material's texture Materials[Objects[i].MatFaces[j

Data information