Subframe Thinking
-
Okay, i have a concept of a subframe "method" of doing things.
Imagine a subframe electronic contraption, and because of the particle order, it will do its thing and then yeah, in 1 frame. (depends on how you make it)
However, okay, what if we dont wait the next frame, but choose to literally push (or copy) the enitre contraption down, where the particle order hasnt yet checked?
After its done, its pushed downwards so it can sorta do it twice in 1 frame, because of the particle order updating.
So you can have 2 CPU instructions in 1 frame, or at least 1 in 1 frame, if some instructions take several frames to be done, nonetheless, you will double the speed.
You can actually push and trigger more than 2 times, but lets stop at 2 now.
How can we do this? Is it even possible? Lets think about it. I had, but didnt come up with anything useful.
-
So, if you had a particle at x,0 and y,100, if you Dray'd the particle back to x0,y0, would the game recalculate the particle order of every particle after x0,y0.
My gut tells me no, otherwise you could endlessly re-use the same piece of hardware between arbitrary points with recursion. Completely throwing the 60Hz barrier out the window. (freezing the game until your calculation is done, lol.) -
@G-LinuxorU Well, i might have not explained it well enough or you didnt understand me.
I mean, you have a particle at x:0, y:100. You make it do what it does, then somehow
move or copy to x:0, y:200. Then do it again.
At the end, you get it back to the original position. That way you can sorta make it complete 2 cycles in 1 frame.
-
I believe particle order evaluates based on particle ID (e.g. 0 upwards) rather than position (left to right, top to bottom). Maybe most people think its the position, but this is caused by saving (TPT arranges pID "L to R, T to B"), therefore particle order does its work "L to R, T to B" because of the arranged pID. And it's a different situation in the actual simulation.
Moving it through PSTN would not work, because particles pushed does not change pID (or particle ID).
Example, you have the contraption at the top, let the contraption be evaluated, and push it down to the bottom. The contraption didn't change pIDs, therefore it wouldn't be reevaluated.Copying through DRAY won't either. This one's more complicated, but I'll try to explain.
Trying to copy the contraption downward: Well, DRAY creates particles with incremental pIDs, that is, it assigns pIDs starting from the one nerest to it. So, when we do it in 2D, we get this:S S S S S S - SPRK
D D D D D D - DRAY
..1.2.3.4.5 \
6.7...8.9.A |-the original contraption "L to R, T to B"
B.C.D...E.F /
..3.6.8.A.D \
1.4...9.B.E |-the copy "T to B, L to R (which is bad)"
2.5.7...C.F /And there's DRAY copying diagonally, which is another problem (and I didn't include in the example).
Edited once by Draco712. Last: 15th Sep 2017 -
@Draco712, Thanks, but i have already solved the issue with the DRAY copying with mirrored particle order. You just have to make another DRAY, to dray it in the opposite direction of the first one, then it would mirror the particles again, and it will work. Plus, you can DRAY it in the original position. Try it :)
Also, you might think, okay, i make it update 2 times in 1 frame, and then on the next frame, i DRAY it in the original position to restore itself, isnt it not worth it? Yes, but you can compensate and gain, if you make it update more than 2 times, ie copy it more times.
Also, this concept has a proof that it works:
2185872View Save 2185872 -
Problems
- @NoVIcE (View Post) This isn't doing what you think it is doing, since you copy it to the left, the DRAYs' IDs make it so that each row is copied to the left right after that row finishes simulating. This means that instead of turning the spark off and on again in a single frame, what you are actually doing is activating the ARAY with the same spark. (This exact effect could be achieved by layering 2 ARAY together.)
- Another problem with this is that SPRK needs to have a life of 3 to activate most things, but the life is only decremented once per frame, before anything is simulated.
- Another major issue with this is that layering does not copy properly.
Solutions
- You could fix this problem by loading the save (or stamp) with all of the DRAYs underneath all of the stuff you want to copy, and then using PSTN to push them into position.
- This problem is much harder to fix, I believe the best way to do it would be to only reset the SPRKs after everything has been copied over, this would likely require having a bunch of SPRKs set up outside of the copy area being copied into the original after it had been copied.
- The only way to fix the layering issue is to not layer anything that is copied.
There are also some more things that I feel could become an issue with this later on.
On the whole, I believe this might be theoretically possible, but the overhead required would make it useless, it would just be easier to layer the things you want to do twice individually, or to just make two of the thing that you want to copy.
Edited once by mecha-man. Last: 19th Sep 2017 -
Yeah, actually i dont know why i placed it right from the contraption.
I tried with placing it down, but the pID is again on the way. So, to do this, i have experimented with CRAY-ing some particles **in the process** of DRAYing the contraption, so the pID stays how its should. This is extremely hard to do, and in my case becomes bulky.
But, anything is possible.
-
I kinda made it update two times per frame continuously. It 'reupdates' a 16 by 8 square of particles. Here's the save:
2192513View Save 2192513It's 'pseudo' because for some reason, the upward (+up-left and up-right) ARAY doesn't seem to update two times (just one time). Other directions work fine, look at the save. (BTW in the save, the very first frame is the initialization of the DRAYs, so I left the contraption unsprked here.)
Why the PSTNs? I got the idea from Sandwichlizard's and samrrr's print heads, id:1919569 and id:1919007. They've used PSTN to initially arrange particle order in a desired position. I used that technique so that the contraption gets updated before DRAY B [in the save] (or is it DRAY D?) copies it.
Well, there are some limitations to this concept. For this specific way (this save), upward ARAYs do not work. Then, for devices that propagate SPRK (either directly, by ARAY-to-conductor, or nonreplacing CRAY(SPRK)), since electronics need SPRK with life 3 (and SPRK creation gives it life=4) and life gets decremented before a frame update (and not during the particle update), those kinds of devices will see no improvement in speed, or get misbehaved with sub-subframe parts.
