How do I use extremely large animation files?

Post reply
0 favourites
From the Asset Store
Ninja pixel art char w/ animation
$2.49 USD
Ninja char for your game! Make your own Shinobi game with this art.
abdelhc's avatar
abdelhc

  • BadMario

    That's what Families are for. Put your characters in a family, then all your events can reference the family but affect the picked character.

  • So if instead of having all of them in a single sprite, I create 12 sprites ( one for each character ) and add this to a family, I can create only the selected one and destroy the other characters/sprites in the family, and that will not be in RAM any more?

    And still be able to use a single event for all characters such as: on click Family > play animation hit

    If that works, I already have a game that could maybe use it

  • davioware.com/Q3Dplugin.php

  • Thanks dop2000 that's exactly the kind of stuff I'm looking for. That Pre-Loader was what I was thinking about, just couldn't for the life of me remember what it was.

    I looked into Q3D a couple of years back newt, when I first thought about using 3D models rendered as 2D sprites. I thought it would cut out the middleman so to speak but I just found it impossible to use and very hard to find good tutorials or documentation for. I'm not sure it's a good fit for a Beat Em Up style game but if anyone knows any good guides for Q3D I would be willing to look at it again.

  • blackhornet Thanks for the tip. I've only used Families so far to apply effects to groups of objects

    Sorry if this is like a partial hijack , but this may help the original poster too..

    After BlackHornet's suggestion I did a couple of tests and this may come in handy.

    My game does not have nearly as many image sequences, but enough that it caused RAM problems on phones.

    I solved it by optimizing everything and was able to keep my original set up, but in the future I may go with that Family route.

    To some of you this is probably, duh!! an obvious thing, but may help others.

    So, if you have too many images these would be important points:

    #1 Having all your sprites in one layout ( layout you actually use in your game ) is a no go, too much RAM usage and probably a crash. Even if you destroy them on start of layout it's a no go.

    #2 So they have to be created as needed with System > Create Object, but that means they have to exist somewhere in some layout in the first place.

    #3 Creating a layout that exists for this purpose ( to hold all sprites ) and never actually going into that layout seems to work. If you actually try to go to that layout, again, probably a crash because too many things loaded into RAM, but since they exist there, you can create them in all other layouts as needed

    #4 Possible issue is jank, because when you create them during gameplay, they need to be loaded into RAM which is not instantaneous. One of the reasons I prefer to have everything pre loaded and ready. Same with music, yeah it streams, but if connection stalls, can cause game to stall too, so I prefer to use music as regular sound and pre load as well.

    That MM pre loader plugin helps with that

  • Thanks BadMario those are essential points (& in no way a hijack, these are all useful things to note in regards to this topic).

    So I built a test. I made a copy of the Beat Em Up project I've well underway (which contains a fair few sprites already but only weighs in at around 25MB on disk),then I loaded it with a 18 individual sprites at 200px² each containing a whopping 160 individual animations at 35frames each. That's a ludicrous 100,800 image files. All pre-loaded in the first layout (I've not used the MM-Preloader plugin yet).

    So on disk this is a huge 6½GB. Construct takes about 2 minutes to save/autosave the project each time, & on top of that all browsers I've tried just crap themselves & crash when I try to run a preview.

    However when I export it, after brute compression, the NW.EXE for windows only weighs in at 94MB. The game loads almost instantly & runs fine. I even put in a test key to spawn different character sprites again & again. I had like 30 of these massive bastards on the screen all playing a looping animation & the game seemed to run with no problems.

    I figured my PC was just powerful enough to chew it up & spit it out, so I tried it on my crusty 10 year old iMac. Even though the OSX export was twice the size at 196MB, Steve Jobs old paperweight still loaded the game almost instantly & run it with no problems, even with a butt-load of sprites getting spawned onto the screen.

    Finally I tried it on this crappy old tablet I found. I have bricks in my back yard that have more processing power than this thing. I ran the 32bit windows EXE on it & even though it was a little slow it still run ok, if not great.

    So the real problem here wouldn't be exporting & distributing the game it would actually just be working on it, as Construct will not preview a project of this size. I guess if I just build it gradually, piece by piece, this isn't going to be a huge problem? Any ideas for improving the creation process are welcome.

  • Wow, that's really encouraging! Did you test how much memory your game was using - for images in Debug Mode, and overall RAM in Task Manager?

    Check out the animation loader addon, it may help with the development stage. As I understand, it will allow you to store all images on disk and load them into sprites on runtime. This will keep the project small. When you are ready to release the game, you can import all animations into sprites.

    EDIT: Are you saying that the exported game size was 94MB? This is not right. It means that Construct has removed all duplicate images. Or was that the size of NW.EXE file only?

  • Thanks dop2000 I dunno what we'd do without Rex Plugins.

    In regards to your Edit: the full Win64 folder is 141 MB including the NW.EXE.

    Not sure how I can run a debug since the project is so large any browser I've tried crashes on preview.

    These are all seperate cloned sprites with 160 individual animations of one of those bouncing idles everybody does in fighting games. All those animations are duplicates though. Are you saying that Construct's Exporter is smart enough to somehow detect that these images are identical and remove them? Even though they are in different sprite folders?

  • Are you saying that Construct's Exporter is smart enough to somehow detect that these images are identical and remove them? Even though they are in different sprite folders?

    IDK, but it's very unlikely that it could export/compress 6GB project and 100.000 images into 141 MB game.

  • FYI Construct 3 may well be better suited for this. Firstly the C3 runtime handles image memory much more efficiently. IIRC the C2 runtime always holds all compressed images in memory at all times, so you pay a memory cost for images even if they're not loaded. The C3 runtime avoids storing them in memory at all until they're really loaded, which can save tons of memory for large projects. Secondly the C3 runtime has built-in features to load and unload images for objects which helps manage the memory usage within a layout.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thanks Ashley it's definitely something I'm considering. I've built most of the game already in Construct 2 and it's fairly complex. How easy would it be to copy a large amount of Events from C2 to C3 (I don't believe I've heavily relied on any 3rd party plugins yet)?

  • Construct 3 can directly import C2 .capx files.

  • C3 runtime has built-in features to load and unload images for objects which helps manage

    What does this exactly mean? I could not find anything. It sounds like I could unload 10 animations from a sprite and only keep the 2 or 3 actually used thuse reducing RAM usage. If this is that, that would be helpful, as I have not found a really efficient way to select between 10-15 teams with 3 animations each, while minimizing RAM usage. Putting them into families only solves part of the problem.

    Also, I had a game that reached 1GB of RAM usage and started crashing. After optimizing everything I could I got it down to 450 MB when exported from Construct 2, 650 MB when exported ffrom Cinstruct 3 as runtime 2, and 850 MB when exported as runtime 3

    As a result that game will not even open on most phones if exported via Construct 3. You see the loader layout and as soon as it goes into team selections it crashes ( triead a few iPhones and Galaxy S6 with 3GB of RAM, all crash ) Construct 2 export, being "only" 450 MB works

  • Look at the memory management system actions. They're only available in the C3 runtime. There are also new spritesheeting project settings to help control memory use.

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)