Jump to content

  • Log In with Google      Sign In   
  • Create Account


Is this a case for smart pointer usage or is my design wrong,help needed.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 ankhd   Members   -  Reputation: 1243

Like
0Likes
Like

Posted 12 October 2012 - 04:50 AM

Hello there.
What I have so far is a class that holds a vector<Psystem*> of all the different particle systems that can be used.
It also has a vector<cActiveParticleData> when a Unit fires it's weapon it can add to this list.(Renders and processed list)
This is where my problem is.

Should I give the unit a index to the element in vector<cActiveParticleData> and let the unit update this data(no smart ptr needed in this case).
but the particle may end and then the particle system will remove it from the list needs to tell the unit about it.???

or
should cActiveParticleData have a smart pointer to the unit and let the particle manager use this pointer to get the
position data for the emitter.(unit may die before it gets here but)

Or
none of the above;
I'm asking because I have not yet used any smart pointers.
maybe I'm just making a excuse to use them lol.
I looked into
std::shared_ptr

weak_ptr


here,



Sponsor:

#2 NightCreature83   Crossbones+   -  Reputation: 2762

Like
0Likes
Like

Posted 12 October 2012 - 05:28 AM

Shouldn't the system itself have a world position, that it can update?
Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#3 slicksk8te   Members   -  Reputation: 191

Like
0Likes
Like

Posted 12 October 2012 - 10:57 AM

I would expect that particles are completely self contained. That is once they are spawned they would not need to reference the Unit again in its lifetime. For instance if the unit fired, it would spawn a particle in the particle system with its position and the particle system would manage it completely after it was initially spawned.

Why does the particle need a reference to the Unit again? What kind of data do you need from the Unit?

#4 ankhd   Members   -  Reputation: 1243

Like
0Likes
Like

Posted 12 October 2012 - 05:29 PM

The unit can walk and shoot, rockets move through the air. Can't keep adding a new particle each time a unit move. The emitter needs to move with the unit dies it not.

#5 sednihp   Members   -  Reputation: 241

Like
-1Likes
Like

Posted 12 October 2012 - 05:39 PM

Don't create a particle every time it moves, no, but you could create one randomly on movement. The particle then controls it's own movement and animates itself (if so called for) until it's lifetime expires, at which time it is destroyed. All of this management should be done in the particle manager class, with a check done to see if a particle is still alive and needs to be removed in the game's code, i.e.

[source lang="cpp"]for(auto particle : particles){ if( particle.isDead() ) //erase particle code here else particle.update();}[/source]

Edited by sednihp, 12 October 2012 - 05:40 PM.


#6 slicksk8te   Members   -  Reputation: 191

Like
0Likes
Like

Posted 13 October 2012 - 01:02 AM

Sednihp is right you should not have the unit controlling the particle but the particle system. Once it is spawned the particle should not need the the emitter at all. This is the best way to implement it and how professional particle systems work.

#7 ankhd   Members   -  Reputation: 1243

Like
0Likes
Like

Posted 13 October 2012 - 03:58 AM

what Im talking about is say the unit is moving and shooting the emitter will need to follow the units weapons position.


the particle system will control all of the particles from its current emitters wold pos, but this world position will need to change
may be not so for a muzzle flash because the muzzle flash is quick just a flash, But for say a rocket its life time is when the
rocket hits something, so dueing this time the emitter will need to move hey
/
- --
\

#8 sednihp   Members   -  Reputation: 241

Like
0Likes
Like

Posted 13 October 2012 - 07:57 AM

The rocket doesn't need to know about it's particles, that code goes in the Game/Level update function. A very simplified example:
[source lang="cpp"]void update(){ rocket.move(); if(rand() % 5 < 1) //create a particle on 20% of the frames particles.push_back(new Particle( rocket.getX(), rocket.getY() ) ); //or if you want smart pointers instead: particles.push_back(std::make_shared< Particle >(rocket.getX(), rocket.getY())); for(auto particle : particles) { if( particle.isDead() ) //erase particle code here else particle.update(); }}[/source]

Edited by sednihp, 13 October 2012 - 07:58 AM.


#9 ankhd   Members   -  Reputation: 1243

Like
0Likes
Like

Posted 13 October 2012 - 09:46 PM

Sednihp thankts for the reply. But I don't think your getting what I'm saying.

if I fire the rocket 5 frames ago then going by the code above, the current position of the rocket would be half way across the map
but the emitter would still be at the starting point because the particle system does not control where the emitter is (The Emitter Is a point in 3d that the particles launch from, they have direction and stuf but thats not what where here for).

I cant just send a new request for a new rocket flame particle system because it would be at its starting of its particle motion like animation each time.

I'm thinking is I use a weak_ptr in the particle manager to hold a object pointer then this would be invalid when a object remove it self and then the
particle system can detect if the object dies and remove its self from the active list of particle systems ready to be used again.
Is that how smart pointers work.

No, looked into doing the above just then and now I'm going to link then old school style by a Index to the particleSystem the object is using
and a object pointer in the particle system to the current bound object to this particle system, It will be valid all times until the object die then
the object will use its index and remove its self from the particle manager, like wise if the particle system has finnished its animation it can use the
objects pointer to tell it to remove its self from the particle manager.

#10 ankhd   Members   -  Reputation: 1243

Like
0Likes
Like

Posted 18 October 2012 - 03:06 AM

I've linked the unit to the particle manager and also linked particle manager to the unit, I have not yet tested it, because when I ran it the first time
I could not see my particles 2 hours later I find they are small so now got it working but not tested yet.

here a picture of the particle system on the terrain and unit

Posted Image.

#11 BeerNutts   Crossbones+   -  Reputation: 2860

Like
0Likes
Like

Posted 18 October 2012 - 08:41 AM

ankd,

What sednihp said is correct for your typical particle systems. "Particles" are typically just residue left from an emitter. Once a particle has been created, it doesn't matter where the emitter is. Think about a car with bad exhaust. When the smoke (ie, the particle) leaves the car, it just starts floating up. It doesn't care if the car has turned left, it's doing it's own thing once separate from the car (ie, the emitter).

In simple games, a particle could just be a small block of red/yellow/orange that is created by a rocket, and fades away a short time after to look like some kind of fire (when combined with many particles). These particles don't care where the emitter is once they have been created.

It sounds like you are trying to define something else, not the typical particle emitter.
My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

#12 ankhd   Members   -  Reputation: 1243

Like
0Likes
Like

Posted 19 October 2012 - 02:37 AM

ok this is the last time i'm going to say this. This is not about the particles its about linking the emitter to my objects.

My particle systems are define to do a certain task, Eg. Muzzel flash it luanches 50 particles that come from the emitter at some direction.
This emitter can be moved around but that only changes any new particle that is launched, at its new world position.

Now ParticleManager managers a bunch of particle systems that do there own thing and each one has a world position emitter that I would like
to set at runtime, like when a unit walks. ParticleManager also adds request from objects when a object need to activate a particle system.
It's at this stage, I would like to link objects that are bound to the particle manager and what one it is using, and like wise with the objects.
So what I have done todate is in the particle manager when a unit adds a request I also store a pointer to the object and the add function
returns back to the unit data containing where and what elements its in.

Now when a unit dies or no longer needs its particle system it will message particlemanager to do so.
all good so for but none of my objects have death built into them yet and Im also in the process of making the rest of the particles,
I'll get back as soon as I can with the test results.

#13 BeerNutts   Crossbones+   -  Reputation: 2860

Like
0Likes
Like

Posted 19 October 2012 - 07:46 AM

Oops, my bad. I did misunderstand.

So, my initial thought is there may be a design flaw with using a "particle manager" to control the emitters. I would have the emitter itself (which is given to rocket) handle how it renders and processes the particles. As for when it needs to be removed, it could come from the rocket (or whatever object is using the particle system), and that object removes the particle system (emitter).

The specific emitter can be copied from your vector of the possible systems, but you're getting into trouble having to share it across multiple objects.

There are a number of posts throughout discussing the pitfalls of using "managers" You can search through and find them.
My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS