A way to eliminate potential EMP lag?
-
Well, this was made for two things.
The first, irrelevant thing, is that I had to restart my thermite generator to make the BMTL sequence WAY more compact.
And the actual topic (:D) is this:
Is there a way to make the potential lag from EMP become less, besides using less EMP?
A fairly simple question, yes, but it is somthing that I seriously need some answers (Even in the negative) as to if this is possible or not.
Ever since I upped my BREL generation by about 1200%, I have been getting noticable FPS drops upon running through my THRM generator.
Any suggestions on how to reduce it?
It may be a hopeless struggle, but I want to at least give it a shot.
-
@Webdude53 (View Post)
TPT is pretty much a FPS rollercoaster, expect it to change. EMP needs to update the entire screen in one tick so I would suppose it's slow. If you use like five pixels, that would (Maybe?) equate to five updates for a single frame. -
I know a way the developers could probably reduce EMP lag. Only count how many EMP particles there are instead of looping through all the particles for every EMP. After every particle is done updating and all the EMP has been counted, then loop through all the particles. Check if each one can be destroyed, and if it can, attempt to destroy it for each EMP there was; if it can't be destroyed, just skip to the next particle, and this would make it more similar to only having one EMP.
The only current way to reduce it's lag is to use less, and make sure as little as possible is activated every frame.
Edit:
@jacksonmj (View Post)
That would be even better too. I was sort of thinking about also doing that, and I didn't realize how laggy rand() was. -
@jacob1 (View Post)
True, I was just thinking about something similar to that. But I was thinking about increasing the chance of the particle being destroyed, instead of trying to destroy it multiple times. Otherwise just as many random numbers have to be generated (which can be quite slow), even though there is an improvement due to not iterating through parts[] as many times.
Some of the temperature increases may need to be changed as well, to more closely match the effects of multiple attempts to destroy the particle. -
@jacksonmj (View Post)
Something like this?
//chance being a float suggesting chance
chance = 0.05f * empc;
//rnd being a random number from 0 to 100 as percent
if(rnd / 100 < chance) {
to_brel(parts[r>>8]);
} -
@boxmein (View Post)
Not quite. Multiplying the chance by the number of EMP particles is a reasonable approximation (for small numbers of EMP particles and small chances), but is not the same probability as making multiple attempts.
For actions that can only happen once per particle (such as sparked semiconductors turning into BREL):
If the original probability of destruction was 1/100, the probability of the particle having been destroyed after n attempts to destroy it is 1 - (1 - 1/100)n
