Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualJuliean

Posted 07 April 2013 - 07:00 AM

In any case, you'd kind of expect liskov to be violated anyway. You really can't expect a D3DEngine to work happily if you swap out half the textures with COpenGLTexture. It just plain wouldn't work, regardless of how it gets at the data inside.

 

Thats what I thought for a moment, too. The I decided not to post it because I thought it sounded a little too obvious and stupid to me. Seems I was wrong^^

 

 

It seems to me that the way to do that is to have the api specific engine implementation worry about storing api specific texture resources. CTexture stops storing a texture, and instead becomes a resource locator. It can expose functions which act on the texture, and internally it implements that by making a call to the engine, which can look up the texture and perform the actual modification.

 

Ah, that sounds like a brilliant idea! It goes a bit in the direction of what I was actually doing, as for one thing I was indeed storing my textures in a texture module class of my graphics engine. I would reference them by file or specifiy name, and have that module functionality to set a texture as render target, clear it, etc... . Now having those functions on the texture itself so I don't need to use the module for everything just sounds natural to me, too. Having the actual API specifiy texture stored in the texture module and CTexture just use this won't make a huge difference to implement. Then when passing the texture to e.g. the Effect, it would pull out the textures hash, and tell its own action handler to set the texture with that hash to the cBuffer... right? Sounds just like what I've been looking for, thanks!

 

Just a quick question about your code, too:

 

class CTexture : public ITextureAccessor, ITextureMutator

I assume those are the interfaces whose getter / respective setter the CTexture class in your example implements, right?

 

 

Oh, another big question concerning the whole interface thing. I assume you have willingly not made CTexture another interface, right? I don't know how to put that in a question that won't make me sound like I have no idea what I'm talking about, but... well, since that train has left the station: Until now I've always conducted tests of my code by clicking, using etc... every feature I added. Since I've read about test driven developement and belive it to be very useful and making bug tracking way more easy for me, I want to give it a shot in the near feature. Now, I don't want to post a question to a different topic here, but I've heard that TDD is somewhat hard to conduct in its full feashion in c++, and that using "interfaces" whereever possible it one of the main requirements (or to make things easier). Is this true? Unfortunately I didn't find that much info on that topic on google, but since I'm at the whole interface thing, I might ask here as well.


#2Juliean

Posted 07 April 2013 - 07:00 AM

In any case, you'd kind of expect liskov to be violated anyway. You really can't expect a D3DEngine to work happily if you swap out half the textures with COpenGLTexture. It just plain wouldn't work, regardless of how it gets at the data inside.

 

Thats what I thought for a moment, too. The I decided not to post it because I thought it sounded a little too obvious and stupid to me. Seems I was wrong^^

 

 

It seems to me that the way to do that is to have the api specific engine implementation worry about storing api specific texture resources. CTexture stops storing a texture, and instead becomes a resource locator. It can expose functions which act on the texture, and internally it implements that by making a call to the engine, which can look up the texture and perform the actual modification.

 

Ah, that sounds like a brilliant idea! It goes a bit in the direction of what I was actually doing, as for one thing I was indeed storing my textures in a texture module class of my graphics engine. I would reference them by file or specifiy name, and have that module functionality to set a texture as render target, clear it, etc... . Now having those functions on the texture itself so I don't need to use the module for everything just sounds natural to me, too. Having the actual API specifiy texture stored in the texture module and CTexture just use this won't make a huge difference to implement. Then when passing the texture to e.g. the Effect, it would pull out the textures hash, and tell its own action handler to set the texture with that hash to the cBuffer... right? Sounds just like what I've been looking for, thanks!

 

Just a quick question about your code, too:

 

class CTexture : public ITextureAccessor, ITextureMutator

I assume those are the interfaces whose getter / respective setter the CTexture class in your example implements, right?

 

 

Oh, another big question concerning the whole interface thing. I assume you have willingly not made CTexture another interface, right? I don't know how to put that in a question that won't make me sound like I have no idea what I'm talking about, but... well, since that train has left the station: Until now I've always conducted tests of my code by clicking, using etc... every feature I added. Since I've read about test driven developement and belive it to be very useful and making bug tracking way more easy for me, I want to give it a shot in the near feature. Now, I don't want to post a question to a different topic here, but I've heard that TDD is somewhat hard to conduct in its full feashion in c++, and that using interface whereever possible it one of the main requirements (or to make things easier). Is this true? Unfortunately I didn't find that much info on that topic on google, but since I'm at the whole interface thing, I might ask here as well.


#1Juliean

Posted 07 April 2013 - 06:49 AM

In any case, you'd kind of expect liskov to be violated anyway. You really can't expect a D3DEngine to work happily if you swap out half the textures with COpenGLTexture. It just plain wouldn't work, regardless of how it gets at the data inside.

 

Thats what I thought for a moment, too. The I decided not to post it because I thought it sounded a little too obvious and stupid to me. Seems I was wrong^^

 

It seems to me that the way to do that is to have the api specific engine implementation worry about storing api specific texture resources. CTexture stops storing a texture, and instead becomes a resource locator. It can expose functions which act on the texture, and internally it implements that by making a call to the engine, which can look up the texture and perform the actual modification.

 

Ah, that sounds like a brilliant idea! It goes a bit in the direction of what I was actually doing, as for one thing I was indeed storing my textures in a texture module class of my graphics engine. I would reference them by file or specifiy name, and have that module functionality to set a texture as render target, clear it, etc... . Now having those functions on the texture itself so I don't need to use the module for everything just sounds natural to me, too. Having the actual API specifiy texture stored in the texture module and CTexture just use this won't make a huge difference to implement. Then when passing the texture to e.g. the Effect, it would pull out the textures hash, and tell its own action handler to set the texture with that hash to the cBuffer... right? Sounds just like what I've been looking for, thanks!

 

Just a quick question about your code, too:

 

class CTexture : public ITextureAccessor, ITextureMutator

I assume those are the interfaces whose getter / respective setter the CTexture class in your example implements, right?


PARTNERS