WackyToaster's Recent Forum Activity

  • Any webpage that can show an iframe will work with Construct. So basically all webpages will work with Construct. I'd be surprised if not.

  • I'm not 100% sure but I think it shouldn't matter too much. Using it within the editor may be a different story since there is no chunking (I guess?)

    I'm really no expert though.

  • Construct already does some chunking for you, especially on collision checks. First of all, offscreen stuff isn't rendered, so no GPU impact. However, if things move or have behaviors attached it will require the CPU to do work, so you wanna disable those where possible. Btw. checking every tick isn't a problem inherently, it depends on how much work has to be done. Better check 9 things every tick if it helps you to avoid checking 9000 things every tick.

    As for how to do chunking... I'm not entirely sure honestly. Probably with an array of sorts? There gotta be tutorials about it.

    On that note, since construct already does chunking, would it be possible to expose that with a plugin to be used with all kinds of behaviors? Ashley or maybe I'm wrong and this already works that way.

  • I guess the KaL Login probably is.

    The profile template mentions plugins and it probably won´t run out of the box, but I´d guess you can rebuild the functionality with C3.

  • Someone tried to recreate it. It looks very close to me in terms of behavior.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Thanks for the notes and workarounds!

  • All actions should happen after an On World Pre-Step

    Hehe yeah I figured that one out when I tested for framerate independence and things went bonkers :D In this particular case for deleting particles it didn´t seem to have any effect though while Trigger once made sure things happen properly.

    Good to know that particles and the sprites exist somewhat independent from each other.

  • I (maybe) got some more information on the memory out of bounds thing.

    First of all, the system max count of particles appears to be minimum 256. Even if set to 100, it will spawn up to 256 particles regardless. I don´t think this is what causes the error though (and I don´t really mind it)

    The second thing however are some discrepancies of created/destroyed particles that may lead to the issue.

    1. The spawnbox I have creates 530 sprites every time... EXCEPT the first time particles are created, where it only creates 529.

    2. The first spawn also seems to overlook the first created particle in the destroy action. So one particle will not be destroyed despite fulfilling the conditions. I nailed this down to the conversion of LFJS.ParticleUidFromSprite, it simply seems to be one off. If I add a LFJS.ParticleUidFromSprite - 1 it will destroy all particles but not the last one. (These particles keep flying until reaching the -12k issue)

    3. Destroyed particles are not actually destroyed, they are placed offscreen at -1000X -1000Y (I assume they are "stored" for reuse). Now if I just go ahead and check to destroy particles that have a Y lower than 300 it will permanently attempt to destroy those, just nothing happens since LFJS.ParticleUidFromSprite returns -1.

    As such I think I figured out the correct way of destroying particles is to filter out all particles that are exactly -1000X -1000Y (that is fine since naturally that will never happen, and even if probably not cause much issues) then use a for each sprite loop AND also use trigger once (Though I´m not sure why the trigger once is important, but it is required. I also tried using the pre world step trigger but that didn´t do anything)

    There is an action to clean up these unused sprites (destroy spare sprites) though I didn´t quite figure out a good place to put it. It usually seems to add issues and I don´t think in my case it will be useful. Either way, the discrepancy with the first spawn beeing one off still exists.

    4. There is also a weird correlation with this issue between the system max count aswell as Particle group tags. It´s a bit hard to explain. Basically if Group tag "A" causes particles of group tag "B" to despawn due to max count settings it will throw this error. If both tags are the same, it works fine. It also works fine even with different groups as long as the max count setting is "amount of newly created particles + 2"

    My conclusion is that this "ghost particle" is likely the root of that issue.

    See these two new projects for debugging.

    wackytoaster.at/parachute/particleBugs2.zip

  • Something is broken with the code formatting and editing the post also doesn´t work :V here´s the link to a nicely formatted code version

    drive.google.com/file/d/0Byqm4cKYC28xV0M1NTdsNVBUMjQ/view

  • Does anybody know how Terraria keeps such good FPS? There are millions of blocks and water tiles,

    countless particles torches, etc. How did they do that? Any ideas? Thanks.

    This was answered in the thread already. Terraria (most likely) uses chunks and processes everything within those chunks while ignoring everything that is outside of said chunks. So the world is basically active around the player (+some extra) but everything else sort of gets frozen, doesn´t create particles/enemies etc. and thus takes basically no processing power. So yes, there are millions of tiles but it doesn´t matter. Even if you would put trillions in, only a specific amount of them is ever needed around the player.

    Also one should mention that when dealing with huge amounts of things, you will get more out of it when you use C# or C++ instead of javascript, even though javascript is slowly creeping up (especially with WebAssembly)

    In terms of water, I really don´t know how one could do it. I found this though

    youtube.com/watch

    Along with the code

    drive.google.com/file/d/0Byqm4cKYC28xV0M1NTdsNVBUMjQ/view

    I think there is a fair chance that you´d be able to translate this into Events or JS (or webassembly?), though it will likely be slower AND it is not optimized for chunking and such.

  • Good to hear! I´m pretty sure I can reasonably work around the -12k thing if it happens to be unfixable. For the destroying, I also think I probably won´t really need it for what I have planned so I think I´ll be fine either way, but obviously fixing it would be great.

  • I actually have never seen that before.

WackyToaster's avatar

WackyToaster

Member since 18 Feb, 2014

Twitter
WackyToaster has 26 followers

Connect with WackyToaster

Blogs