WackyToaster's Forum Posts

  • I don´t see a problem with that, go for it!

  • Really cool work! Reminds me (obviously) about the classic 3D baby-steps like doom/wolfenstein.

  • Wait... you made C2 all on your own? Holy moly I wasn´t aware of that. I always struggle sticking with a project as soon as I hit a couple months of work :V

    As a note to piracy. I used to pirate C2 for a while (pls don´t ban me, lol). I kinda was at a point where I needed to keep my money together for education. I obviously tried the free version first and just thought... wow I hate beeing limited, even though I was just toying around. I liked C2 and after beeing able to really try it as a whole with no limits, my liking grew until I caved in and bought it. So in some way, piracy may have been a contributor to why I stuck with (and still stick to) Construct. Nowadays, as pointed out, there are many more free options with no limits that I could just have picked instead, potentially ending up not beeing here.

    I always had the intention that if I end up with a project that I want to release in some capacity, I´d have bought a license anyway. If I make money, you get money sounded fair to me. (Kinda flawed argument but eh...) And to this day, I haven´t made any significant money with Construct, guess that didn´t work out exactly as planned. (Well, I always have something cooking but you know...)

    What I did gain was a lot of experience and knowledge, about programming logic, about communicating with a server (AJAX), about using server-side scripting, PHP, SQL, JS, math, nodeJS, Firebase, Admob, App-development general and probably much more that I just can´t quite think of now. Most of that stuff also wasn´t planned, but I´m not complaining.

    End of storytime

  • Yeah the 5 million is barely relevant. I think I alone am responsible for 20 of those. And construct 2 was supported for a long time from one-time purchases, I doubt there are still reserves left from that.

    And the current usercount is pretty much unknown, estimates at best. "100,000 users create games every month" How many of those are free users? And then there are a ton of costs for businesses, services (server, backup services,...), hardware (development devices, ipad/iphone/android devices for testing,...), wages, rent, power, water, heat... not to forget taxes. You may earn a million, but earning that million may have cost you 900k.

  • Well thanks, the high quality downscale mostly clears it up on the sprites (looking at the spritesheets it´s obvious why). I still noticed bleeding on tiled backgrounds, despite adding padding pixels on the opaque edge even when the game wasn´t all that scaled down. Eventually I settled for 5 extra pixels. Bleeding still happens when the game is scaled down really small, but at that point it´s unplayable anyway.

    Guess it´s a quirk that needs getting used to. Thanks again.

  • So there is this thing with tiled backgrounds that include transparency. Since they are tiling, the trilinear (and bilinear) filtering methods will cause part of the non-transparent part to bleed onto the transparent part (and vice versa). They were mentioned every now and then and I think that was also the reason why the 1px transparent border was added when cropping in Construct to mitigate that issue.

    I sometimes see sprites still do this regardless, but it´s rare. I assume it´s because of the spritesheeting going on, that if the sprite happens to be in an "unlucky" spot and at certain zoom levels it can end up bleeding. Here's an example of a sprite having bleeding. In this case it is scaled down quite a bit (used as a more distant object). Looking at the spritesheet it´s quite obvious what causes the bleed. Note that both sprites have the 1px extra border.

    One thing I noticed it that the lines will not appear if the game is at the intended zoom level. But once you zoom, scale the game (by scaling the window) or scaling the layout/layer with events, the lines will start creeping in. After some testing I noticed that zooming in is less of a problem, and an additional 1px added will prevent the lines from appearing. When zooming out, even with 2 or 3 pixels extra it will eventually bleed, though you really have to zoom out quite a bit for that.

    I just think this shouldn´t be a thing, and I know that setting sampling to nearest completely solves this, but I like my smooth edges, I don´t want jaggies. There must be a way to get rid of this... please :V

    Found this info on disabling mipmapping or using texture arrays, sounds kinda promising if possible. Especially the mipmapping since different zoom levels seem to be the main cause of that issue.

    gamedev.stackexchange.com/questions/46963/how-to-avoid-texture-bleeding-in-a-texture-atlas

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • 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