Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 05 Jan 2002
Offline Last Active Apr 23 2015 10:21 AM

Posts I've Made

In Topic: Indie game developers getting screwed by PAX?

15 September 2014 - 12:17 PM

...Article is now on GDNet?



In Topic: Where is Greg Costikyan?

03 September 2014 - 12:23 PM

He's posting about cycling on Facebook;  yup.

In Topic: Anybody left from the 2003 crowd?

21 October 2013 - 08:47 AM

Did somebody say 2003 crowd!?

In Topic: questions about singletons

29 August 2013 - 09:07 PM

LPD3DXTEXTURE tex[maxtextures];




i should have something like:






or better yet:



although internally, set texture is a d3d device pointer method, perhaps leading to (the possibly over-engineered - over abstracted):

D3Ddevice.settex(texID)   and the "database" of textures is  part of the D3Ddevice object, 'cause that's the object that actually uses the data. 


over-engineered, or did i just have an insight? <g>



Certainly if you desire to have an object that holds textures; it might be:


texDB->addTexture(id, pTexture);


then later




these two methods form an interface, with that interface I as another developer can replace your implementation with another that functions different internally; without upsetting any other code.



As for:




i would assume that is a static method off of a class;


instead you should have an instance of a D3DDevice


D3DDevice* device=new D3DDevice(/*params require for instantiation*/);



In Topic: questions about singletons

29 August 2013 - 12:21 PM


Singleton as a "one and only one" instance enforcement


This is better handled with standard object construction / destruction; if there should only be one instance of an object in your program, instantiate only one.


If your code would break because more than one object has been instantiated that is a big problem that should be solved.



I mostly agree with what you've said, but in this case I'd point out that the only time I use a singleton is when I inherit this kind of problem from an external library. I actually had that problem crop up in class last semester, where a library we were using abstracted all resources and forced us to refer to everything by assigning it an integer handle. I created a singleton to function as a kind of handle distributor. It contained an internal int that started at 1 (the lowest allowed value for the int handles) and it had a method that would return that and increment it. If there were ever two instances of this class then all of my resources would potentially be invalidated because their handles could suddenly be used to load a new resource. My whole motivation in creating the singleton was to enforce one-and-only-one instance.



That is a poorly designed library, or your understanding of the API might be incomplete.


Such libraries exist where they are just calls to 'getNextResource', virtualizing this across multiple objects can be tricky.


The simplest case of this is C or C++ 'rand()' function, it uses an internal PRN sequence


While not ideal, you could manage this using srand() to set the seed to the known instanced value before a call to the global rand()


Some libraries provide similar functionality, specifying a 'context' or 'device' id for the global functions, which partitions sets of identical resource id's.


If the library had such a feature you could have your 'Singleton' instance, hold and use the device id.


If the library did not support such a thing, time to go bitch them out, they're writing broken code.



Thanks for posting this example, as it is another common reason people turn to singletons, to help shield against code like this.