Ashley, could you please confirm this behavior?

Discussion and feedback on Construct 2

Post » Sat Feb 07, 2015 4:08 am

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...

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?
I got a game that you multiply, breath fire with two heads and brawl foes to oblivion with your clones: http://www.newgrounds.com/portal/view/660664 (use Chrome on Windows for best performance)

My sites:
http://twinblazar.deviantart.com
http://twinblazar.newgrounds.com
https://twitter.com/twinblazar
http://www.pixiv.net/member.php?id=15072448
B
30
S
11
G
11
Posts: 411
Reputation: 8,469

Post » Sat Feb 07, 2015 1:49 pm

From http://blogs.msdn.com/b/oldnewthing/archive/2007/07/18/3926581.aspx:

The first answer is "If you have to ask, you're probably doing something wrong." Programs shouldn't be creating anywhere near ten thousands window manager objects in the first place.


Along the same lines: I don't understand how you could possibly need so many thousands of individual images? What are you doing? Surely there is a better way?

The editor could spritesheet images for preview, but that would be a big architectural change and could slow down preview. And I don't see the point, since needing thousands and thousands of images does sound like you're doing something wrong.
Scirra Founder
B
398
S
236
G
88
Posts: 24,428
Reputation: 194,600

Post » Sat Feb 07, 2015 3:02 pm

I don't understand how you could possibly need so many thousands of individual images? What are you doing?


@Ashley, like we've said. We are doing pixel arts like this: http://probertson.tumblr.com/post/82062 ... animations

If imported to C2, each Sprite object could contain up to a hundred of frames or so. (But with exported spritesheet image, those hundred frames should become just a huge 512 x 512 or two instead. And that is completely fine.)

The editor could spritesheet images for preview, but that would be a big architectural change and could slow down preview.


We have tried some experiment on loading time.

On our project, we tried previewing and see the time it takes from hitting "preview" button to when the game finish loading and play. (If the loading percent becomes red, we just try again until it gives in)

- Preview Chrome: 1:13 minute
- Preview Node Webkit: 1:05 minute

But here's the funny bit, we have tried exporting Node Webkit, (disable minify and image compression) and it took 42 seconds. In addition, when we run the exported Node Webkit, it took only 10 seconds to finish loading.

In other words, it seems we can test our game faster than preview by exporting node webkit and run it right now. And yes, this would also avert the red percent loading error issue entirely as well.

Could the big architectural change slow down preview? With the above result, I don't think so. In fact, in this case, I could just well go with using the faster exported node webkit instead. :D

We have also tried Preview Firefox, and it took 27 seconds...

I see that preview Chrome and preview Node Webkit took the longest on the first 0-20% (loading images perhaps?), but for exported Node Webkit and Firefox, the percent just "zaps" through to 100% in seconds. In fact, Firefox seems to kick the number up the fastest (only 8 seconds to 100% after the percent shows up, in fact). Does Chrome has inferior loading speed to Firefox or something?
I got a game that you multiply, breath fire with two heads and brawl foes to oblivion with your clones: http://www.newgrounds.com/portal/view/660664 (use Chrome on Windows for best performance)

My sites:
http://twinblazar.deviantart.com
http://twinblazar.newgrounds.com
https://twitter.com/twinblazar
http://www.pixiv.net/member.php?id=15072448
B
30
S
11
G
11
Posts: 411
Reputation: 8,469

Post » Mon Feb 09, 2015 8:11 pm

@keroberos

I think Ashley basically just said he isn't going to do this. You can still export and test, which is reasonably fast if you disable minification and set png-recompression to 'none'. On export, you will never hit the image limit since images are spritesheeted.

Do you have an SSD? It's going to be a lot more difficult to work on such a project without one, especially if your are using caproj vs capx.
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Tue Feb 10, 2015 3:03 am

@TiAm Yes I understand. @Ashley will have to go through a lot and I completely understand.

I already got a better solution in front of me, so I am not requesting for any change in C2 any more.

A screaming soul exploded inside me when the project manager requested for a change like this. A simple change from client's perspective could involve lots of gigantic technical changes and outsiders never see the internal technical pain. I've been there done that so I do understand.
I got a game that you multiply, breath fire with two heads and brawl foes to oblivion with your clones: http://www.newgrounds.com/portal/view/660664 (use Chrome on Windows for best performance)

My sites:
http://twinblazar.deviantart.com
http://twinblazar.newgrounds.com
https://twitter.com/twinblazar
http://www.pixiv.net/member.php?id=15072448
B
30
S
11
G
11
Posts: 411
Reputation: 8,469

Previous

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 15 guests