I would like to put using and managing sprite sheets for preview just like exported projects and better sprite sheet management here.

More info:

One more thing, Ashley, I would like to suggest one more thing:

You could pack more frames into a single bigger image. Right now, each animation of each Sprite got its own sprite sheet on export I do have a huge number of 128 x 128 sprite image sheets to accommodate lots of those frames less than 64 x 64.

Could it be done to pack several of Sprites into a single bigger sprite sheet? For example, we could have enemy A,B,C sharing the same sprite sheet image. This way, you won't be referring the sprite sheet by sprite name any more, but instead have a table storing which animation is in which sprite sheet and the locations of each respective animation frame on this sprite sheet.

This way, instead of lots of 128 x 128 and even smaller 64 x 64 sprite sheet images, we could, for instance, have fewer 512 x 512 or 1024 x 1024  instead.

And let's have C2 manage and take care of this when previewing just like I wrote in the previous post.

Sure, given the current design and implementation of C2, this could mean changing things almost inside out. I don't know how flexible, scalable or changeable is your code, so I can't have a say on this. Yet If you can do it, then that is great, but if you can't...

[quote:3lbtdlio] Further, we are confident Construct 3 will be able to import Construct 2 projects, allowing you to easily transition over.

Please design and implement C3 to address the issue above, especially for preview.

No. We do NOT have thousands of frames for one sprite. That is insane. But we do have total number of individual frames for every sprite combined up to thousands. You have seen how games like Mercenary Kings do with their pixel arts from http://probertson.tumblr.com/post/82062 ... animations 

Pixel art is a serious business, and all those frames could be packed tightly into sprite sheets. You have seen that all my 5638 frames could become 819 images. (And could even be reduced further with the above suggestion) This implementation won't only benefit pixel artists but also everyone, as it will reduce total number of actual images required to load.

***** One more thing: you haven't answer the most important question yet:

Does exported Node Webkit need to do something (ex. Some sort of Javascript request or the like that could hit some limit) with ALL images of the project on the initial startup just like preview?

Hi Ashley,

I've tested further. I've tried exporting the whole project as a HTML5 website, and see that with all those sprite sheets combined, I only got 819 "sprite sheet" images so far. This is possibly the same reason why exported Node Webkit can run it fine, because it only have 819 "sprite sheet" images. I have seen that the total number of individual images are 5638 images.

Looking around further, I see https://www.scirra.com/blog/87/under-th ... onstruct-2:

[quote:1ovp95x1] Construct 2 has typically exported object's animation frames as separate PNG files. Spritesheets - a new feature in the latest beta r92 - means Construct 2 now exports bigger images with several animation frames arranged on each.

This implies that for previewing project, all these 5638 images are not packed as sprite sheets. (as seen in the console) Thereby, causing the app to hit the limit and crash in this case.

It might be the implementation choice to leave each individual frame as it is and then combine them later into sprite sheets when exported. But this design choice now is affecting a few people who wish to preview their project with several thousands of small individual images.

Packing multiple sprites into one sheet has been "the way" for all 2D games since the Nintendo NES era. So Perhaps we could change this by having C2 create sprite sheets for these images during preview as well, but save these sprite sheets as a cache so that the next time of previewing, C2 does not have to create sprite sheets unless there are some changes. But I do understand that this suggestion when turn into actual implementation could be a technical nightmare given that the "packing images into sprite sheets" are introduced in r92 for exported projects only. However, if you can pull it off or have a better solution to address this, C2 will be a force to reckon with for us, enthusiastic pixel artists. Not to mention that previewing will be even faster with less number of actual images to load.

Also, Ashley,

1. Mind give me a link to the Microsoft blog?

2. The 10000 images limit means "total number of loaded images at any given time during runtime", and not all images in the project, yes?

3. I haven't reached 10000 images limit yet but I got the error during preview on Chrome. From the link above, this is because of the 25 MB bound limit in Chrome. The error occurs when there are too many requests at once. So is it possible to try do less number of requests at a time, and then proceed to the remaining requests only when the previous requests have been processed? (EDIT: but again, if C2 can manage all the graphical assets and pack them into smaller number of "sprite sheet" images, this issue will likely to not occur)

5. Also from the link above:

[quote:3jmd7v2j] People occasionally report this but I just cannot believe how you could possibly genuinely need so many thousands of images in one project. You must be doing something wrong or appallingly inefficient! Can you explain a bit more about why you need this and why there really is no other alternative than to have thousands of images?

See this artist here: http://probertson.tumblr.com/post/82062 ... animations

See those fluid animation? In one animation (idle, running, shooting, etc), this is something similar to what I am going through right now. Lots and lots of small images for the love of pixel animation. This is only a small fraction of animation used in the game Mercenary Kings. There are a lot more in the game and all those thousands of frames in one project.

But again, my concern is not that I need all images presented at once. Yes, it is ludicrous to have 10000 images at once. In my game, there are only 100-500 unique small images on each layout at once, I am sure.

My concern is whether this is just a thing in preview and could I get away with the exported node webkit in the long run or not?

3. Also, from the link above,

[quote:3fcy9cwj]Windows has a hard-coded limit of about 10,000 images per app

Is it not possible to deallocate and reallocate resources internally programming-wise? I used to write an OpenGL app that can load any image from the given path during runtime. What's the trouble here? From the Preview image above, it's as if C2 need to load all the images.

4. Does C2 apps need to load all images (without loading them as texture into the GPU) initially even they are not required?

Hi Ashley,

I need to discuss about something.

The game I have been making feature graphics in the retro era. The images are small and the the game's native resolution is only 480 x 320 and majority of the images are even less than 64 x 64. I have been watching those memory numbers down below from the beginning. Right now, it is only:

Approx download: 92.2 mb memory use: 72.9 mb

Recently I have seen this error where the loading percentage sometimes turn red in the beginning. I looked around the forums and I see that it is related to having way too many images in the game. Each Sprite object in my game got something like this sprite sheet: http://www.spriters-resource.com/other_ ... heet/8208/ (but fewer images)

While err-insufficient-resources-when-previewing-in-chrome_t118122 claimed that it loaded 10000 frames and encountered the same issue, however I've discovered something else, in my game I've also tried previewing a layout which only have 1 Sprite that has only 1 frame and nothing else, the error also occurred multiple times.

Previewing the game in Chrome and launching up the debugger, I see this:

I checked https://www.scirra.com/manual/183/memory-usage:

[quote:11274wk0]Construct 2 only loads the images for the current layout. This avoids loading the entire project in memory which would be slow and consume a great deal of memory. When starting a layout, all images for the objects placed in the Layout View are pre-loaded. This includes all frames in all animations of any Sprite objects. (In other words, Sprites are either fully loaded in to memory, or not at all - they are never part-loaded.) When the layout ends, all images that are loaded but not used on the next layout are released from memory.

I don't understand. I thought Construct 2 only loads the images for the current layout. But here, all these output from the console show that the engine failed to load images that are not in the layout I am trying to preview, which has only 1 Sprite with 1 frame of size 128 x 128. The event sheet in this layout also does not create any other Sprite or stuff from other layouts. It only wait for 5 seconds before proceeding to another layout. So... why and how do these images come from? Is it because of the preview mode so all these images are here?

I have been testing around and here is what I got so far:

On Chrome, Usually, this loading percentage turn red at around 1-2%. If it did not turn red around at that time, mostly it will be able to load up to 100% and the game will play without any problem. Sometimes it occurs. Sometimes it does not. But apparently, as more and more images are added, it becomes a lot more frequent.

For Preview Node Webkit, when it starts up, it goes 1-2%, it could turn red at this time. If it does not, it load its way up and the game can be played.

I have also tried exported Node Webkits. After hitting the .exe, the loading percentage jumps up to 27% initially and made it ways to 100% and the game runs just fine. I've tried this multiple time, and it never fail to load even once yet. But this does not mean the problem could not occur on exported Node Webkits in the future. In fact, obviously Node Webkits are basically Chromium, just like Chrome. So I expect it to pretty much behave just like Chrome, but right now it does not - it can play the game without any loading red percentage .....for now, it seems.

-----

So here's the thing, Ashley. Could you please confirm the following:

1. For exported Node Webkit (which problem never occurred yet), can I take it for granted as a workaround that I should be able to avoid this dreadful error with it, yes or no? Please give us an insight. While we have quite a number of animation frames, each of our layout never contain more than 500 animated images. (In fact, most of the time, it is only 100-200 images) Also, recall Approx download: 92.2 mb memory use: 72.9 mb

2. Programming-wise, I believe C2 clear up unused textures. I've tested it and it worked. But about the error I am facing here. It's as if during the preview, C2 has to allocate all of the resources for all images in one go for some reason. Could you please confirm this? Or is this some sort of loading implementation in favor of previewing sake? Or is there really some invisible global limit to the total number of images regardless of their sizes for the whole project? (again, recall Approx download: 92.2 mb memory use: 72.9 mb )

If the answers for questions are "yes, I can take exported Node Webkit for granted as a workaround, as each layout pretty much contains only 100-200 images and C2 can allocate and deallocate all the resources without any trouble. It is likely that preview contains some bugs", then I would be happy to use exported Node Webkit to "preview" my game instead.

However, if there is really some invisible global limit, then... this could spell doom to my project that I've been working for 1.5 years...

So Ashley, please confirm.

— Unfortunately, no, but I guess someone needs to dive into the the SDK and play around with the buffer part a bit. I don't know if someone can do that...

int(x) got one problem. If x < 1 (ie. 0.5), it will return 0, which is also the value to indicate that x is not a number. To remedy this, use float(x) instead.

Did you play a sound with a sound tag, then mute this sound tag after a while, then play the same sound with same sound tag? Then, you have 2 instances of the same sound: one mute and one not mute.

Is this the case?

Yes. Theoretically and ideally, there should be no changes for users of C2, and no change in C2 too.

But you never know. All these deep down implementation sometimes have things that may not lock down together when some tiny change is made. Better to test stuff before taking things for granted.

OK, I have tried it. The version in my Chrome is now Version 37.0.2062.94 unknown-m (64-bit).

The space shooter example runs without any problem.

I have also tried my game for 40 minutes or so and it runs just fine. No problem.

Performance-wise, I don't see any difference.

Chrome 64 bits for Windows is released. (not the experimental build)

Check chromium blog here: http://blog.chromium.org/2014/08/64-bit ... 6.html?m=0

[quote:wh3irwbd] 64-bit Chrome offers many benefits for speed, stability and security. Our measurements have shown that the native 64-bit version of Chrome has improved speed on many of our graphics and media benchmarks. For example, the VP9 codec that’s used in High Definition YouTube videos shows a 15% improvement in decoding performance.

So what could this mean for us that use Chrome? There are a few questions on my head right now regarding C2 and Chrome 64 bits.

While the quote above mentioned graphics, it didn't specifically mention webgl or canvas2d. But could it mean that our games would run a bit faster? In fact, how fast? Or is the speed rather negligible?

Also, another interesting question to consider is, will NodeWebkit also have exported version of win64 bits implemented in the near future? There used to be a case where someone requests for 64 bits NodeWebkit here: https://github.com/rogerwang/node-webkit/issues/1320 but since 64 bits is now available - it should be only a matter of time for the node webkit folks to implement 64 bits node webkits on windows.

Glitches and incompatibilities are always the bread and butter of Software development. Perhaps maybe we should grab chrome 64 bits and try run some C2 games on it and see whether all those advertised qualities are really present (and see if some aforementioned quality is really significance) and also to see whether there is anything that needs addressing, whether it's on C2 side or Chrome side. So anybody wanna give it a try?