Vector system (2D vs 3D)
After another realization of how primitive my particle system was (it was build with 3D particles in a 2D system, thank you time for making me forget there was a difference between the two), I took out all the 2D vectors and replaced them with 3D vectors. Now it can truely move around, as opposed to just a 2D plane.
G-Data problems
But even then, moving the phone around did nothing despite the gravatometer (tilt + accelerometer) showing that it was getting values. Turns out that although they were being send to the class, it's sub-class was getting the value and not telling it's parent about the value (due to me using "@Override" and forgetting about the "super(base)"). This was patched up and values were flowing through the system again.
First Images
Meanwhile, this is all stepping through the debugging mode, I still haven't seen anything of the particles...due to there not being anything to show yet. But, after making the basic particle (4 points, color, billboard = true, add to the world), they came without a problem....well, short of the problem where the particles are so close to the screen that only 1 is visible at a time. This was solved by re-telling the particles to be at z = 20 instead of the default z = 0 (my fault for forgetting it).At this point, I wish I took a screenshot to show what was happening, but I forgot. The screen which was now visible, the FIRST image of the particle system.....was 100 dots randomly flickering on the screen. Not moving, just flickering. Seems that they were moving so fast, they were only visible once and then too far away from the viewing port. So I adjusted the velocity values before using them (divided them all by 1000), and now something was working.
They were no longer flying away...but now wimpering around. Yes, wimpering....not floating towards gravity, just gittering around the emitter location. Which, by the way, was working. Looked pretty nice with a particle sprinkle effect which follows your finger (another screenshot which I failed to take).
This, wimpering, was caused by normalizing the gravity values as soon as they were received...which by the way, Android has record of the gravity value for the Death Star (the same one from Star Wars). Thank you funny Android developers :-). So, I took out my code of normalizing the data, and particles were now flowing
 |
| First particle system (making a stream) |
May not seem like much, but this is a fully working particle system producing a stream of particles. The emitter is in the middle where the light blue squares are and falling away away (up right).
There was a slight problem where the x axis was reveresed, but this was resolved by a simple "change + to a -".
 |
| 4 Streams, moving into space |
Besides the system running at 14 fps (more on this later), this was great. Particles spawned, moved, and each had their own color
 | |
| 4 streams, moving towards the user |
Then, the much anticipated view....particles falling towards the user.As expected, the particles got bigger the closer they got. Although not as drastic or amazing as I hoped for, this still showed that they are working
Note: please do not change the streams to yellow when the game is further in development.
Speed problems
As mentioned earlier in this post, 4 streams were causing the game to run at 14 fps. For a game which is supposed to handle up to 8 on a phone (12 for a tablet) and currently there is only 100 particles per emitter....this was really shitty performance.
When compared to the particle system Rajawali has, his absolutely kicks my system's ass. But, I know why. My system has 100 objects per emitter with 2 triangles per object (to make a square). His system has 2000 planes (4,000 triangles)....in 1 object.
The way the graphics system works is that it likes to do as many things at once. Having to open a memory channel (to pull data) and then close the channel (so another can be opened) takes time (about 1/2 ms?). Sure, it's not that long for a few objects, but when there is many objects all needing seperate memory channels being opened, this adds up.
So, what I am going to be doing after this post is, instead of having 100 objects, there will be 10 objects with 10 particles each (20 triangles per object)....or 1 object with 100 particles (which would help when there is more than 100 total particles per emitter).
But, copying his system isn't so easy. In the mentioned page, the system accesses the GL buffers while mine (jPCT-AE) takes care of the GL access behind the scenes....So I need to find how to access the data using some built in function. Which, after a bit of looking, seems that the Polygon Manager would do the trick. No research has been done besides "does this interact with the vectors?", but so far, it seems to say yes and that this is the function I'm looking for.
Future plans
- research how to use the Polygon Manager
- add more eye candy to the particles
- start researching how to add a tabbed menu system for the settings
Nearly forgot; Custom Squares
Sometime around when working with the single particle system, there was some speed glitches. Not much, but enough to be noticeable. So, I checked on the jPCT-AE forums for what others have done. and it seems that running a function to make the squares was faster.
My code:
public Particle(ParticleSystem particles)
{
object = new Object3D(Primitives.getPlane(1, 1));
object.setBillboarding(true);
object.translate(Particles.emitter);
object.Build();
object.Strip();
object.setScale(size);
object.setAdditionalColor(color);
}
Code from online:
public static Object3D createQuad(float width)
{
float offset = width / 2.0f;
Object3D obj = new Object3D( 2 );
obj.addTriangle( new SimpleVector( -offset, -offset, 0 ), 0, 0,
new SimpleVector( -offset, offset, 0 ), 0, 1,
new SimpleVector( offset, offset, 0 ), 1, 1);
obj.addTriangle( new SimpleVector( offset, offset, 0 ), 1, 1,
new SimpleVector( offset, -offset, 0 ), 1, 0,
new SimpleVector( -offset, -offset, 0 ), 0, 0);
// Make it billboard:
obj.setBillboarding( Object3D.BILLBOARDING_ENABLED );
// Set up the transparency:
obj.setTransparency( 50 );
obj.setTransparencyMode( Object3D.TRANSPARENCY_MODE_ADD );
obj.setLighting( Object3D.LIGHTING_NO_LIGHTS );
obj.build();
return obj;
}
My new code (+ the online above code)
public Particle(ParticleSystem particles){
Position = new SimpleVector();
color = particles.color;
size = particles.size;
object = createQuad(1);
object.setScale(size);
object.setAdditionalColor(color);
}
This was able to add some boost....although it makes me curious of how the objects were created in the "Primitives.getPlane(1, 1)" function. Anyway, this may be changed/ removed after applying the Rajawali optimization changes.
Edit:
The code which jPCT-AE uses to make the planes with "getPlane(int quads, float scale)" is that far from the code which I'm already using. The code I'm using has less padding and only makes a 2-triangle square
public static Object3D getPlane(int quads, float scale){
float startx = -scale * quads / 2.0F;
float starty = startx;
float tx = 0.0F;
float ty = 0.0F;
float dtex = 1.0F / quads;
Object3D obj = new Object3D(quads * quads * 2 + 8);
for (int i = 0; i < quads; i++) {
for (int p = 0; p < quads; p++) {
float dtx = tx + dtex;
float dty = ty + dtex;
if (dtx > 1.0F) {
dtx = 1.0F;
}
if (dty > 1.0F) {
dty = 1.0F;
}
obj.addTriangle(
startx, starty, 0.0F, tx, ty,
startx, starty + scale, 0.0F, tx, dty,
startx + scale, starty, 0.0F, dtx, ty);
obj.addTriangle(
startx, starty + scale, 0.0F, tx, dty,
startx + scale, starty + scale, 0.0F, dtx, dty,
startx + scale, starty, 0.0F, dtx, ty);
startx += scale;
tx += dtex;
}
starty += scale;
startx = -scale * quads / 2.0F;
tx = 0.0F;
ty += dtex;
}
return obj;
}
No comments:
Post a Comment