class TextureHandle {
public:
    GUID_Type id;
};

Quote:

The biggest issue is your requirement that the renderer can alter IDs.

class TextureResource { };

class TextureResource_D3D : public TextureResource { };

class TextureResource_OGL : public TextureResource { };

// Use:
TextureResource* myTexture;
renderer->createTexture( myTexture, creationParams );

• cheap to pass around
  
• contents are easily and safely examined - useful for state sorting for example
  
• type-safety can be achieved by wrapping in a class
  
• contents are too easily dangerously modified
  
• (re)serialisable
  
• All API specific code is kept in one place/class
  
• render-device owns all GPU resources
  
  • during a device-lost state the render-device can release and re-load all resources and the client need never know or care
    
  • all services are performed through the render-device (potential for optimisations)
    
  • most of the costly virtual methods calls are made only at initialisation and kept to a minimum at render-time.
    
  • Since the render-device is the only polymorphic class, if the platform can be known at compile-time (when targetting a specific platform for example) then virtual functions can be inlined (circumstances permitting) or atleast cost no more than a non-virtual call.
    
  • Potential for changing API on the fly! (same argument as during device-lost state)
    
  • Under OGL
    
    • GPU resources from the API are integers handles anyway and can be trivially cast directly into unsigned int handles
    
    
  • Under D3D
    
    • GPU resources from the API are class instances, the unsigned int handle is used for a simple array lookup - alternatively the device could cast a D3D-resource pointer into a handle-type (perhaps a handle should be an unsigned long in this case)

• pointers are cheap to pass around
  
• automatically typesafe
  
• must not be tempted to delete a pointer
  
• can be dangerously modified
  
• harder to safely examine the address of a pointer - e.g. for state sorting
  
• cannot be serialised
  
• API specific code is distributed to many classes
  
• expensive virtual calls during rendering usually need to be made all over the place
  
• each resource needs to own a reference to its render-device - memory overhead, possibly even one virtual call to the resource makes another virtual call to the render-device.
  
• client effectively 'owns' the resources not the render-device (though the device can still keep a local copy)
  
  • During a device-lost state the client must re-request all their resources - all resource-owners need to be notified
    
  • No chance of the render-device optimising resource use since it doesnt own them.
    
  • changing API on the fly is difficult at best
    
  • little chance of compile-time optimisations.

Quote:

Original post by Trenki I don't see why there is any difference. You can't use the GUID directly just like you can't use the pointer directly for sorting.

Quote:

This is not your problem. If the client modifies it even if he isn't supposed to it is entirely his fault.

Quote:

I don't know how you intend to serialize it but only serializing the GUID number won't cut it. And for a graphics API you probably don't need serialization anyway.

Quote:

And if you use OpenGL shaders you can't simply store the returned GLuint because you can't use the same for the next time ...

Quote:

This isn't entirely true. Where you put your methods is not dependant on this choice. Take a look at DX9! The also have classes and I don't think that is bad.

Quote:

Yeah, then you get a fat interface which isn't good either.

Quote:

Changing API on the fly: I wouldn't go there. It is a complete mess.

Quote:

Ok, not a hash-map but an array lookup (potentially even slower)

Quote:

Virtual methods: You claim they are slow. Sure, they are slower than a normal function call and probably cannot be inlined but it solely depends on how often you call these virtual methods and how expensive the method body is. Generally I would say virtual methods are no problem (even though I had to reprogram my own software rasterizer to not use virtual functions because 1 call per pixel with a small method body caused to much overhead)

Quote:

About wrapping you GUID into a class for type safety: You could forward declare a struct/class and make the handle a pointer to this struct (opaque pointer). You gain type safty and don't expose the internal GUID. But still I don't really like your design.

Quote:

DX9 is well designed but DX10 is even better. Personally I know only OpenGL. It is good but has some quirks. Hopefully Longs Peak makes it better.

Quote:

I wonder how Ogre does all this as it also supports both, DX and GL.

Quote:

Quote: And if you use OpenGL shaders you can't simply store the returned GLuint because you can't use the same for the next time ... Do OGL shaders return a different ID everytime then? Are they not like texture objects where you generate an ID (either yourself or using glGenTextures)?

Quote:

Quote: Ok, not a hash-map but an array lookup (potentially even slower) An array lookup slower than a hash-map lookup? A hash-map lookup (implementation dependant ofcourse) requires a hashing routine followed by an array lookup followed by a linked list iteration or a repeat of the hash routine. Or were you thinking of a worst-case O(N) linear search? I mean a cheap O(1) lookup.

Quote:

Quote: About wrapping you GUID into a class for type safety: You could forward declare a struct/class and make the handle a pointer to this struct (opaque pointer). You gain type safty and don't expose the internal GUID. But still I don't really like your design. Could you maybe explain this further?

Quote:

Original post by Trenki For shader objects you can't choose your own but you must use the one returned by glGenShader(). Nvidia seemed to return simple integers incrementing the returned id at every shader creation. ATI probaly returned a pointer as the numbers were more arbitraty.

Quote:

Quote: Ok, not a hash-map but an array lookup (potentially even slower) An array lookup slower than a hash-map lookup? A hash-map lookup (implementation dependant ofcourse) requires a hashing routine followed by an array lookup followed by a linked list iteration or a repeat of the hash routine. Or were you thinking of a worst-case O(N) linear search? I mean a cheap O(1) lookup.

Quote:

You can put a struct without a body in a header file. You can have pointers to this struct without requireing the body either. This is called an opaque pointer as it has a type but what is inside it is unknown. You could maybe use such a pointer as handle. (Google opaque pointer -> wikipedia)

Quote:

Original post by dmatter Quote: Quote: Quote: Original post by Trenki Ok, not a hash-map but an array lookup (potentially even slower) An array lookup slower than a hash-map lookup? A hash-map lookup (implementation dependant ofcourse) requires a hashing routine followed by an array lookup followed by a linked list iteration or a repeat of the hash routine. Or were you thinking of a worst-case O(N) linear search? I mean a cheap O(1) lookup. You have a GUID and you need to map this to the instance of the object; right? So how would you do that in O(1) with a simple array lookup?? How big is your array? Yes I need a 1->1 mapping between GUID and object instance, an array provides exactly that (the size is equal to the number of resource instances created) e.g. // At initialisation std::vector< LPDIRECT3DTEXTURE9 > textureResources( numTextures ); // Get a D3D texture resource from a GUID with an O(1) lookup LPDIRECT3DTEXTURE9 pTex = textureResources[ textureGUID ];

Quote:

Original post by swiftcoder And what happens when the user destroys/releases the first resource? Do you leave the array as is and re-use the slot? Or do you actually remove the item from the array, which would be extremely slow, and would invalidate all the other GUIDS.

Quote:

If you really can't bring yourself to pass pointers around (and honestly, I don't think your reasoning not to is very compelling), how about stashing the resources in a std::list and using std::list::iterators as your GUIDs? (it isn't perfect, but better than GUIDs indexing a huge array).

Quote:

But again, why not use pointers? All you are doing is adding in the cost of a table lookup to retrieve the pointer. You might as well just use the pointer directly.

Quote:

Original post by dmatter how did you intend on allowing the renderer to modify the m_id member on an already created handle?

Quote:

Original post by dmatter Quote: Original post by swiftcoder And what happens when the user destroys/releases the first resource? Do you leave the array as is and re-use the slot? Or do you actually remove the item from the array, which would be extremely slow, and would invalidate all the other GUIDS. Nah the slot is re-used or ignored.. actually it doesnt matter since this is an implementation detail that is abstracted away, the implementation is in a DLL and can be changed willy-nilly.

Quote:

Quote: If you really can't bring yourself to pass pointers around (and honestly, I don't think your reasoning not to is very compelling), how about stashing the resources in a std::list and using std::list::iterators as your GUIDs? (it isn't perfect, but better than GUIDs indexing a huge array). Again, the specific renderer implementation is reponsible for managing this (or it could delegate the task), whether it uses a list, an array, simple casts from OGL handles to integer handles.. its all taken care of under the hood, if the implementation changes the handles dont so nothing breaks.

Quote:

Quote: But again, why not use pointers? All you are doing is adding in the cost of a table lookup to retrieve the pointer. You might as well just use the pointer directly. void pointers? Or you mean using polymorphism and wrapping API specific resources? void pointers are no more typesafe than using handles (and infact the implementation might choose to (somewhat riskily) cast a pointer into a handle so theyre almost synonymous with each other.) using polymorphism requires virtual calls, which typically require function pointers behind the scenes that are looked up from a vtable anyway, so actually in this respect a table lookup is not a greater overhead than a virtual call.. both fairly minimal costs but a virtual call is always going to cost the same, with handles the cost can be minimised further depending again on the actual implementation.