Class shared by other classes??
Author
Hey all fellow programmers. I'm of need of some help with class objects. I and some fellow classmates are working on an game project and I'm working on making a particle system for the game. So how does this relate to my question, Im making a class for the particle system and I want it to be shared with other classes that will use it. I'm looking for a way to make the particle system class shared by these classes that will use it and dont want to make more instances of it but one that will be shared by all the other. I hope that I'm explaining well to you all :/.. All help are welcome!!!
What language are you using? Static (or Shared! in vb) might be what you're looking for if all your class is is a place for particle functions to sit and you don't want to have to worry about passing around an object.
There are all kinds of reasons to not use Static classes if you don't know what you're doing with them (thread saftey being the biggie), but if you're single threaded it's not a big deal.
The other approach I like to use is to pass around a custom State object, that contains all of my engine's quasi-shared objects, where almost all of my functions take the state object as a parameter (reason they aren't actually shared is because my engine sits in a process that can run multiple engines)
Hope that helps (Looking up the static/shared keyword would be a good place to start)
There are all kinds of reasons to not use Static classes if you don't know what you're doing with them (thread saftey being the biggie), but if you're single threaded it's not a big deal.
The other approach I like to use is to pass around a custom State object, that contains all of my engine's quasi-shared objects, where almost all of my functions take the state object as a parameter (reason they aren't actually shared is because my engine sits in a process that can run multiple engines)
Hope that helps (Looking up the static/shared keyword would be a good place to start)
Use a global variable (there is no plausible justification for making it a singleton). But, first and foremost, rethink your design and discuss it with the other developers. A multi-developer design with global variables and programmers not knowing how to use another programmer's class is bound to fail in a very ugly fashion.
Ideally, depending on what the particle system does, it should be available internally to particles and to nobody else, or each particle user should create its own instance, possibly shared internally for performance reasons.
Ideally, depending on what the particle system does, it should be available internally to particles and to nobody else, or each particle user should create its own instance, possibly shared internally for performance reasons.
Author
GuinnessKMF - I'm using C++ language and were using single threaded.
ToohrVyk - I and my classmates are using our own code standard so we cant mix up class name, instance, members, defines and variables.
I'm gona try both ways and se if it will work out. There might be a trouble if I use a global variable, our lead coder rather we dont use it but I will try and convince him if it work :).
I'll post after I have try both ways....
ToohrVyk - I and my classmates are using our own code standard so we cant mix up class name, instance, members, defines and variables.
I'm gona try both ways and se if it will work out. There might be a trouble if I use a global variable, our lead coder rather we dont use it but I will try and convince him if it work :).
I'll post after I have try both ways....
Quote:Original post by Vulcanus
ToohrVyk - I and my classmates are using our own code standard so we cant mix up class name, instance, members, defines and variables.
This is not the real problem. If you mix up class names, instances, members, defines (what for?) and variables, the compiler would warn you about it anyway, so I would not worry about that.
The real problem is about the interaction between your work and the work of others. Ideally, you would work on a "as required" basis: developer A needs a class which does X, and tells the group what X is, and how the class should be used to do it. Developers B, C and D provide feedback based on their own needs for a class which does X, or which does an Y that is quite similar to X. Then, developer B implements that class and gives the class to all other developers. So, in this situation, people would know how to use the class before it was even written.
Better, developer A could and should have written an unit test demonstrating the usage of the class, so that developer B can know if the implementation is correct-ish or not without having developer A proofread the code.
Working the other way around—writing a class without anyone needing it yet, or without the users of the class deciding how it should be used—you run the risk of a class that is not adapted to its intended usage, or a class that people don't know how to use.
Author
Quote:Original post by ToohrVykQuote:Original post by Vulcanus
ToohrVyk - I and my classmates are using our own code standard so we cant mix up class name, instance, members, defines and variables.
This is not the real problem. If you mix up class names, instances, members, defines (what for?) and variables, the compiler would warn you about it anyway, so I would not worry about that.
The real problem is about the interaction between your work and the work of others. Ideally, you would work on a "as required" basis: developer A needs a class which does X, and tells the group what X is, and how the class should be used to do it. Developers B, C and D provide feedback based on their own needs for a class which does X, or which does an Y that is quite similar to X. Then, developer B implements that class and gives the class to all other developers. So, in this situation, people would know how to use the class before it was even written.
Better, developer A could and should have written an unit test demonstrating the usage of the class, so that developer B can know if the implementation is correct-ish or not without having developer A proofread the code.
Working the other way around—writing a class without anyone needing it yet, or without the users of the class deciding how it should be used—you run the risk of a class that is not adapted to its intended usage, or a class that people don't know how to use.
It sounds to me that you are trying to explaine the interaction of my classmates , just as we started on the project we hade meetings to divide the work and I got the particle system. At the end of the week we have a meeting to see out progress, feedback and to explain how it works. So all of my classmates know how it work . And I have commented in the code about all the function and variables what they are and do.
Does this help??
The main difference is that your classmates know how your class works, but they don't decide how it works. The typical result is that you find yourself asking how people would use it (and, as a consequence, you ask that same question on the forums), when the usage of the class should have been determined before you were sent out to develop it, not during or (heaven forbid) after development.
What I'm saying is, when your team decided that you should write the Particle System, they should have told you how, exactly, the system was going to be used. For instance (to reuse the example from my previous post), by providing you with an unit test:
So, the usage illustrated above is to create a particle type and a particle generator, and then spawn the particle using the generator. There is no "passing around" the system (either as arguments or as a global variable): people who wish to use one simply create their own instance of the system. This makes usage easier by removing your initial constraint that "only one instance should be created", because creating an object is a very abstract operation (since you don't know what the object does behind-the scenes) while accessing an existing object isn't (in particular, that forces you to use an existing object).
Internally, you may, for performance purposes, implement the particle system as a global variable (or set of global variables), so that ParticleSystem is only a proxy to a global system (which means creating it is cheap, and all particles are clustered together). However, the globality of the particle system is not visible from the outside (nobody knows, or needs to know, that the particle system is something global), and you may decide to implement it this way only later, if it proves necessary (if the performance is otherwise good, no need to add complexity by implementing a highly optimized performance system yet).
What I'm saying is, when your team decided that you should write the Particle System, they should have told you how, exactly, the system was going to be used. For instance (to reuse the example from my previous post), by providing you with an unit test:
#include "mockRenderer.hpp"#include "mockWorld.hpp"#include "test.hpp"START_TEST(particles);{ MockRenderer render; MockWorld world; /* USAGE EXAMPLE: this is how users of the particle system will manipulate it. This code would appear as-is (or almost) in actual game code, not only in the unit test. */ // One creates a new system for personal usage, tied to // a renderer (for graphics) and a world (for updates). // Each user creates its own system: using another // pre-existing instance (global or otherwise) is possible, // but neither useful nor recommended. Just create your own! ParticleGenerator system(render,world); // Particles are instanciated from types. A type describes // how the particle should look like, and when it dies, // possibly other properties (such as physics). ParticleType type( render.GetTexture("test"), // What it looks like seconds(3)); // Duration of life // Once a type is available, one can use the generator // to make a particle appear. The particle lives independently // of its creator (so destroying the creator does not // destroy the particle). system.Spawn( type, // The particle type vector(0,0,0), // Initial position vector(1,0,0)); // Speed per second /* TESTING: the following section verifies that the system, as set up above, corresponds to the requirements for its design. */ // The properties should be set correctly assert (type.Texture() == render.GetTexture("test")); assert (type.Life() == seconds(3)); assert (system.Graphics() == render); assert (system.World() == world); // When the renderer draws its contents, the particles in the // system should be drawn. render.Draw(); assert (renderer.QuadWasDrawn(renderer.GetTexture("test"), vector(0,0,0))); // When the world updates, so do the particles world.update(seconds(1)); render.Draw(); assert (renderer.QuadWasDrawn(renderer.GetTexture("test"), vector(1,0,0))); world.update(seconds(1)); render.Draw(); assert (renderer.QuadWasDrawn(renderer.GetTexture("test"), vector(2,0,0))); // The particle dies after its life runs out world.update(seconds(1)); render.Draw(); assert (renderer.NothingWasDrawn());}END_TEST(particles);So, the usage illustrated above is to create a particle type and a particle generator, and then spawn the particle using the generator. There is no "passing around" the system (either as arguments or as a global variable): people who wish to use one simply create their own instance of the system. This makes usage easier by removing your initial constraint that "only one instance should be created", because creating an object is a very abstract operation (since you don't know what the object does behind-the scenes) while accessing an existing object isn't (in particular, that forces you to use an existing object).
Internally, you may, for performance purposes, implement the particle system as a global variable (or set of global variables), so that ParticleSystem is only a proxy to a global system (which means creating it is cheap, and all particles are clustered together). However, the globality of the particle system is not visible from the outside (nobody knows, or needs to know, that the particle system is something global), and you may decide to implement it this way only later, if it proves necessary (if the performance is otherwise good, no need to add complexity by implementing a highly optimized performance system yet).
Author
Quote:Original post by ToohrVyk
The main difference is that your classmates know how your class works, but they don't decide how it works. The typical result is that you find yourself asking how people would use it (and, as a consequence, you ask that same question on the forums), when the usage of the class should have been determined before you were sent out to develop it, not during or (heaven forbid) after development.
What I'm saying is, when your team decided that you should write the Particle System, they should have told you how, exactly, the system was going to be used. For instance (to reuse the example from my previous post), by providing you with an unit test:
*** Source Snippet Removed ***
So, the usage illustrated above is to create a particle type and a particle generator, and then spawn the particle using the generator. There is no "passing around" the system (either as arguments or as a global variable): people who wish to use one simply create their own instance of the system. This makes usage easier by removing your initial constraint that "only one instance should be created", because creating an object is a very abstract operation (since you don't know what the object does behind-the scenes) while accessing an existing object isn't (in particular, that forces you to use an existing object).
Internally, you may, for performance purposes, implement the particle system as a global variable (or set of global variables), so that ParticleSystem is only a proxy to a global system (which means creating it is cheap, and all particles are clustered together). However, the globality of the particle system is not visible from the outside (nobody knows, or needs to know, that the particle system is something global), and you may decide to implement it this way only later, if it proves necessary (if the performance is otherwise good, no need to add complexity by implementing a highly optimized performance system yet).
Maybe I sould have mention that I already have created a particle system outside of our project that work but it is when I need to code it in to the game. Our game is rather large, in code not in size :).
Well since the particle system is in it's own class i need to make sure that every time that I make a instance of the class the variables values and my pointers aren't back to NULL, in other word I want the particle class to be shared by the other classes that will use it.
I wont be able to post until sunday, I will try to work and see if I can solve it until then. Thx for the help this far, kiss kiss XD
Not sure why this ended up in the DirectX forum, but I'll push it over to 'General Programming' which is probably more suitable [wink]
Cheers,
Jack
Cheers,
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
