Hi, i’m developing an android version of this one:
link
I’m using the half amount of particles to get it run smoothly.
If i use more than 100 particles per explosion the fps-rate drops under 20 or will lag and skip the explosion.
The src is nearly the same to mine and you can download and watch it your self.
How can i improve that behaviour?
kind regards
sytrox
Well I think they are target the tutorial at (lower end)Desktop computers, so you have to adjust/fake some effects to archive the same performance on android.
Contrary to what most smartphone producers let you guess their performance is still somewhat terrible. I would try with larger and fewer particles or some kind of fake effect. Eg instead of particle effect on the explosion use a sprite animation with a pregenerated one. (or a combi of both reducing the real particles to very few but keeping the look mostly the same)
I’ve never looked at that tutorial in detail… but if they aren’t batching the particles then that’s another place for improvement. If every particle is a separate object then that’s going to be pretty bad for performance.
If you enable the stats display, what does the object count look like?
Hi, i already thought about prerendered explosions, but these particels are pretty nice if they reflect on the borders.
btw: can i record the screen and safe it to a gif and play this gif with jme?
I have about 200 particels moving around with 20 fps on an S3.
The CPU on this device does’nt seem to be very busy, just one core is used and the device does’nt get warm like on other HD games.
kind regards
sytrox
@sytrox said: I have about 200 particels moving around with 20 fps on an S3.
But I don’t know enough about the tutorial to know if those are 200 separate objects or if they are already doing batched particles. If the stats display is enabled then you can see how many objects are being drawn.
If the particles were batched then they would show up as only one object in the stats display (so 1 plus whatever else is going on).
Each particle is a single object.
If i have about 200 of these Objects the fps-rate goes below the magic 25fps
I duplicated the particles in the meantime by editing the image, so i got two particles in one object.
kind regards
sytrox
That’s way too many. You should use a max of 50 objects. Like others have said, look at batching.
With 91 simple quads I get about 15FPS.
@sytrox said: Hi, i already thought about prerendered explosions, but these particels are pretty nice if they reflect on the borders. btw: can i record the screen and safe it to a gif and play this gif with jme? I have about 200 particels moving around with 20 fps on an S3. The CPU on this device does'nt seem to be very busy, just one core is used and the device does'nt get warm like on other HD games.kind regards
sytrox
You most likely want to use a spritesheet, the particle material can use this as well. you basically only have one large particle then that loops the textures via shader.
Just a note about the explosions.
You can likely produce the exact same effect with about 3-4 particles (1 if you don’t care about variation)
The particle texture would be all particles moving outward from center… scale the particle from 0 to 4 or something…
Set the initial force to something close to 0.
For variation, add a couple particles with different z rotations.
Just make sure the particles are camera aligned
So, actually, you could use point-base particles and it would run without effecting your framerate at all.
EDIT: Since it only require a few particles, you may be better served using 2-4 quads? And skipping the use of an emitter.
EDIT 2: Are you currently using point-base particles? Triangle (or quad) based make no sense in a 2D game (unless you’re using particle stretching… which I don’t think you can do right now anyways).
@t0neg0d said: Just a note about the explosions.You can likely produce the exact same effect with about 3-4 particles (1 if you don’t care about variation)
The particle texture would be all particles moving outward from center… scale the particle from 0 to 4 or something…
Set the initial force to something close to 0.
For variation, add a couple particles with different z rotations.
Just make sure the particles are camera aligned
So, actually, you could use point-base particles and it would run without effecting your framerate at all.
EDIT: Since it only require a few particles, you may be better served using 2-4 quads? And skipping the use of an emitter.
EDIT 2: Are you currently using point-base particles? Triangle (or quad) based make no sense in a 2D game (unless you’re using particle stretching… which I don’t think you can do right now anyways).
I’m completly new in game-dev, i decided to try jme3 and found this tutorial.
I have no clue what a point-based particle is, i googled it, but found nothing.
What do you mean with using quads? I found this wiki-entry link should i use quads instead of pictures?
how can i user just 1-4 particles for the same effect?
kind regards
sytrox
@sytrox said: I'm completly new in game-dev, i decided to try jme3 and found this tutorial. I have no clue what a point-based particle is, i googled it, but found nothing. What do you mean with using quads? I found this wiki-entry link should i use quads instead of pictures? how can i user just 1-4 particles for the same effect?kind regards
sytrox
The JME Emitter allows you to select ParticlePointMesh as the type of particle. This tells the emitter to let the GPU render the particles by just passing it the location and size. Otherwise, the vertices making up each particle are calculated on the CPU and the buffers are pushed to the GPU each frame (Slower then the first option, especially on Android)
So… using crappy ASCII art, I’ll try and demonstrate what the texture would look like:
\ | /
This is all of the little sparks flying out in different directions. Now, stead of having the emitter create each spark and push it out along a random velocity, have it create one particle using a texture like the crappy example above with minimal force (so it doesn’t move from the point of emission) and then scale the size of the particle over time, making it look like the particles are moving outward.
To make it look random, have the emitter emit between 2 and 4 of these at once at different initial rotations and scale them all.
It will appear REALLY close to the original effect and not impact your frame rate at all.
Perhaps it was what led you here, but have you read “Make a Neon Vector Shooter for iOS”? It’s basically an extension of the original XNA/jMonkeyEngine tutorial, but in C++. Might give you some pointers.
Hi, i spend a lot of time today improving my code with no mentionable results -_-.
I have used the BatchNode and added the sparks to it. But i cant see any improvements.
On the contrary, sometime the explosion “freezes” and the sparkles stay in their position on the screen until the next explosion, even though the BatchNode isn’nt added to the scene anymore.
I also experimented a little bit with the ParticleEmitter until @erlend_sh posted the link to the equivalent ios tutorial.
How is it possible that alls sparks are “object based”? c++?
@sytrox said: Hi, i spend a lot of time today improving my code with no mentionable results -_-.I have used the BatchNode and added the sparks to it. But i cant see any improvements.
On the contrary, sometime the explosion “freezes” and the sparkles stay in their position on the screen until the next explosion, even though the BatchNode isn’nt added to the scene anymore.
I also experimented a little bit with the ParticleEmitter until @erlend_sh posted the link to the equivalent ios tutorial.
How is it possible that alls sparks are “object based”? c++?
BatchNode is definitely not a good idea. This will likely be worse performance than the emitter only due to the context you are trying to use it.
@t0neg0d said: BatchNode is definitely not a good idea. This will likely be worse performance than the emitter only due to the context you are trying to use it.
He’s not using an emitter (at least not in the original case) but 500 separate particle objects. A BatchNode used properly would be a big improvement over that if done properly.
A particle emitter will be marginally better.
…the big thing is to stop using separate Spatials per particle however that’s done.