[WIP] Ale Effect Editor

Hello all!
Since we had already posted some information in this topic, I decided to make a small video to show that we are still working on it. It can be found here.

Note that the editor where you can change all the emitter/particle/field values is still not finished and the table will be replaced. But you can already work with it and some live editing is possible. Also saving and loading the ale file into Freelancer is possible.

There are still some things to be finished before we can release, though. So don’t expect a release to soon.

If you have any questions, suggestions etc. feel free to post them here!

Also here is an image from the other thread:

I’ve been thinking: For the time being you could use a different (already finished, if there is one) particle system for your FL clone and when it has matured enough you could include our renderer / ale loader via dll. This would be when the game is basically playable (including (basic?) AI and network, maybe uses the open fl server we also have). I would write a c interface which you should be able to use. The renderer uses OpenGl 3.3 with instancing so it already is optimized. I am also thinking about a non instanced mode for older graphics cards, but for now it is mandatory.

It would be nice to have a working FL clone, so go on doing what you have been doing

I can precompile it for you. It’s written with freepascal / lazarus so it is not really os dependent. Please understand that we don’t plan to release the source as we would gain no benefit from it.

As for the states: You would have to set your vertex attrib arrays again and the blending modes. That should be all (at least at the current state). And of course different shaders are used.

Thanks!

The main benefit is not having to worry about releasing the code Meaning license, clean up and copyright stuff (since this would require our real names, which we are not really fond of to publish - and without them we would not be the authors since everyone can claim a nickname).

Basically from our point of view it would mean to invest more time which can better be spent implementing more things.

Thanks! And also thanks for the advice. In case we don’t decide to develop it any further making it open source is definitely very likely to happen. But for the time being we like to finish what we can do first. Maybe you can give us some further advice when the time comes, that would be very helpful.

Sorry, at the moment we know most of the bugs. When the time is right there will be a beta for everyone.

Currently I am working on this project again anyway, so only some progress has been made.

I have been working from time to time on the particle system and even recently solved our GUI problem by using html for all the dynamically generated inputs (Lazarus has a really nice component for this), but as Skotty pointed out I was not able to motivate him using it.

The last thing I started working on was cleaning the code up and optimize it using Data Oriented Design, so that it gets faster by being more cache friendly (although we already can simulate more than 10000 particles without problems).

There still is a problem with multiple fields behaving not the same like in FL. Beams need to be rendered different, so that they look similar. Also there are values which are not supported yet. But the really tough things are done I think.

Currently I am writing the normal, tangent and binormal calculation algorithm for the OpenGL project, so as you already pointed out I am still more focused on getting that project done.

Actually this is really heavy stuff. Especially the math is quite tricky at some points. With all those node transforms I had to reformulate the problem to make it fast enough for all this calculations per particle. Also there is lots vector math.

I think the best way one could help is figuring out the meaning of the missing parameters. But you would need to use adoxa’s xml tools to generate the ale effect and try to make sense of changes you do. The problem is that this is not easy and some stuff you only can figure out with lots of experience or being able to test ideas in an implementation. This is why I hesitated asking people for now. For some really tricky things I even used my OpenGL wrapper to let FL render effects in wireframe mode because otherwise it was impossible to figure out what’s going on.

When the most difficult parts are solved I plan to ask people for testing and maybe even release a beta where people can try to figure out the missing values by observing the effects in FL, but we are not there yet

Thanks! I had a look again at the fields and since I solved the mystery about the approach value the last time I am not sure whether there actually still is a problem with the fields. I’ll try to let you know until the weekend. I also will go through the document again to see if there have been any changes.

Last time I checked treewyrm had errors in the documentation. If we have the time and are sure enough it is not our mistake we will correct them.

One thing which is still a tough problem is the randomness of the emitters. If you do a naive implementation and use the frequency you will get an absolute deterministic behaviour, meaning your e.g. engine flame will flicker in always the same way (Example: 1,1,1,2,1,1,1,2, … particles per time step) . But this is not like FL behaves. It is what I was working on the last time when I was trying to figure out stuff.