Skip to content

Particle effects Version 1 & 2#3520

Open
LizardKing777 wants to merge 3 commits intoEasyRPG:masterfrom
LizardKing777:DynRPG-Particle-Effects-V1-&-2
Open

Particle effects Version 1 & 2#3520
LizardKing777 wants to merge 3 commits intoEasyRPG:masterfrom
LizardKing777:DynRPG-Particle-Effects-V1-&-2

Conversation

@LizardKing777
Copy link
Copy Markdown

Both function independently of one another, so if a game was released using either version it should work flawlessly.

Both function independently of one another, so if a game was released using either version it should work flawlessly.
@jetrotal
Copy link
Copy Markdown
Contributor

some stuff to consider

/*
 * This file is part of EasyRPG Player.
 * ... (license header) ...
 * Based on DynRPG Particle Effects V1 by Kazesui. (MIT license)
 */

the generated code ignores the license code (my llm rigging of it had it removed to be economical, but it should be manually pasted)


Other thing thing, does the v1 and v2 share or repeat code?
Maybe having a dynrpg_particle_shared set of files, to group the repeated code could be thing.

@Ghabry
Copy link
Copy Markdown
Member

Ghabry commented Feb 23, 2026

Does this code address the non-working fast forward support?

When pressing "F" to speedup the Player the particles (e.g. in Deep8) kept the same speed (or even worse: On 120 Hz displays the particles were twice as fast than the rest of the game).

This was this "nobody understands the code Kazesui wrote" issue where I couldn't figure out how to split the Update and Draw logic.

And added EasyRPG Distribution/GNU File info at top. Still trying to figure out Version 2 (I can get it to sync, but then we end up with a Vector Substack out of range error.)
@LizardKing777
Copy link
Copy Markdown
Author

As far as I know, the two versions are basically independent of one another, so probably keeping the code separate for now is probably the pragmatic way to go. I added the license info back and got V1 to sync with the acceleration (they were keeping the same speed and calling at the accelerated rate, which was creating a neat but undesirable effect. Basically moving the particles from "Draw" to "Update" - but it's causing a "Vector Substack Out of Range" overload on the V2 particle effects, so I'm going to have to play around with that one a bit more.

Got it figured out - V2 particle animations now move at whatever speed the game is moving at, without overloading the vector.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants