Automatic updating for particle systems

[forthevin]

I have implemented a very basic version of particle systems, which can be seen in this fork: https://github.com/forthevin/enigma-dev. Recently, I have worked with implementing automatic updating of particle systems. In GameMaker, particle systems can be either updated automatically (the default setting), or updated by hand. I have determined that GameMaker updates the particle systems between the end-step events and the draw events.

The issue is now that updates and changes in GameMaker generally happens as part of instances and their events, and not outside them. This is reflected in ENIGMA's handling of events, since function calls (as far as I can tell) cannot be put directly in between events. Since particle systems are independent of instances and their events, they are an exception to the rule. Therefore, updating particle systems between the end-step event and the draw event seems non-trivial, since only events can be updated between events.

I have found two solutions to the problem. The first is to create a hacky event, that does not go through instances, but just calls a single function. It could look like this in event.res:

Code: [Select]

particlesystemsupdate: 100000
Name: Particle Systems Update
Mode: None
Default: ;
Instead: enigma::update_particlesystems();

The above code would be placed in between the end-step and draw events. This code solves the issue. The only thing of notice is that it also generates a superfluous virtual function in the object superclass. This solution is currently implemented in the fork and works.

The second solution I have found would be to extend the format of event.res, such that the format allows the above solution but without generating a superfluous virtual function in the object superclass.

My suggestion is now that the first solution is used as it is, while the second solution is postponed until further notice. Since the superfluous virtual function is never called, it shouldn't cause much (if any) overhead.

[Josh @ Dreamland]

If particles were the only systems requiring such an event, I'd probably go with the hack, but since they certainly are not, it's definitely better to do something else about them. Polygone already hacked up events.res to update some globals in a weird spot ages ago, and I haven't gotten around to dealing with that yet, either. So for now, go ahead and push your changes to master and the issue can stew for a while until I have time to do something about it.

I'd kind of like to reformat events.res into basic e-Yaml anyway, so LGM can read it. Otherwise we can't add new events in one spot later on. This might be a good place to talk about what that system should look like.

[polygone]

It was updating instance locals not globals. Also the path updates I put there (which are local as well).

[Josh @ Dreamland]

Whatever.

Point is, it needs restructuring so IDs don't need supplied. And while we're at it, we may as well make LGM use the file, too.

[polygone]

I suggested ages ago having LGM use the file. And having instances be able to call separate event files.

[forthevin]

Cool, I will keep the current implementation. There is one other thing that I would like to implement before pushing to master, namely including built-in sprites for the particle systems.

In regards to events and formats, I see both a localsweep event and several calls between events to [snip]enigma::update_globals();[/snip] in IDE_EDIT_events.h.

[Josh @ Dreamland]

@polygone: And Ism ignored the suggestion, and I didn't push the issue. Now we have two update hacks in that file, and as ENIGMA grows, we're bound to have more legitimate events as well. Having instances use different files is by far more work for Ism in the UI than it is for me.

@forthevin: The built-in sprites sound to me like the kinds of things that can be generated with simple math functions, which beats the shit out of any compression format we'd use.

And yes. It inserts the global updater itself. Polygone hacked in the local updater the same way you did.

Also, forthevin: Are you sure you need that "default" code? Does it just not insert the event without it?

[polygone]

Yes it's work for Ism but I consider it as a decent benefit for ENIGMA. You see so many games that use hundreds of wall instances that do nothing, being able to just switch them to use the localess res file would be an easy way for people to be able to increase efficiency.

[forthevin]

I hadn't thought about generating the sprites. I have taken a look at the sprites, and I think that good approximations can be generated for each of them.

Regarding "default", it did indeed not insert the event without it.

[Josh @ Dreamland]

All right, I'll see about adding a "mode: static" setting that just puts a piece of code or function call in the event function instead of the loop. Do we want to keep "instead" for it, or just make it "code:" or something? I'm happy with leaving it "instead: ", but I'm open to input on the matter.

[forthevin]

If there is no difference in work required, I would prefer "Code", but "Instead" is fine as well.