APE - A 3d particle engine for GLBasic.

[Hemlos]

Its already using milliseconds as a regulator, I said 20 fps, but i meant 50ms(same thing). 

[fuzzy70]

On my system there are problems with the regulating/prevention implementation in that it dips below 20fps for 2-3 seconds which is a bit longer then I was expecting. For example drops to 19fps then 13-14fps for a couple of updates before going above 20 again. If I zoom in closer the problem gets worse.

Lee

[Hemlos]

As expected Lee.
150k particles is EXTREME.
Without the regulator, your game framerate would drop to 0 fps instantly!

The way it works is, it chops off 10% of total count each frame, until it detects minimum designated speed.
eg. if it were 100k particles, this stabilization would happen quicker.
Keep in mind, when you build a game, you should not be depending on the regulator to provide max particles to your end users.
This is simply an emergency cutoff to prevent instantaneous frame locking.

Typically, you wont even use the regulator at all, because using it will create more unneeded computations.
The regulator will be an option you will use as a programmer, in situations where you dont know whats causing a game to lock fps to 0.
That said, its a debugging tool as opposed to a performance feature.

[Hemlos]

Ok since this is going to end up being a gbal, a better way of doing help file is directly in a separate .gbas file.
This file not only contains help information for all the commands, but also all the actual function calls in the type.
So what you would do with this, is open it in your ide, but not your project source file list.

I rewrote the helpfile knocking out typos.
Also, i added honorable mentions for people who helped with testing, if i forgot anyone let me know.

 New help file attached here:



[attachment deleted by admin]

[Hemlos]

Here is a test of explosion arrays.
I made an array of 20 explosions which each have 3 particle emitters, 100 particles each emitter.
The 3 emitters are flames smoke and embers.

So, that 300 particles for each of the 20 explosion arrays.
Theyre all in an array like this: array[20][3]

Left control to fire one....left shift to fire all of them.

You will notice, these arrays are being recycled.
This is great because many explosions can ingite and no memory will be wasted.
I picked 20 arrays, which may be overkill, you may want more...or less for a game, depends on the game i suppose.


[attachment deleted by admin]

[fuzzy70]

All working fine here, explosion sounds odd with left shift being pressed but that's prob due to so many sounds being triggered at once.

Also I assume you are aware that the explosions (both single & multiple) shift to the right (if looking from the starting viewpoint) if the key is pressed again to soon. Only mentioned it just in case 

Lee

[Hemlos]

ya its just to show 20 arrays of explosions waiting in line to be used, and being recycled, proof of concept.
thanks for the feedback lee

[kanonet]

I think i found a bug in your arrows, but dont know how to describe it. Maybe ask me about it next time in IRC. Or i need to make a video dont know, will need to think about it.

[Hemlos]

I know what you mean, its not really a bug per say, but rather a side effect of fluxuations in processing time.
All objects are using time segments to move, to maintain consistancy of distance movement, from one machine to the next.

I already have an averaging algorithm in place for 10 frames.
Do you think its bad enough i need more time segments averaged in?

[Hemlos]

After putting it aside for a day, i reviewed the code before trying to fix it.
Discovered i forgot to use square time with the gravity duh lol.
Now its sorted out, everything is relative as it should be.
I reduced the explosion array to 10 explosions, this is enough to fluxuate the fps for this test.
They die quick, its enough for a large game too.

The test:
Keep your eyes on the arrows when you test this explosion array, no particles(including arrows) should go off its course when the fps fluxuates.




[attachment deleted by admin]

[kanonet]

This did fix the problem with arrows, at least i cant see it again.

[Hemlos]

Be on the lookout for a new test soon.
Ive been studying the science of sorting algorithms to implement a very fast z sorting, as you would guess for better quality of transparencies.
I have a couple hours of studying to do based on the theories of sorting algorithms from my harvardx comp science course, after this ill be able to make some solid descisions for which to do tests with.

In a sense i am reinventing the wheel here.
Why you might ask? Yes, and surely, there is proven sorting methods for great speeds to sort many numbers.
However the reasoning behind the many sorting algorithms out there is due to the fact not all computational systems are alike.

This particle system is not based on fixed computational methods, so using proven methods based on nondynamic computation systems isnt really going to prove to be faster, ie.. merge sorting
The numeric system is an emerging depth order, and i am thinking that bubble sorting might actual prove to be fastest, especially because not all particles are rendered at once.

If my theory here is correct, the sheer speed of big O(<n) will be a great advantage!

[Hemlos]

big O(<n)

My bad, i meant the sorting time is going to be O(1), which means...Fast!

Ill have this done in the next couple days when i get the time.

[Hemlos]

No test will be published for the z ordering, afterall.
The z ordering is working perfectly as i expected it to, however, there is no observable difference!

It seems the only thing that really plays a role in the "slicing" of the transparencies (as observed by kanonet) in an earlier test, is alphatesting.

Kano, do you think there is an issue with TSprite here using the glarrays as it were?
Shouldnt the transparencies by additive(accumulatating the colors) when rendered z ordered from back to front? (eg first rendering the particle furthest from cam, to the particle closest to cam being rendered last)

Im finding this system difficult ( if not impossible ) , to truely blend all the colors as expected from any transparent particle emitter.

[kanonet]

Old version of TSprite used glarrays, new one uses just good old glbegin. There should be no visible difference in both, only speed. Alpha works the same on both.

Alpha is always an issue in opengl there are millions of texts about this in the web, seems like its very hard to get it looking the way you want it. I would say, dont waste to much power on ordering everything - i mean you cant order everything, even if order all your particles, thats still not everything thats inside the game, so other objects would still be out of order. Maybe this is a working compromise: order all particles in each emiter (independently from other emiters) and order all your emiters. In theory this few small lists should get sorted faster than one big list and the result should still look ok in most cases. Just an idea.