Jump to content
  • Advertisement
Sign in to follow this  
Kyall

Unity So best way to provide interface....

This topic is 2477 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm working in C++, and I'm trying to figure out the best way to build an interface so that it's easy to use, but also clean. If you think about the textures that a graphics device holds, and the textures that are currently active on the device, in a wrapper with DirectX, the interface for letting the user set that texture can be:

graphicsdevice.SetTexture(0,&mytexture);
//or
graphicsdevice.Textures[0] = &mytexture;
// or
graphicsdevice.Textures.Set(0, &mytexture );


And I just want a quick opinion on what the community thinks is the best way to handle this type of interface problem, considering that when the texture is assigned, some code must be called by the wrapper to actually set the texture on the graphics device.

The code for the first and third option is pretty simple, but the code set up to do the second method is a goddamn mess. The second and third methods end up calling SetTexture anyway, because some directX code must be executed. In terms of interface design, SetTexture can be hidden as a private an the classes that overload the operators for the second and third methods are friends with the graphics device class. This sort of structure could be used for lights, zenable, a whole bunch of stuff to try and make the use of the class cleaner for the end user, at the cost of really, really messing up the base code with a whole heap of horrid overloading .

I'll put the code for the second method as simply as I can below:

class GraphicsDevice
{
class TextureBoard
{
public:
class TextureNode
{
public:
TextureNode( int ind, GraphicsDevice *_gdevice )
{
m_index = ind;
gdevice = _gdevice;
}
// Some -> and * operators
TextureNode& operator=( const Texture* texture )
{
m_texture = texture;
if( m_texture ) gdevice.SetTexture(m_index,m_texture);
else gdevice.ReleaseTexture(m_index);
}
protected:
Texture *m_texture;
GraphicsDevice gdevice;
unsigned int m_index;
};
TextureNode& operator[](int index) { return textures[index]; }
protected:
TextureBoard( GraphicsDevice *gdevice)
{
for(int i = 0; i < 16; i++) textures = TextureNode(i,gdevice);
}
TextureNode textures[16];
} Textures;

void SetTexture(int,Texture*);
void ReleaseTexture(int);

};



I don't know if that's going to be code correct since I just typed it into the text box here, but it should explain the complexity of building classes to do what the second interface method entails.

There's also
graphicsdevice.Textures[0].Set(&mytexture);
which is just as messy as the second option, but has the benefit of using a function so when the user releases they can call Release

So what's really the best method here, where I want to keep my code base decently tidy, but also group some stuff into mini-interfaces instead of having everything looped into one big ol interface.


Or as a separate way of looking at this:
I can create a template class that just overloads the assignment operator and the overload calls a function that is passed in as a template argument. But I can not do this easily when there's an array of elements to be used. Unless maybe I unionise.... I'll try that and report back.

Share this post


Link to post
Share on other sites
Advertisement
I'm not sure if you're seriously asking or being rhetorical, but I kind of came to that conclusion looking at it. I'd love to be able to dice stuff up into smaller more manageable pieces so it's not just a mess of functions, but I can't seem to find a better method than just throwing it all in the same class.

Share this post


Link to post
Share on other sites

// Sketch

raster_description desc(512, 512, channels::rgba);
// Todo: you might also want parameters for byte stride, planar vs interleaved rasters, ...

texture tex = graphics_device.allocate_texture(desc);
tex.set_raster(raster); // raster might contain "unsigned char" or "float". set_raster() could be overloaded, perhaps

// When the last copy of 'tex' is destroyed it is cleaned up (use reference counting internally)


One question you should ask yourself is whether the texture object should own the raster, copy it, share it, or refer to it. The latter is the most dangerous, but it appears to be the only one you've considered so far.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!