WackyToaster's Recent Forum Activity

  • will not succeed in smooth transitions from one animation to another

    Not entirely wrong but also not entirely true. You can draw transition animations if you want to.

    Also, your game will take up more memory at times

    True, but in this day and age it pretty much doesn´t matter. Every phone has gigabytes of space and people also happily download a game even if it´s 500mb (like the game you posted has almost 500mb)

    And since because you said it cannot be done with the same quality in Construct... observe:

    Subscribe to Construct videos now

    And yes this is made in Construct.

  • Just because there is no deformation mesh doesn´t mean you cannot create similar games? Just do traditional sprite animation, maybe with some added tweening if you feel fancy and you are good to go.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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

WackyToaster's avatar

WackyToaster

Online Now

Member since 18 Feb, 2014
Last online 26 Nov, 2024

Twitter
WackyToaster has 25 followers

Connect with WackyToaster

wackytoaster.at

Trophy Case

  • 10-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Coach One of your tutorials has over 1,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • RTFM Read the fabulous manual
  • x17
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x5
    Lightning Draw First person to up-vote a new Construct 3 release
  • x10
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

23/44
How to earn trophies

Blogs