Tokinsom's Forum Posts

  • Hard to say. My laptop (PCIe SSD) boots in 3 seconds and takes 4 seconds to preview Copy Girl. My desktop (Samsung 850 Evo) boots in around 15 seconds and takes 5 seconds to preview Copy Girl...so the PCIe is much faster but only helps preview by about 1 second. That's not accounting for the rest of the machine though. My desktop's CPU is much faster so maybe that has something to do with it.

    Also, that's a slightly older PCIe SSD. A brand new desktop PCI SSD could be faster but you're talking at least $400. Also I've heard they have some issues if used as a boot drive, but I don't remember the details. Last I looked into them was almost 2 years ago.

    Some of my older projects take 15+ seconds to preview on either machine so I'm also wondering how I can improve that. I was just talking about it in another thread, but C3's in-editor spritesheeting might be the only thing to really make a difference here.

  • Where did he confirm that, was it inside a post on the forums? Please send me a link if possible, that's sounds great.

    In these threads Ashley talks about in-editor spritesheeting being a goal for C3, and it requiring architectural changes that won't happen in C2. This was all regarding preview times but it affects export as well.

    I don't mean to speak for him nor say this is the ultimate solution to faster export times, but to my knowledge this will help a lot and is probably all we can expect for a while.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Nobody knows what will happen with C3 and if we will see any major improvements.

    Judging by the current information we got, it doesn't look well for the exporting side of things.

    Anyway, I don't want this topic to turn into a discussion about C3 and it's possible features.

    Ashley confirmed in-editor spritesheeting for C3, which should boost preview & export times considerably.

    It's kinda hard not to mention C3 when it comes to new features and even improvements to existing features. C2's all light maintenance and bug fixes now.

    Also I made a very similar thread a long time ago. Ashley's response was just this.

  • Image count has a huge impact on preview and export times

    Probably won't see any improvement here until C3

    Don't buy anything from AMD

    Stencyl's preview/export times are significantly longer. I am quite alright with C2's after learning this.

    S'all I got.

    I would like to see NW.js build options though. I don't care if 4 different builds take the same amount of time to process; it's really annoying having to delete a bunch of them and rename folders every single time.

  • Unfortunately this is something all sellers just have to deal with on any market. At least here you can contact a buyer to try to solve their problem and ask them to remove the bad review afterwards...provided they leave a written review and not just an anonymous rating, that is.

  • In short, surround each room with a "zone" using a sprite or 9-patch. If the player enters a new zone, destroy the enemies/objects outside of its bounding box and use 'recreate initial objects' inside of its bounding box. To be extra safe you can destroy objects outside of the previous room first, then recreate the new room, then destroy everything outside of the new room. Depends on the type of transition you want, really.

    Not to shamelessly advertise, but my Metroidvania Game Kit does exactly this

  • You do not have permission to view this post

  • Works for me. Debugger's busted though

  • If you're gonna be spreading out a simple grass texture like that then the Tiled Background Object is probably more suitable. Tilemaps with extra details can go over that.

    Or you can just use Tiled's fill tool and import the .tmx into a C2 tilemap object in the layout editor.

  • (Would be nice for C2 but will probably have to wait for C3 if the idea is supported.)

    The ability to tag and/or color instance variables would be very helpful, especially if you've got teammates working on levels that aren't familiar with all of them. Some examples...

    Editor: These are variables that can be freely modified in the layout editor, like the contents of a treasure chest or the item a particular enemy instance should drop.

    Private: "Internal" variables that are only modified via events and should not be touched in the layout editor.

    Family: These variables are inherited by a family and are not unique to this object. (These should be automatically separated from the rest, really)

    States: These variables control the object's states or mechanics like Attacking, Climbing, Dashing, etc.

    Stats: These variables define the object's stats, like HP, MP, ATK, DEF, etc.

    Currently you can add prefixes or whatever to help define the variables, like E_Contents, Private_Timer, Mech_Jumping, etc. but that can get messy and make expressions really long or hard to read.

  • Mh. Yeah, creating a 3rd family specifically for using "Recreate Initial Objects" works, I just wanted to avoid it because that's a lot of objects to account for. Easier to just recreate all the families so nothing gets missed.

  • Ashley This isn't necessarily a bug as much as a design issue/possible oversight, so I'll post here.

    I have an object that is in both "Family A" and "Family B". Since I use "Recreate Initial Objects" on both families, my object is recreated twice. Is there any way this can be fixed? I don't think there's anything I can do on my end with events..

  • Change the sampling to "point" in the project properties.

  • Prominent There we go! Simple but effective. I had considered writing my own jump that overrides the platform behavior's but feared it would mess with it too much. Didn't think about just using the existing y vector / gravity...derp.

    btw it looks like the y positioning and rounding isn't necessary - just modifying vy and the y vector seems to do the trick.

    Thanks all.

  • GenkiGenga Thanks for the .capx but that has the same problem as Asmodean's - The player hovers for an undetermined or fixed amount of time instead of for the remainder of the jump.

    Also worth noting that if the player is jumping while moving, hits a ceiling, and then moves past the ceiling, the jump will continue upwards (provided he's not at the falling end of the complete jump arc).

    I think the only way to properly do this is to modify the platform behavior or make a whole new jump mechanic with events :T hmm..