Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does/should ParticleGenerator work? #354

Open
Gadgetoid opened this issue Sep 21, 2020 · 1 comment
Open

How does/should ParticleGenerator work? #354

Gadgetoid opened this issue Sep 21, 2020 · 1 comment
Assignees

Comments

@Gadgetoid
Copy link
Contributor

Looking over ParticleGenerator and the particle example reveal several wrinkles that I think should be fixed.

Perhaps I'm overthinking the role of the particle generator here, but presently in the particle example it seems almost completely unused.

ParticleGenerator

  • generate_per_ms and remaining_ms are currently unused?
  • Should ParticleGenerator be managed by the engine in the same way that Timers/Tweens are?
  • Should ParticleGenerator not include separate generate, update and render functions?

It feels like ParticleGenerator should handle expiring old particles and calling the necessary function to generate new ones, but then call out to an anonymous function for the "update remaining particles" portion of its functionality.

Perhaps update should be update_particle and render should be render_particle and these user functions can then only have to worry about operating upon a single particle:

    // update remaining particles
    for (auto p : particles) {
      update_particle(p);  // Call out to user supplied function
      p->age_ms += elapsed_ms;
      p->age = p->age_ms / float(lifetime_ms);
    }

Particle Example

  • How do rain_generate, rain, generate_basic_rain and basic_rain_generator interplay. Why so many named functions?
  • Why is only basic_rain_generator's update function called?
  • Why do spark(), smoke() and rain() not exist as update and render functions on the ParticleGenerator itself?

I would expect the code to feel something like this:

struct RainParticle : Particle {
    float wetness;

    rain_particle(Vec2 pos, Vec2 vel, float wetness) : Particle(pos, vel), wetness(wetness) {};
}

void update_rain_particle(RainParticle p){
    // Update physics nonsense
}

void render_rain_particle(RainParticle p){
    // Draw stuff
}

RainParticle generate_rain_particle(){
    return new RainParticle(
        // THIIIIIIIIIIIINGGGGGGGGGGGGGSSSSSSSSSSSS
    );
}

ParticleGenerator rain(250, 4000, generate_rain_particle, update_rain_particle, render_rain_particle);

void render() {
    rain.render();
}

void update(uint32_t time_ms) {
    rain.update(); // Possibly managed by engine, like Timers/Tweens?
}
@Daft-Freak
Copy link
Collaborator

Looks like the particle example has two copies of rain/smoke, one using the generator and one not (and the generator ones aren't used).

generator:

  • generate_smoke/smoke_generator/render_smoke
  • generate_basic_rain/basic_rain_generator/render_basic_rain

no generator:

  • smoke_generate/smoke
  • rain_generate/rain

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants