AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
0c22997075
skia2/tools/viewer/ParticlesSlide.cpp

358 lines
11 KiB
C++
Raw Normal View History

Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
/*
* Copyright 2019 Google LLC
*
* Use of this source code is governed by a BSD-style license that can be
* found in the LICENSE file.
*/
#include "ParticlesSlide.h"
SkAnimTimer -> AnimTimer Change-Id: I700b7c0461475062ac66712cc29070f150cf777d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/202315 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-03-20 16:55:08 +00:00
#include "AnimTimer.h"
Add curve visualization back, guard eval Editing curves is still cumbersome, but that's fine. Visualization is just for feedback (and imgui's path renderer is a little wonky), but this helps a bit. Bug: skia: Change-Id: I3dace6d822d472314513bb1ad72bcea1e8991b77 Reviewed-on: https://skia-review.googlesource.com/c/192828 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-15 15:45:56 +00:00
#include "ImGuiLayer.h"
change particleslide to use Resources standard way to find assets across different platforms Bug: skia: Change-Id: I4cb464be1e643a59431eba66b5caad70ecfed1e9 Reviewed-on: https://skia-review.googlesource.com/c/196775 Reviewed-by: Greg Daniel <egdaniel@google.com> Commit-Queue: Mike Reed <reed@google.com>
2019-03-02 22:57:20 +00:00
#include "Resources.h"
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
#include "SkOSFile.h"
#include "SkOSPath.h"
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
#include "SkParticleAffector.h"
Moved image params out to SkParticleDrawable Added a simpler circle drawable, moved drawing code out so that frame calculation is handled by the drawable. Fixed all the sample effects, including some size adjustments to better create the intended effect. Bug: skia: Change-Id: I60af9cd6262ff98352ca8ceaf6768aef9c7e164c Reviewed-on: https://skia-review.googlesource.com/c/193029 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-15 19:29:38 +00:00
#include "SkParticleDrawable.h"
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
#include "SkParticleEffect.h"
#include "SkParticleSerialization.h"
#include "SkReflected.h"
#include "imgui.h"
using namespace sk_app;
namespace {
static SkScalar kDragSize = 8.0f;
static SkTArray<SkPoint*> gDragPoints;
int gDragIndex = -1;
}
///////////////////////////////////////////////////////////////////////////////
static int InputTextCallback(ImGuiInputTextCallbackData* data) {
if (data->EventFlag == ImGuiInputTextFlags_CallbackResize) {
SkString* s = (SkString*)data->UserData;
SkASSERT(data->Buf == s->writable_str());
SkString tmp(data->Buf, data->BufTextLen);
s->swap(tmp);
data->Buf = s->writable_str();
}
return 0;
}
class SkGuiVisitor : public SkFieldVisitor {
public:
SkGuiVisitor() {
fTreeStack.push_back(true);
}
#define IF_OPEN(WIDGET) if (fTreeStack.back()) { WIDGET; }
Remove SkField, it's no longer used Bug: skia: Change-Id: I8efcbb09dce2cb0e4f33a10e4ff2148058c6fbc5 Reviewed-on: https://skia-review.googlesource.com/c/193362 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 15:45:56 +00:00
void visit(const char* name, float& f) override {
IF_OPEN(ImGui::DragFloat(item(name), &f))
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
}
Remove SkField, it's no longer used Bug: skia: Change-Id: I8efcbb09dce2cb0e4f33a10e4ff2148058c6fbc5 Reviewed-on: https://skia-review.googlesource.com/c/193362 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 15:45:56 +00:00
void visit(const char* name, int& i) override {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
IF_OPEN(ImGui::DragInt(item(name), &i))
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
}
Remove SkField, it's no longer used Bug: skia: Change-Id: I8efcbb09dce2cb0e4f33a10e4ff2148058c6fbc5 Reviewed-on: https://skia-review.googlesource.com/c/193362 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 15:45:56 +00:00
void visit(const char* name, bool& b) override {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
IF_OPEN(ImGui::Checkbox(item(name), &b))
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
}
Remove SkField, it's no longer used Bug: skia: Change-Id: I8efcbb09dce2cb0e4f33a10e4ff2148058c6fbc5 Reviewed-on: https://skia-review.googlesource.com/c/193362 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 15:45:56 +00:00
void visit(const char* name, SkString& s) override {
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
if (fTreeStack.back()) {
ImGuiInputTextFlags flags = ImGuiInputTextFlags_CallbackResize;
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
ImGui::InputText(item(name), s.writable_str(), s.size() + 1, flags, InputTextCallback,
&s);
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
}
}
Particles: remove non-stable random, add better enum reflection The other generator was never used (or useful). String-based serialization of enums is quite helpful, though. Bug: skia: Change-Id: Ic9d58f8d20cfe7aba47722bd74f1e6f8f0f219e5 Reviewed-on: https://skia-review.googlesource.com/c/195368 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-02-26 19:58:40 +00:00
void visit(const char* name, int& i, const EnumStringMapping* map, int count) override {
if (fTreeStack.back()) {
const char* curStr = EnumToString(i, map, count);
if (ImGui::BeginCombo(item(name), curStr ? curStr : "Unknown")) {
for (int j = 0; j < count; ++j) {
if (ImGui::Selectable(map[j].fName, i == map[j].fValue)) {
i = map[j].fValue;
}
}
ImGui::EndCombo();
}
}
}
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
Remove SkField, it's no longer used Bug: skia: Change-Id: I8efcbb09dce2cb0e4f33a10e4ff2148058c6fbc5 Reviewed-on: https://skia-review.googlesource.com/c/193362 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 15:45:56 +00:00
void visit(const char* name, SkPoint& p) override {
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
if (fTreeStack.back()) {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
ImGui::DragFloat2(item(name), &p.fX);
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
gDragPoints.push_back(&p);
}
}
Remove SkField, it's no longer used Bug: skia: Change-Id: I8efcbb09dce2cb0e4f33a10e4ff2148058c6fbc5 Reviewed-on: https://skia-review.googlesource.com/c/193362 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-19 15:45:56 +00:00
void visit(const char* name, SkColor4f& c) override {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
IF_OPEN(ImGui::ColorEdit4(item(name), c.vec()))
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
}
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
#undef IF_OPEN
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
void visit(sk_sp<SkReflected>& e, const SkReflected::Type* baseType) override {
if (fTreeStack.back()) {
const SkReflected::Type* curType = e ? e->getType() : nullptr;
if (ImGui::BeginCombo("Type", curType ? curType->fName : "Null")) {
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
auto visitType = [baseType, curType, &e](const SkReflected::Type* t) {
if (t->fFactory && (t == baseType || t->isDerivedFrom(baseType)) &&
ImGui::Selectable(t->fName, curType == t)) {
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
e = t->fFactory();
}
};
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
SkReflected::VisitTypes(visitType);
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
ImGui::EndCombo();
}
}
}
void enterObject(const char* name) override {
if (fTreeStack.back()) {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
fTreeStack.push_back(ImGui::TreeNodeEx(item(name),
ImGuiTreeNodeFlags_AllowItemOverlap));
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
} else {
fTreeStack.push_back(false);
}
}
void exitObject() override {
if (fTreeStack.back()) {
ImGui::TreePop();
}
fTreeStack.pop_back();
}
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
int enterArray(const char* name, int oldCount) override {
this->enterObject(item(name));
fArrayCounterStack.push_back(0);
fArrayEditStack.push_back();
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
int count = oldCount;
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
if (fTreeStack.back()) {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
ImGui::SameLine();
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
if (ImGui::Button("+")) {
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
++count;
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
}
}
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
return count;
}
ArrayEdit exitArray() override {
fArrayCounterStack.pop_back();
auto edit = fArrayEditStack.back();
fArrayEditStack.pop_back();
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
this->exitObject();
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
return edit;
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
}
private:
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
const char* item(const char* name) {
if (name) {
return name;
}
// We're in an array. Add extra controls and a dynamic label.
int index = fArrayCounterStack.back()++;
ArrayEdit& edit(fArrayEditStack.back());
fScratchLabel = SkStringPrintf("[%d]", index);
ImGui::PushID(index);
if (ImGui::Button("X")) {
edit.fVerb = ArrayEdit::Verb::kRemove;
edit.fIndex = index;
}
ImGui::SameLine();
if (ImGui::Button("^")) {
edit.fVerb = ArrayEdit::Verb::kMoveForward;
edit.fIndex = index;
}
ImGui::SameLine();
if (ImGui::Button("v")) {
edit.fVerb = ArrayEdit::Verb::kMoveForward;
edit.fIndex = index + 1;
}
ImGui::SameLine();
ImGui::PopID();
return fScratchLabel.c_str();
}
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
SkSTArray<16, bool, true> fTreeStack;
Particles/SkReflected: Generalize array reflection This supports arrays of any type, and removes all of the special case code for arrays of SkReflected objects. (This is extracted from my rewrite of SkCurve, which needed something like this to work). Bug: skia: Change-Id: I55ab942f7922335dca0685d28b3b122bc4d53daa Reviewed-on: https://skia-review.googlesource.com/c/192620 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-14 18:23:51 +00:00
SkSTArray<16, int, true> fArrayCounterStack;
SkSTArray<16, ArrayEdit, true> fArrayEditStack;
SkString fScratchLabel;
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
};
ParticlesSlide::ParticlesSlide() {
// Register types for serialization
REGISTER_REFLECTED(SkReflected);
SkParticleAffector::RegisterAffectorTypes();
Moved image params out to SkParticleDrawable Added a simpler circle drawable, moved drawing code out so that frame calculation is handled by the drawable. Fixed all the sample effects, including some size adjustments to better create the intended effect. Bug: skia: Change-Id: I60af9cd6262ff98352ca8ceaf6768aef9c7e164c Reviewed-on: https://skia-review.googlesource.com/c/193029 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-02-15 19:29:38 +00:00
SkParticleDrawable::RegisterDrawableTypes();
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
fName = "Particles";
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
fPlayPosition.set(200.0f, 200.0f);
}
void ParticlesSlide::loadEffects(const char* dirname) {
fLoaded.reset();
fRunning.reset();
SkOSFile::Iter iter(dirname, ".json");
for (SkString file; iter.next(&file); ) {
LoadedEffect effect;
effect.fName = SkOSPath::Join(dirname, file.c_str());
effect.fParams.reset(new SkParticleEffectParams());
if (auto fileData = SkData::MakeFromFileName(effect.fName.c_str())) {
skjson::DOM dom(static_cast<const char*>(fileData->data()), fileData->size());
SkFromJsonVisitor fromJson(dom.root());
effect.fParams->visitFields(&fromJson);
fLoaded.push_back(effect);
}
}
Defer loading particle effect to load time. Moving this out of the constructor means less going on at slide creation time, making debugging easier. Change-Id: I37bdd249abef663931bc8ef152a92a3a3436dcf4 Reviewed-on: https://skia-review.googlesource.com/c/192600 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Ben Wagner <bungeman@google.com>
2019-02-14 18:22:43 +00:00
}
void ParticlesSlide::load(SkScalar winWidth, SkScalar winHeight) {
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
this->loadEffects(GetResourcePath("particles").c_str());
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
}
void ParticlesSlide::draw(SkCanvas* canvas) {
canvas->clear(0);
gDragPoints.reset();
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
gDragPoints.push_back(&fPlayPosition);
// Window to show all loaded effects, and allow playing them
if (ImGui::Begin("Library", nullptr, ImGuiWindowFlags_AlwaysVerticalScrollbar)) {
Various particle system improvements Effects now have a duration, and can be played looped or one-shot. Added a second list of affectors that are applied at spawn vs. update. Effects grab and store the SkRandom at construction, so it no longer needs to be passed to update(). Bug: skia: Change-Id: Ib54d60466e162e4d4b70fa64c1215fc01680d47a Reviewed-on: https://skia-review.googlesource.com/c/191722 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-02-14 19:49:55 +00:00
static bool looped = true;
ImGui::Checkbox("Looped", &looped);
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
static SkString dirname = GetResourcePath("particles");
ImGuiInputTextFlags textFlags = ImGuiInputTextFlags_CallbackResize;
ImGui::InputText("Directory", dirname.writable_str(), dirname.size() + 1, textFlags,
InputTextCallback, &dirname);
if (ImGui::Button("New")) {
LoadedEffect effect;
effect.fName = SkOSPath::Join(dirname.c_str(), "new.json");
effect.fParams.reset(new SkParticleEffectParams());
fLoaded.push_back(effect);
Various particle system improvements Effects now have a duration, and can be played looped or one-shot. Added a second list of affectors that are applied at spawn vs. update. Effects grab and store the SkRandom at construction, so it no longer needs to be passed to update(). Bug: skia: Change-Id: Ib54d60466e162e4d4b70fa64c1215fc01680d47a Reviewed-on: https://skia-review.googlesource.com/c/191722 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-02-14 19:49:55 +00:00
}
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
ImGui::SameLine();
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
if (ImGui::Button("Load")) {
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
this->loadEffects(dirname.c_str());
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
}
ImGui::SameLine();
if (ImGui::Button("Save")) {
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
for (const auto& effect : fLoaded) {
SkFILEWStream fileStream(effect.fName.c_str());
if (fileStream.isValid()) {
SkJSONWriter writer(&fileStream, SkJSONWriter::Mode::kPretty);
SkToJsonVisitor toJson(writer);
writer.beginObject();
effect.fParams->visitFields(&toJson);
writer.endObject();
writer.flush();
fileStream.flush();
} else {
SkDebugf("Failed to open %s\n", effect.fName.c_str());
}
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
}
}
SkGuiVisitor gui;
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
for (int i = 0; i < fLoaded.count(); ++i) {
ImGui::PushID(i);
if (fTimer && ImGui::Button("Play")) {
sk_sp<SkParticleEffect> effect(new SkParticleEffect(fLoaded[i].fParams, fRandom));
effect->start(fTimer->secs(), looped);
fRunning.push_back({ fPlayPosition, fLoaded[i].fName, effect });
}
ImGui::SameLine();
ImGui::InputText("##Name", fLoaded[i].fName.writable_str(), fLoaded[i].fName.size() + 1,
textFlags, InputTextCallback, &fLoaded[i].fName);
if (ImGui::TreeNode("##Details")) {
fLoaded[i].fParams->visitFields(&gui);
ImGui::TreePop();
}
ImGui::PopID();
}
}
ImGui::End();
// Another window to show all the running effects
if (ImGui::Begin("Running")) {
for (int i = 0; i < fRunning.count(); ++i) {
ImGui::PushID(i);
bool remove = ImGui::Button("X") || !fRunning[i].fEffect->isAlive();
ImGui::SameLine();
ImGui::Text("%4g, %4g %5d %s", fRunning[i].fPosition.fX, fRunning[i].fPosition.fY,
fRunning[i].fEffect->getCount(), fRunning[i].fName.c_str());
if (remove) {
fRunning.removeShuffle(i);
}
ImGui::PopID();
}
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
}
ImGui::End();
SkPaint dragPaint;
dragPaint.setColor(SK_ColorLTGRAY);
dragPaint.setAntiAlias(true);
SkPaint dragHighlight;
dragHighlight.setStyle(SkPaint::kStroke_Style);
dragHighlight.setColor(SK_ColorGREEN);
dragHighlight.setStrokeWidth(2);
dragHighlight.setAntiAlias(true);
for (int i = 0; i < gDragPoints.count(); ++i) {
canvas->drawCircle(*gDragPoints[i], kDragSize, dragPaint);
if (gDragIndex == i) {
canvas->drawCircle(*gDragPoints[i], kDragSize, dragHighlight);
}
}
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
for (const auto& effect : fRunning) {
canvas->save();
canvas->translate(effect.fPosition.fX, effect.fPosition.fY);
effect.fEffect->draw(canvas);
canvas->restore();
}
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
}
SkAnimTimer -> AnimTimer Change-Id: I700b7c0461475062ac66712cc29070f150cf777d Reviewed-on: https://skia-review.googlesource.com/c/skia/+/202315 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-03-20 16:55:08 +00:00
bool ParticlesSlide::animate(const AnimTimer& timer) {
Various particle system improvements Effects now have a duration, and can be played looped or one-shot. Added a second list of affectors that are applied at spawn vs. update. Effects grab and store the SkRandom at construction, so it no longer needs to be passed to update(). Bug: skia: Change-Id: Ib54d60466e162e4d4b70fa64c1215fc01680d47a Reviewed-on: https://skia-review.googlesource.com/c/191722 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Michael Ludwig <michaelludwig@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-02-14 19:49:55 +00:00
fTimer = &timer;
Particles: Cleanup and better UI Remove SkAnimTimer from the module interface entirely. Clean up some other SkParticleEffect methods. Simplify VisitTypes to just visit all of them, it's easier for the client to do any filtering. In the slide, make the UI far nicer. Load all files in a given directory, and allow editing (and saving) them all at once, or adding a new entry. Support multiple playing effects, with a draggable handle to set the position. Bug: skia: Change-Id: I0bec4077f9135bc122569f1410bebc96d5439480 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/197243 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com>
2019-03-06 16:08:48 +00:00
for (const auto& effect : fRunning) {
effect.fEffect->update(timer.secs());
}
Experimental Particle System This adds a new "Particles" slide to viewer, that allows editing, loading, and saving particle effects. All of the particle system code is in modules/particles. There are many rough edges and some not-yet-finished changes to generalize the model[1]. A rough overview: - SkReflected.h implements a lightweight reflection system for classes derived from SkReflected. Adding a new class involves deriving from SkReflected, adding a macro to the class declaration, and implementing visitFields(), which simply calls a virtual on an SkFieldVisitor for each field. Currently, emitters and affectors use this mechanism. - SkParticleSerialization.h demonstrates two useful field visitors - for serializing to and from JSON. The driver code that uses those is directly in ParticlesSlide. - SkParticleData.h and SkCurve.h define a variety of helper types for talking about particles, both for parameterizing individual values, and communicating about the state of a particle among the effect, affectors, and emitters. - SkParticleEffect.h defines the static data definition of an effect (SkParticleEffectParams), as well as a running instance of an effect (SkParticleEffect). The effect has simple update() and draw() methods. - ParticlesSlide.cpp adds a third field visitor to generate GUIs for interactively editing the running effect. --- 1: The critical change I'd like to make is to remove all special case behavior over time and at spawn (setting sprite frames, size over time, color over time, etc...). Integration is the only fixed function behavior. Everything else is driven by two lists of affectors. One is applied at spawn time, using the effect's lifetime to evaluate curves. This allows spawning particles with different colors as the effect ages out, for example. The second list is applied every frame to update existing particles, and is driven by the particle's lifetime. This allows particles to change color after being spawned, for example. With a small set of affectors using a single expressive curve primitive (keyframed list of cubic curve segments), we can have affectors that update color, size, velocity, position, sprite frame, etc., and implement many complex behaviors. Bug: skia: Change-Id: Id9402bef22825d55d021c5a2f9e5e41791aabaf4 Reviewed-on: https://skia-review.googlesource.com/c/181404 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-02-12 18:27:51 +00:00
return true;
}
bool ParticlesSlide::onMouse(SkScalar x, SkScalar y, Window::InputState state, uint32_t modifiers) {
if (gDragIndex == -1) {
if (state == Window::kDown_InputState) {
float bestDistance = kDragSize;
SkPoint mousePt = { x, y };
for (int i = 0; i < gDragPoints.count(); ++i) {
float distance = SkPoint::Distance(*gDragPoints[i], mousePt);
if (distance < bestDistance) {
gDragIndex = i;
bestDistance = distance;
}
}
return gDragIndex != -1;
}
} else {
// Currently dragging
SkASSERT(gDragIndex < gDragPoints.count());
gDragPoints[gDragIndex]->set(x, y);
if (state == Window::kUp_InputState) {
gDragIndex = -1;
}
return true;
}
return false;
}
Reference in New Issue Copy Permalink