Spriter is a great tool, but there are some types of animations that spriter is not suitable for, like prerendered 3d. I think that's what Kronar was talking about.

I never said it was the best way to do it, but it is capable of doing it, with the addition of the ability to define hitboxes and sound triggers in Spriter.

Rotating an image at runtime does not use more image data in memory than if it was not rotated. Rotating an image at runtime does require more work for the gpu than not rotating it, but requires so little any affect on the framerate will only be noticeable on a weak mobile device.

That depends on how it's rotated and how often. If it's rotated in-game by rotating the sprite, then it needs to do that, along with resizing the sprite if the images are different sizes, every frame. Saving memory and still ending up with a potential framerate drop is not exactly a positive tradeoff.

If it's rotated in memory, that makes rotation dependent upon the GPU, and since C2 strives to support non-WebGL accelerated devices as well, chances are it'd have to create a copy of the original sprite, rotate it, then remove the original sprite from memory - which would most likely involve rewriting how C2 handles images in memory, keeping in mind that when not using WebGL it loads all images from the project at once, and the memory spikes that would be caused by rotating images at runtime could push many mobile games over their limit. And that all assumes that HTML5/JS, outside of full hardware-accelerated WebGL, even has the capabilities to do it quickly. Which is questionable.

If rotating images to fit on a texture reduces two 512s to one 512, it certainly does seem worth it (perhaps rotation could be an option if people didn't want to use it to ensure maximum performance on old mobile devices).

That's making an assumption in terms of GPU power, and I'm still not buying that there would be any significant memory savings - while not impacting other areas - by doing so.

Kronar

1. Spriter is an entirely different tool for an entirely different purpose. Please read the entire thread to get a better understanding.

No, it isn't. It can handle spritesheet-style animation just fine.

2. 90 degree rotations are standard optimizations when packing spritesheets. Think 'Tetris', where you rotate the shapes to make them fit tighter together.

No, it isn't, and it's incredibly inefficient to waste time rotating the images at runtime as that would just create MORE image data in memory, not less. We're not talking about 1990's-style hardware-supported sprite rotation, C2 is based on entirely different set of technologies. The amount of space saved is absolutely minimal both in terms of file size and memory footprint. I've NEVER been in a commercial production setting where this was ever considered a good idea, in games or elsewhere.

3. I took the time to thoroughly explain the problem so that the community and project would benefit. I want Construct 2 to continue to improve, I thinks its a great application. It already supports independent origins with each sprite frame so supporting a third a party application would be pretty easy to implement. This definitely takes priority over less useful new features like Spriter as using a spritesheet is a requirement not an option. Every single Construct 2 user would benefit greatly form this, even Spriter users would benefit.

Your information is entirely incorrect, and for someone who's attempting to make a point on optimization, you should probably find out what Spriter actually allows you to do and what a spritesheet actually is, especially in terms of how C2 handles them on export.

4. Let me reiterate by saying that If spritesheets were properly packed, the benefits would be HUGE. This isn't a small gain, or a good gain, this is a HUGE gain.

Really, there would be hardly gain at all, if any, if you didn't purposely leave a ton of white space around your example images. Even under normal circumstances, without that additional white space, the gains would be next to nothing.

5. It would not be uncommon to see a large reduction in file size, very large memory requirement reduction and FPS boost. All this without lifting a finger. All Construct 2 games would instantly gain that, no additional work, all done automatically for you.

Yes, it'd be pretty uncommon, because there's a point where optimization reaches a level of diminishing returns/pedantry that simply isn't useful on modern hardware, from mobile all the way to desktop. There isn't a single reason there would even be single-digit FPS gain. Your beliefs that it would matter seem to come from either a complete lack of how modern hardware functions across platforms or a background in an entirely different form of development than that which C2 subscribes to.

BluePhaze It's all about the scaling. During most gameplay, the zoom scale (in Magicam) is set pretty low - 0.1 to 0.175. I THINK I recorded the video at 720p so that the screen capture on Twitch didn't knock on the framerate too hard. Without video capture running, it stays pretty stable at 60fps/1080p on most desktops, though as I mentioned previously on Intel laptop GPUs it seems to have a bit of trouble about 720p unless I drop the Paster resolution to 50% of the level's pixel size. My target is node-webkit, though it seems to run fine in Chrome when I've tried previewing it in Chrome. On Windows 8 on a tablet, IE11 performance is actually better than Chrome's, probably because it's been optimized to run on the newer ARM CPUs and Chrome hasn't (as far as I can tell).

iceangel Never heard of it, but I'll check it out!

Softloulou Thanks!

Beaverlicious I'll be doing some form of alpha testing starting in a month or so. I'm in the middle of adding in the additional player character choices, now that we have Spriter character map support in C2. I also want to get at least one more stage map in there for testing.

BluePhaze

1-Layout size is 640x360, and scales up to whatever monitor resolution. All of the gameplay is based off of the 640x360 size. The actual STAGE size clocks in a bit over 5k, but the camera zooming & scaling keeps most of it contained within the layout.

2-Magicam. It is such a blindingly awesome timesaver to use.

3-Final release will allow one player to use a mouse, but the others will be locked to gamepads. Controls are twin stick + a jump button, and that'd be really awkward with lots of people on a single keyboard.

4-Shaders are WebGL, for the smoke particle effects mostly, so they blend together nicely. There's also some newly-added shader-based distortion effects around the explosions (that's why the ladder is warped in that last screenshot post). Any tile without interactivity is pasted into a Paster object, so that's also pretty WebGL-heavy.

Interesting (to me, at least) WebGL stuff:

Loading times still stay pretty low at a few seconds on initial stage load, though loading speed, and pasting a few thousand objects on stage load, seems to be entirely tied to the speed of the GPU, so those with lesser GPUs may see a longer loading time. Testing on a GTX460, loading time increases, but it's still only around 10-15 seconds and performance at 1080p sticks to 60fps. On a GTX770 it's around 3-5 seconds and the fps is whatever refresh rate my monitor is set to, up to the monitor's max res (2560x1440@120Hz). On a laptop-based Intel 4000 loads times are still pretty snappy at 8-10 seconds, but performance drops a bit - 720p is still 60fps but 1080p gets really flaky and varies between 35-45fps. Poor lil fella can't handle it. For those lesser GPUs I'll probably put in some way to turn off some of the eye-candy WebGL effects that don't affect gameplay. Or maybe Ashley will find some magical way to allow us to change the resolution the monitor is running at .

5-Windows, OSX, Linux. Consoles once C2 has support for them. I've started reaching out to my contacts at MS and Sony to bug them to respond to Ashley's requests on how to go about adding said support. Unfortunately most of my contacts at both places are on the PR side of things, and they can be...less than helpful, let's say...when asked about tech-related questions. At one point I considered Ouya, but so far as I can tell that's pretty much a dead console and I have my doubts as to its ability to run Sombrero at my self-required 60fps framerate, let alone a smooth 30fps.

In the middle of more updates like integrating the new support for character maps from Spriter, but in the meantime here's a nice high-rez screenshot of the near-complete "Clampett's Hideaway" stage! Yes, that's the framerate in the corner - C2 is basically locked to my monitor's refresh, even at 2560x1440, and that's with multiple 4k+ Paster objects that the tile sprites are pasted into. That's a heck of a lot of performance there, Ashley!

Hey! Looks like Sombrero got a mention in the indie gaming press after last night's playtest: http://www.bliptalk.org/the-best-of-nyc ... est-night/

Everyone who asked how the game was developed (there were lots of aspiring devs at the event) were pretty surprised when they heard the game was HTML5-based and not Unity3D. Here's hoping my repeated mentions of C2 help more people find out about it!

Quick update - we conducted a Sombrero playtest last night with a group called the NYC Games Forum at Microsoft's NYC offices!

I should've probably mentioned it here sooner, be we also did a live stream on Twitch.TV - you can check out the archived footage here: http://www.twitch.tv/pixelmetal

Unfortunately we had to kill the stream early since it was dragging the framerate down on the test laptop (normally it's locked at 60fps on most machines). Next time we'll stream on a desktop with a beefier GPU!

Almost done squashing bugs, then on to new stages! New characters! New gameplay modes!

distance / deltatime * time

^ That's the equation you're looking for.

Ashley Hmmm... It makes me to think about PNG files without big transparency background would not cause performance drop.

Then don't use PNGs with large areas of transparency. You wouldn't do that if you were keying out any color (there's no reason it has to be magenta), either.

As Ashley said, it's not a performance issue. Technology has come a long way since there was any real need to key out a specific color for transparency. Your phone is probably 10000x as fast as the computers that were around when that was a thing.

I'd really like to see a WebGL effect for rim-lights. A simple additive light from set angle and with freedom to set RGB colors and the effect's radius. Do those terms even make sense?

I second this one. Though would prefer screen over additive blending, which can get a bit extra-glowly. When I'm slapping rimlight on stuff in post for my day job (animation stuff), screen blending always ends up being the way to go.

BluePhaze Well, if he's hitting a web-based database, that's not necessarily a bad thing. C2 makes accessing things like a WP database/SQL, or even a WP feed, pretty easy to deal with compared to more common alternatives.

Djordhan There's no reason C2 couldn't do this, though keep in mind you're going to have to figure out how to parse that data. Is it a web-based or local database? And what database format?

If you're using the platform behavior, all of that functionality is built-in:

https://www.scirra.com/manual/100/platform