Code: Particle module or include file plus editor

[Petr Schreiber]

Hi Simone,

I would not use GL_LINES, as they are slower than classic polygons and they do not get thinner with distance.

There are many approaches to replicate sparks, I have seen following used in games ( and preproduction of Episode 7 ;D ):

Approach #1> Solid object
... so no particle. You create little spark object, you put lot of them on one place ... it is like launching multiple tiny rockets. You have to turn them during flight as they fall down.

Approach #2> 2 poly Particle
Two crossed quads with spark texture - turned as they fall down.
They do not always face camera, look quite good.

Approach #3> Particle
Round circle fades from yellow to black and has very short life span.
They always face camera, but fall down attracted by gravity.

So all have in common some gravity force, which is missing from our system now.
Approach 1 represents one spark by one object of few polygons, approach 2 represents spark by 2 crossed quads, approach 3 represents one spark by multiple particles delimiting the sprak trajectory.

Approach 4 would be to use motion blur and let there fly just one light point - but this is little clumsy solution, so far #2 looks ok to me, although it does not fit to particles design.


Petr

[Simone]

Hi,

Approach #2> 2 poly Particle
Two crossed quads with spark texture - turned as they fall down.
They do not always face camera, look quite good.

Ok approach 2, sounds good for me, for physics we can use uniformly accelerated motion that use weight of particle multiplied by gravity force, and obviously we have to know the trajectory of particle.

I think that to do this approach we have to find a nice Texture.

Ciao,
Simone

[ErosOlmi]

I'm studying TBEM source code but it requires some time. It is a quite complex code to understand and follow.

In any case I think it is something related to timing when a new event is added and immediately supposed to be executed.
In my tests I've see that if all events are set to be repeated at intervals more than 100ms by TBEM_SetRepeat function, the 2/3 seconds of inactivity disappear but of course code is not so nice looking. I think that with intervals lower than 100ms GetTickCount has some problems in fast CPU. But, again, this seems visible only if the events to fire is supposed to be executed immediately after adding it into the queue. So some initialization param is failing or is inconsistent so TBEM_RUN enter in a temporary loop.

Still looking at the problem ....

[ErosOlmi]

OK, I've found the problem. Solution is easy from the script point of view but quite complex to solve from the module point of view.

I will start from the script change.
Every TBEM_ADDEVENT must have a starting time specified. So instead of:
[code=thinbasic] eventParticleAdd = TBEM_AddEvent("Particle_Add", %evt_ParticleAdd)[/code]
change to
[code=thinbasic] eventParticleAdd = TBEM_AddEvent("Particle_Add", %evt_ParticleAdd, gettickcount)[/code]

Without a starting time, TBEM event manager the very first time the event is fired will enter into a loop that can take a while to complete. The loop is
[code=freebasic] While @currEvent.starttime <= time
@currEvent.starttime = @currEvent.starttime + @currEvent.intervaltime
Wend[/code]
Because @currEvent.starttime will be ZERO at first, depending on @currEvent.intervaltime it can take a while to complete.

From the module point of view, I will comment later when I will have study more deeply TBEM source code.

Ciao
Eros

[Michael Hartlef]

ok, that should be easy to solve. When an event is created, I can set the time member to the current tickcount.

Still I don't understand why it takes that long on your computer and not on ours.

[ErosOlmi]

The reason is easy: you use GetTickCount function to set the timers.
That function retrieves the number of milliseconds since the computer was started. But because I usually do not switch off my laptop but put it always in suspended mode, my computer results to be started some days ago, so a lot of milliseconds ago.

Now, if your timer is set to zero and inside you WHILE/WEND you add 20 milliseconds each loop, to get my current GetTickCount it takes a while (how many milliseconds there are in 5/10 days?

So your idea to set a default starting time if no staring time is specified is good and should work in almost all cases. Anyhow remember that GetTickCount can return correct results up to 49.7 days as indicated in Microsoft documentation. This open some considerations when TBEM is used on machines that usually do not switch off like servers. For example in the company I work for some server are restarted every six months or so.

For the moment you idea of a starting time is perfect.
I'm still looking at your code to see how it can be possible to improve.

Ciao
Eros


PS: a little improvement in speed can be achieve in this way:
set funcName to ASCIIZ instead of string: funcName As Asciiz * 64
than when you need to pass it to "thinBasic_FunctionSimpleCall" do not use "Trim$(@currevent.funcName)" but just "@currevent.funcName"
this avoid thousands of TRIM$ calling because PowerBasic will just pass the name up to the NUL char. Also thinBasic internally is already making internal checking on it.

[Michael Hartlef]

Hi Eros,

try the attached version and let me know if it is better now. Which timer function woudl be better to use and also availabel in thinBasic?

Michael

[Michael Hartlef]

Further discussion about the timing in the TBEM module, please do it here:

http://community.thinbasic.com/index.php?topic=2178.0

[Michael Hartlef]

Simone and Petr, do you think that you guys can deliver the needed fucntionalities and an editor application till the end of the month?

[Petr Schreiber]

Hi Mike,

I know we are silent like ... something silent , but I think the particles in form of include are realisable in form of include in scale needed for this project before October ends.
We will go the traditional way shown in my smoke demo and Simones rocket - that means textured particles changing position, color and scale during their life.


Petr