Arima's Forum Posts

  • So far I haven't managed to get a anything working on it other than an extremely simple .capx that simply displays a sprite. :( I haven't managed to come up with a pattern yet.

  • Np - glad it's working!

  • What was it that you were having trouble making? What was it about C2 that you were having difficulty with?

  • gazoogle - Don't be so sure - iOS 5 has a 2000% speed increase for HTML5 over iOS4. Also there is directcanvas and cocoonJS in the works to dramatically improve performance for apps.

  • Hmm... a guess is it might have to do with you using a waypoint text object's text as the parameter for the for each ordered condition. It might run into a string somewhere instead of a number which might crash it. Try replacing that with a numerical variable instead.

  • I don't think clickteam doesn't care about their product - there's no proof of that that I've seen or heard of.

    That said, I think pretty much every part of C2 is superior to MMF except for parts that aren't finished yet, like the image editor and such. There are a ton of advantages to C2 over MMF, and not many the other way around, and most, if not all of those advantages I've heard are on the to do list (EXE wrapper, improved mobile performance, easier object switching, etc). Stick with C2! :)

  • As far as I know, copying and pasting between layouts is fine, between .caps is not.

  • What would you want to combine from MMF, if it doesn't do per pixel collisions for physics either, and for what reasons? The bullet behavior in C2 has a bounce option, BTW.

  • - What I generally do to find crashes is save a copy, then delete code section by section until it stops crashing. Then narrow it down to find out what exactly is causing it.

  • You need to add the mouse and keyboard objects to the project first. It's the same way you add a sprite in the plug in list.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Metal_X - Ashley has said of that JavaScript both isn't fast enough and doesn't allow for certain operations that they used to make construct classic's collision detection so fast.

    AnD4D - I'm a little surprised that works in MMF - have you actually tried it? As far as I thought I understood it, physics are generally a polygon based affair, or straight math in the case of a circular object. Construct classic has per-pixel collisions, but it requires the use of polygons for collisions when using physics, so it wouldn't take seconds regardless.

    Technically you could fake it by using physics object 'tiles' to make up the level, but it's true it wouldn't be a simple as you describe - you would likely have to set up the levels by hand the same way you would put together a level based on sprite tiles.

  • Yeah, topics like this are fine. We don't censor discussion of other tools here.

    Ashley has said they're going to look into making an EXE exporter when awesomium 1.7 comes out. Directcanvas and cocoonJS are also in the works to improve mobile performance. As for per-pixel collisions, why do you need them?

    My recommendation, of course, is to stick with C2. ^^ If nothing else, the ease of development I think is far more important than the need for per-pixel collisions - which is something there's a good chance you can fake, anyway.

  • konjak Jayjay - Actually, I think Dima111 is right! I tried it with a blank .cap - 6,674 bytes, created a sprite, added a condition for the sprite, then deleted the sprite, which deleted the condition automatically and resaved - the resulting .cap is 6,954 bytes! Deleting the event first and then the sprite instead results in 6,697 bytes.

    It would appear both ways that construct is not cleaning up after itself properly. Thanks for the idea Dima111, I had been wondering what caused that for ages!

    lucid R0J0hound if either of you happen to work on CC again, any chance of this bug getting fixed? And though I realize that this might not be something you can devote the time to doing, you have no idea how much nicer it would be for me working on loot pursuit if you could get it to also clean up the garbage that was left from previous versions so I didn't have to wait 7 seconds every time I edited something on that event sheet! ^^

  • Also, Arima, if you've once had event sheets that take MINUTES to open, I probably have no serious memory leak issues to worry about for quite a long while, haha. Nothing I've opened in Construct has taken me longer than a second or two.

    konjak - I think that's a separate issue actually. I think the memory leak itself is restricted to the image editor, the number of objects, the number of objects in a layout and possibly the number of animation frames in those objects. The event sheet taking 10 minutes to load seems to be completely unrelated. :/ It doesn't even make much sense, because the event sheet that takes 10 minutes to open is about 6000 events, and yet another event sheet with almost 2000 events takes 5 seconds to open. I have no idea what's going on there, but it seemed to take longer after having tried to split that event sheet up into multiple smaller event sheets, and then recombining them.

  • Ashley - What about a way that we could switch rendering modes at runtime via events? That way we could do a check for if the frame rate is really low with web GL, then we could switch to canvas 2D instead. Is that sort of thing possible, or does it have to be done at the start when the page loads?