Rable's Forum Posts

  • Thanks for the info. Good to know.

    One last question, is the exported version going to work just fine or should I reduce the number of animation to avoid any problem?

  • I made additional tests, it indeed seems to have a upper limit of animations allowed to be able to preview the project. Exported projects seems to work fine though (could this be confirmed by someone from Scirra?) but not being able to preview is quite annoying.

    For NW.JS preview, the limit is around 5796 animations. It seems that 5796 animations always fails, while 5792 animations always work.

    I've made a capx with 115 object of 50 animations each (49 are empty), and one object (Sprite 116) of 46 animation (total 5796), so you can test for yourself. Please note that despite the huge number of animations, there are only 2 sprites when exporting the project, as I used the duplicate animation and clone object to create them. The exported project is thus very small.

    With Browser preview, the animation limit seems higher. With around 7500 animations, preview with Chrome and Edge doesn't work for me (just duplicate object in the capx to have the desired amount of object), but I didn't notice a limit to preview with Firefox, even with 8000 animations.

    As a side note, Construct 3 previews perfectly even with 10,000 animations.

  • Hi everyone,

    I’ve got some problems in C2 preview (R244). The loading bar is red and the preview never starts. After doing a few tests, I noticed that when I deleted some animations of some newly added objects, the bar gets blue again and the preview works.

    I tried recreating those objects from scratch, implementing all the animations again, but the problem is still there. Even weirder, if I delete the 2 problematic animations, then create new animations that have the same name (but are empty), the problem shows up gain, and disappear if I delete these empty animations.

    I thought it could be the memory use, which is really high, but if I delete those animations, it work even if the memory use is higher than another file with the 2 animations in, but cropped so that the memory use is lower. That last file has always the red bar.

    Lastly, recreating the object from scratch (it was a clone of a similat object that has no problem) and reexporting the images from Photoshop doesn’t help.

    I did a very last test, and deleting a completely unrelated object actually solves the problem. Taking all this into account, it’s like my project reached the maximum allowed number of animations (??). Is there any kind of such limits? Ashley , could this be possible?

    Any idea about how to solve this?

    [Edit]

    Previewing with NW.js doesn't work but previewing with Chrome does work. This is worrying as the game is planned to launch on Steam using NW.js. :-/

  • Hi rexrainbow ,

    I didn't find anywhere the C3 version of the behavior Pause (Pausedt) associated with the Pause plug-in you made for C2 and C3. Is the C3 behavior available somewhere on the web? Else it could be another entry for your lengthy to do list. ^^'

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • brunopalermo

    Nice! I didn't thought about that but it is a much simpler solution.

    Thanks for that!

  • Thanks for the idea! But the capx doesn't seem to be downloadable with the link you provided. :-/

  • Thanks for the explanations. It all makes sense and we now know how to work around it efficiently.

  • Indeed, I'm afraid the wait 0 seconds is mandatory here. I tried your suggestion Ashley, and the problem is still there.

    From what I can see so far, the cleanest way to do this is this one:

  • mekonbekon

    Thanks a lot for your help. At least it's possible to make it look right.

    However, this is still a workaround in my opinion, and it requires checking the animation frame every tick, which isn't optimal. Is the behavior described above the way it is supposed to be? It looks like a bug to me. Maybe Ashley or another Construct guru can confirm if this is intended or not?

    I just tested the capx in C3 and the result is exactly the same in C3 than in C2.

  • Hi everyone,

    I just started to implement separated animations for my characters and their weapons, and I’m struggling to synchronize them with precision, even though they have the same number of frames and animation speed.

    Just run this code with the debugger, and when an attack is about to be finished, pause and advance step by step.

    You’ll notice that the weapon will get into idle animation one frame before the knight, even though the sword is dependent on the knight attack animation to be finished to launch its idle animation.

    If I move the action in event 4 to event 2, launching the 2 animations in the same event, the problem is STILL there!

    The only workaround I found for that is to put a wait 0 action at the beginning of event 4, but I’m guessing this is not the proper way to do that kind of things.

    Even weirder is that, even when I put the wait 0 action at the beginning of event 4, the idle animations are not synchronized. The sword is 1 tick earlier. And if I don’t put the wait 0 action at the beginning of event 4, then the sword animation is a huge 2 tick earlier than the knight!

    Am I missing something here?

    Is there a much more consistent way to do that kind of animation synchronization that I am not aware of?

    Thanks for your help!

  • Thanks once again for the reply .

    After thinking about the various solutions, I started implementing 250 new layouts into my game - one per level, with the different elements that were preloaded on each of them. It's quite some work but it's easier to do than I would have though. Good thing you have implemented a preload layout (by name) into the plug-in!

    Using this method and your preloader plug-in, I don't need any preloader screen and Healer's Quest has close to no load time at all, which is huge!

    Thanks a lot for making this wonderful mm_preloader plug-in!

  • Thanks for replying, everything is much clearer now!

    My next game will sure be thinked differently, but for Healer's Quest it's not possible to have all the object at start of layout. I have only one "game" layout and all backgrounds and enemies in the game are created on it. I'll see if it's still possible to do otherwise but it seems like a lot of work considering the "lag" time for what needs to be created is less than one second.

    I just have a last point on which I'd like to have more detailed explanations: what do you mean by "Otherwise you will probably have to preload both before and after the layout starts."?

    It's possible to preload something before the start of the layout? On the previous layout actually? I thought from your post that this was useless because it would get erased from memory, so I'm probably missing something here.

    Thanks for your help !

  • Hi ,

    I would like to ask you something, just to be sure I’m using your tool correctly.

    Here’s the context:

    Layout 1 has not the object BG1 on it.

    Layout 2 has not the object BG1 on it either, but BG1 is created in the event sheet, on start of layout.

    What’s the correct way to have BG1 preloaded so that I have a smooth transition from layout 1 to layout 2, and no stop at the start of layout 2?

    • Preload in layout 1? (then maybe BG1 is unloaded when going to layout 2 as it’s not present on that layout)
    • Preload at the start of layout 2? In this case does the plugin make a difference from simply creating the object on start of layout?

    Thanks for your help!

  • I'm also waiting for this one. Hope it'll find its way to C3 soon.

  • Also, will those jerky frames on the beginning of layout will ever be taken care off by the scirra? Only construct does that.

    I can't remember on which thread it was discussed, but to get rid of those frames you may try to put all the objects that will be created on this layout on it. Basically put them all on the layout (layout view), destroy them at the beginning of the layout, then create other instances when you need them. That way the new object are already in memory and creating them shouldn't slow down the game.

    If you're doing this already, then I may misunderstand what the problem is.