I am calling setTexture:withRect: on a particle emitter... My question is, is there any way I can give multiple rects so that the particles can be comprised of random sprites? Or is the only way to accomplish this to use multiple emitters?
I thought if there was a way to actually get the collection of particles that are being generated, then I could loop over them and set their rect, or even color properties, but in the cocos2d docs, I see no way to get individual particle objects...... Is there any way to do this?
If you want emitted particles to have different images, you can make sprite sheet of your particle images and subclass CCParticleSystemQuad overriding initTexCoordsWithRect: method so that instead of using same frame for very particle it uses different frames for different particles.
See here for example of such particle system using bitmap font. Using the same idea, I made CCParticleSystemQuad subclass which uses CCSpriteFrameCache to get frame information.
No, you can't access or modify individual particles.
If you want random sprites, simply run multiple particle systems with each using a different texture.
Related
I developed a game with SDL2.00 and c++. I seemed to be having memory and CPU issues. CPU usage goes up to 40% and memory usage goes up by 5mg a second.
So I think the reason is the way Im handling Textures\Sprites.
My question is should I create a different/new sprite/texture for every instance ?
For example, I have a class called Enemy which contains all the variable and methods related to enemy monsters such as HP, damage, location , image(Texture) etc. This class contains its own texture to be rendered onto the renderer.
Is this the right way? Or should I create a Sprite/Texture for all the images before hand and render them as needed?
and I'm wondering if this will render two different images onto the renderer:
RenderCopy(renderer, image);
image->SetPosition(X,Y);
RenderCopy(renderer,image);
or is it going to move the sprite to the new position?
I think my issues are caused my overloading the renderer and/or having too many textures being loaded.
Let me know what you think .
OpenGL is not a scene graph. It's a drawing API. So everytime you're allocating a new texture you're creating a new data object that consumes memory. You should reuse and share resources where possible.
My question is should I create a different/new sprite/texture for
every instance ?
No, not unless every instance of the sprite uses different textures, otherwise you should reuse them, ie only load them once and store a pointer to the texture the sprite uses.
and I'm wondering if this will render two different images onto the
renderer:
RenderCopy(renderer, image);
image->SetPosition(X,Y);
RenderCopy(renderer,image);
or is it going to move the sprite to the new position?
This will copy the image twice. First at the old position and then at the new. What you will get is a trailing image. You should probably either clear the previous position or render the background at that position (or whatever should be there).
What is the best approach to display a same image multiple times e.g. 1000-2000 times? The image has to be rendered in discrete sizes across the screen. The most straight forward idea seems to be declaring different sprites for each image, but there should be a better approach?
That would be a lot ! I would create a batch node with the texture, and add to the batch node 999-1999 additional CCSprites that would be scaled and positioned where you want them. Then add the batch node to the scene and position it.
Then i would test that on the slowest-most-memory-limited device you intend to support with your app. I've gone up to 500 or so replicas like this (remember, only one draw call with a batch node). I dont have a good 'feel' for your use case. In my case, the texture is small.
I'm using cocos2d-x and want to create a dynamic shape as part of my user interface. I need a circle with an adjustable section removed. I attempted this using the draw method but item would be drawn every frame which required too much processing power. What would be an efficient way to achieve this without drawing the shape every frame? Is it possible to clip a circle sprite to remove a section?
The mathematics behind the implementation is ok, I'm just looking for a high level explanation about how I should approach this.
you can have a try on CCTransitionProgressRadialCW. This class contains something similar to what you want.
Turns out theres a class specifically designed for this, CCProgressTimer.
My idea would be to draw several Graphics objects on memory and combine them when drawing the image.
But I haven't got a precise idea of how to do that. Shall I use GraphicsContainer's? Or save the objects as Metafile's? (these are temporary objects, I would like to keep them on memory)
Simplest method: create multiple bitmaps. Draw what you want to them. Composite them by drawing them back to front.
If you have a lot of text, then using a metafile for those layer(s) may improve the rendering quality somewhat.
I guess I'll illustrate with an example:
In this game you are able to draw 2D shapes using the mouse and what you draw is rendered to the screen in real-time. I want to know what the best ways are to render this type of drawing using hardware acceleration (OpenGL). I had two ideas:
Create a screen-size texture when drawing is started, update this when drawing, and blit this to the screen
Create a series of line segments to represent the drawing, and render these using either lines or thin polygons
Are there any other ideas? Which of these methods is likely to be best/most efficient/easiest? Any suggestions are welcome.
I love crayon physics (music gets me every time). Great game!
But back to the point... He has created brush sprites that follow your mouse position. He's created a few brushes that account for a little variation. Once the mouse goes down, I imagine he is adding these sprites to a data structure and sending that structure through his drawing and collision functions to loop through. Thus popping out the real-time effect. He is using Simple DirectMedia Layer library, which I give two thumbs up.
I'm pretty sure the second idea is the way to go.
First option if the player draws pure freehand (rather than lines), and what they draw doesn't need to be animated.
Second option if it is animated or is primarily lines. If you do choose this, it seems like you'd need to draw thin polygons rather than regular lines to get any kind of interesting look (as in the crayon example).