Is there a way I can tell an emitter to stop spawning particles and then later tell it to start spawning them again ?
I am currently using an emitter as a way of telling the user where their 3D Pointing device is pointed at on the screen. I want it to stop emitting particles when they aren't pointing at the screen.
You can use the resetSystem method (kills all particles) or stopSystem (stops emitting but all existing particles will live until they die).
I believe stopSystem is the method for your purpose as living particles should continue to run but the emitter will not be creating any new particles.
Since it is an open source you can manipulate the active property to be used in the CCParticleSystemQuad class logic parts (currently it is readonly but you can easily change that fact and update the emitter class logic accordingly)
Related
I'm developing a 2d fighting game in c++ (for learning purposes) and I'm having a hard time figuring out how to properly implement game logic. For a quick overview of my current architecture, I have component classes that act as data holders and I have 'systems' which are just functions designed to act on those components. I have a scene class which holds an array of fighters that are currently in game and this scene is passed to individual sub-systems which then can freely act on fighter components, updating fighters state:
//Add a fighter object to array of fighters and set starting position
scene.CreatePlayerFighter(160.0f, 0.0f);
scene.CreateAIFighter(80.0f, 45.0f);
gameWolrd.Init(scene);
Renderer.Init(scene, window);
AI.Init(scene);
//etc...
//Game loop
while (true)
{
Input.Update(scene);
Physics.Update(scene);
AI.Update(scene);
//etc....
window.ClearBuffers();
Renderer.Update(scene, colorShaderProgram);
window.SwapBuffers();
}
Again, inside each sub-system (Renderer, AI, Input, etc.) all fighter components are being passed into system functions and spit back out with new values which are then inserted back into fighters:
void Physics::Update(Scene& scene)
{
for (Fighter& fighter : scene.fighters)
{
//Update fighter position based on fighter's current velocity which has been set by input
TransformComponent newFighterPosition = System::MoveFighter(fighter.GetComponent<TransformComponent>(), fighter.GetComponent<VelocityComponent>());
//Insert new TransformComponent to update fighter's position
fighter.Insert<TransformComponent>(newFighterPosition);
}
}
This current architecture has the advantage of being loosley coupled in that I can add and remove systems very easily without effecting the fighter class or it's components directly. The problem is everything is hopelessly serial, as my scene is passed into each sub-system one by one to update fighters. I mention this problem because one of my thoughts to implement a game logic layer was to have higher level classes just call specific game engine system functions directly like physics.MoveFighter(TransformComponent, VelocityComponent, float amountToMove); where I can add additional parameters to give the user at the game logic layer level more control. Of course doing things this way means system functions would be called and invoked in any order the user of the game logic saw fit. Would there be a way to still implement a game logic layer in this way and maybe queue up all calls and reorder them to run correctly within the game engine? Or would there be a better way to try and implement game logic within my current architecture?
As I see your goal, you could just store movementFactor field in fighter, and allow to change it from game logic layer. In Physics class delta is then mul-ied by that field. If you use component like system you probably do not want to update components manually, only operate with data.
Logic update order is a complex problem: imagine a chicken falling on an egg. It happens that in the same frame chicken touches the egg and egg is ready to show us new little chick. What should be executed first? That depends on what is updated first: physics or eggs, and on the fact whether reactions apply immediately. The best scenario (most fair usually) would be for them not to apply immediately, but form a stack of objects (components) state changes, for them to be resolved independently after the action phase.
Also make sure you do not want to stick with existing entity system like entityx.
I am coding a game with cocos2d-x in c++.
In my game scene i will place some instances of my class CircleSprite (Which is an extension of Layer where i create multiple items and set them like child of CircleSprite.
In my scene the user should touch one circle and connect it to another one by moving the finger until another circle is reached. While doing this a line (sprite or draw it dosen't matter) should appear and follow the finger until reach the choosen circle.
I'm new with cocos2d programming and i'm not a c++ expert...i don't know how to manage the events.
Check this official tutorial
http://www.cocos2d-x.org/wiki/User_Tutorials-Dragging_a_Sprite_Around_the_Screen
Also check the version of cocos2dx for which this tutorial was written. If yours is a lower version then v2.3, then you just need to override onTouchesBegin and onTouchesEnded onTouchesMoved functions of the layer, the are already registered with the touch events.
Thanx in advance..I have a problem , how we release memory in cocos2dx ??
In my game, my first scene takes a lot of memory because there are so many animations run at a single time on this scene,there are so many animations , so i am satisfied with this but when we go to next scene, it does not release previous memory used,this is my problem so how we release memory used by previous scene when we change the scene?
To go between scenes you can either call pushScene or replaceScene.
Push Scene
If you're pushing between scenes then I recommend that you have a loading scene in between. It should be lightweight so that you have a chance to release everything from your old scene. This is where the onEnter(DidFinish) and onExit(DidStart) methods come in handy.
The chain of calls would be:
oldScene->onExitDidStart()
loadScene->onEnter()
oldScene->onExit() <-- this is where you release everything
loadScene->onEnterDidFinish() <-- this is where you load up the new scene
newScene->onEnter()
and so on... If you've managed your memory correctly then you shouldn't have 2 heavy scenes at once.
Replace Scene
This is a much easier scenario. You simply need to make sure that for the new scene you load as little as possible until the old scene has completely disappeared. I.e. when onEnterDidFinish() is called, or even 1 frame after it.
Cocos2d-x supports auto release memory. For example, when you create a sprite by calling Sprite::create() it will add this sprite to the auto-release pool. If you don't add this sprite to become the child (or n-th leveled child) of the current scene, it will be released.
Do not create an object using new,use create() instead when you call the next scene, everything from the last scene are released.
I am doing a simulation using MFC application (its a robot moving in a field) what happens is that the process behind calculates the position to quick where as drawing takes time so what I see ultimately is the robot at the end position no intermediate positions . But when I put AFXMessageBox then I can see all the position its been going through , Can you help me figure this out
Hina, What you need to do is move the complex calculation that calculates the position of the robot to a thread and keep the drawing of robot in your main thread. Then you need to communicate your current positions to the main thread and after the drawing invalidate your surface. This way you can see the positions updated frequently.
What happens when you display a message box is you are able to repaint the surface after the calculation.
You can fasten the drawing my using memory device context. In a nutshell you would do all the drawing on a bitmap in memory which will be fast. When it is all ready, you will print the final drawing on your display. This will be very fast and smooth.
I'm using a particles, slightly modified CCParticleFlower with positionVar to be in form of vertical line, from top to bottom. In CCNode update I constantly change the position of the particles from left to right across the whole screen, when it reaches the right side I set x to 0 and start scrolling to the right.
The problem is when I reset the X value to 0, all particles blinks, they disappear for about one frame and appear in the next frame, it causes a nasty flickering effect.
It does not happen when I increment X values by small numbers but when the particle position is reset to its beginning position it flickers, on win32, android and ios. I’m using most recent 1.1 version (master branch)
I recently had something of a similar problem where the particles would jump around whenever their parent changed direction. I'm not sure if it's exactly the same problem, but here's the thread I found that helped with my problem:
http://www.cocos2d-iphone.org/forum/topic/17167
The relevant post:
I just encountered the same problem and it took me a while to get to the bottom of it, >here's the low down: do not use
[self schedule:#selector(NextFrame:)];
Instead, use
[self scheduleUpdate];
and rename NextFrame: to update:
Using a custom selector schedules your update at the very end of the CCScheduler queue, in other words, it will cause your NextFrame: method to be called AFTER the particle system's update: method, because the particle system schedules its own update method with a priority of 1.
This is not good because the position of the quads for the particles are updated using the current position of the emitter, and then the emitter is moved in your NextFrame: method, which causes all the particles to be moved again because the position of the emitter is really the position of the CCNode that draws the particles.
By using scheduleUpdate, you really schedule your update: method with a priority of 0, which means it will be called before the particle system's update: method and all will be well.
So basically, add an update method to your class and call scheduleUpdate instead of manually scheduling it.