I have to wonder why would Scirra tease us for months with so many new features and then release a beta where almost all of these new features are locked. I understand that Scirra wants to test and fix all the basic features first, but why even start teasing with the new features so early when in reality they are months away?

I tested out everything I could think of with the available features. I made a few test games and tested out cloud saving support. Everything worked well for me and I didn't encounter any problems. The editor itself looks and feels almost identical to C2 editor and I really like it.

Having to right-click is a big issue for me as well. While it seems like it should be simple, I'm so used to using shortcuts that I hardly ever touch the mouse in C2. Having to do so just slows things down. Take into accout that OSX requires a two-key combo to right click and it becomes an even bigger workflow roadblock. There seems to be a number of features that take more clicks than they should right now, and from the outside it looks like those exist to work around issues with having a browser-based IDE. Not a great sign, tbh. As for the features, yeah...don't sell me a bill of goods and then not provide the goods.

What's been released as the C3 "beta" is very obviously an alpha. And that's fine, but mislabeling it (not to mention putting such a hard limit on accessible features) means that, even for just messing about with it, it's not entirely worth the effort right now. Hopefully we see an actual beta in the near future, prior to the release of the commercial version. Right now it feels very...meh. I'm not excited by C2 in a browser in the slightest, especially since right now it seems to be more an inconvenience than an upgrade. I guess we'll see what happens!

Wow... This really looks beautiful. It would be so nice to actually know how to do this. looking forward to it... there has been any advance?.

Ashley fixed a bug with canvas resizing affecting collision cells in a recent beta (I don't remember this being mentioned in the beta, but it's working now when it wasn't before) so I've been playing with it a little bit. It won't work in C3, at least until if/when Paster gets ported, and I doubt I'll dig too deeply into adding the features I'd originally planned before C3's worked through the issues that are popping up in public testing.

Construct 3 is built for now and the future, using bleeding edge features.

I would also argue that an organisation not allowing updates to browser is a pretty backwards security policy. Unfortunately you'll have to wait for them to allow updates.

You'd be making an unrealistic argument. Larger companies, especially those with security concerns, are typically at least a few versions behind. Every update to every piece of software is vetted by internal IT teams at larger companies and just about every school I've ever worked at or been in. I've worked at places that were many versions behind with Adobe's CC suite for this reason, and while it's obvious not many people are going to hack a computer through Photoshop, it's still a concern for places with organization-wide IT policies.

Jayjay

Thanks for your input, but I'm already aware of these. Maybe I should have been more specific when I said "competition". Blurymind has consistently pointed out CTF and GM as being C2's competition. I'm just curious to know what he thinks those specific engines have, from a technical standpoint (ie., usability, features, etc.), that's better than C2.

But again, thanks for pointing those out.

From a technical standpoint, C2 is not the best choice if you want larger games that perform reliably well on mobile or console, because of the technology it's based on and mobile/console support of that technology. If your target is desktop only, C2 is fine. Not being able to export natively, and use native libraries directly (OGL, DX, etc.) is a huge issue, and makes it near impossible to predict performance across a wide range of devices, which is especially relevant on mobile. If you're doing puzzle games or runners, on mobile or web, C2 is fine. Bigger stuff? Sure, it can do it, but as soon as anything hits the rendering pipeline, even without layering on lots of shaders, effects, or particles, performance of C2 is god-awful. This may not even be a limitation of C2 itself (some definitely is, but not all), but since it's depending on 3rd-party wrappers to do, well, basically anything other than a game on a website - and even then, it has to depend on the browser's rendering tech and javascript execution speed - it quickly shows itself to not be the best choice. For example: it's exciting that (at some point) C2/C3 may support XB1 export, but Edge currently sucks at any kind of even basic shader/effect support; throwing a handful of tinted objects or, say, objects with a Multiply or Screen blending mode, and it dies a horrible, stuttering death. Which, since I use these in Sombrero, means Sombrero probably won't run very well on XB1, even though it's not REALLY doing anything that's complicated at all on the shader/effects front.

Is C2 the easiest and most flexible to use for 2D games, if you're looking for an engine that is specifically 2D? Yeah, probably. If you want to create something of high quality that can run on multiple platforms, across a range of consumer devices, and doing so with the performance expected by consumers? Not so much. Using Unity's 2D features would be the way to go, even if some of it feels super kludgey and somewhat tacked on top of Unity's 3D engine.

You can install Git, node.js, Java, Cordova and the Android SDK to build locally without having to upload anywhere:

https://evothings.com/doc/build/cordova ... ndows.html

https://cordova.apache.org/docs/en/latest/guide/cli/

https://www.npmjs.com/package/cordova

Can you post a screenshot of what you're seeing? I tried your capx but it's working fine in r243 for me, and I think this latest beta fixed an ugly kerning issue with spritefonts.

digitalsoapbox

I see the issue. The ObjectRefGID is the raw value, but in order to extract the frame ID, the plugin also needs the 'firstgid' parameter from the Tileset because the frame number is relative to the tileset being used. IE: frameNumber=TilesetFirstGID-ObjectRefGID.

As the plugin currently stands I think rexrainbow might need to add the retrieval of the Tileset's 'firstgid' parameter in order to extrapolate the frame number. Sorry for getting your hopes up, but hopefully, Rex will pipe up.

In the meantime, Bjorn, the Tiled developer (am I right in assuming you are using Tiled), doesn't recommend using Tile IDs to reference tiles in a tileset because they are 'volatile'. I had to agree with him because I found out in my situation, I could not reset certain tiles to start at 0 within Tiled. For example, in one of my tilesets, the first tile's id is 3, and there are some the skipped a number. And so referencing them in C2 was yielding incorrect frames even though the tile ordering was identical.

The only practical solution for me was to apply a custom property to each individual tile assigning them a frame number. I think this a much better solution as it is predictable. Also, it is also possible to parse the TMX externally that will procedurally make the correspondence between the TMX tileset and the animation frames in C2.

Lastly, I have modified Rex's code specifically for this 'Image Object Tile ID' requirement, but I have not requested Rex to 'pull' my modifications as I think it's better for Rex to maintain his plugins. If Rex allows me to post modifications to his code then I'll do that here.

But again, I personally have abandoned the idea of using Tile IDs for frame numbers mainly because they're not dependable.

I haven't had an issue with using tile IDs for animation frames so far. I'm using TMXImporterV2.Frame for tile objects and it works just fine. I also started with a set size for tilemaps using a single image in Tiled, so maybe that's why it's working for me. Either way, I sure would like to be able to get the tile ID for objects so I can optimize collisions a bit more .

digitalsoapbox

Rex PM'd me about a TMX Importer V2 update but it seems he had forgotten to update this thread.

Here's a direct quote from rexrainbow

> Please update tmx related plugins.

>

> Add new expression:ObjectRefGID to get reference gid of an object, and extend expression:TilesetName( gid ) to get tileset name of a specific tile (gid).

> ex : TMXImporterV2.TilesetName( TMXImporterV2.ObjectRefGID )

> Hereis a sample capx.

>

The 'gid' is what you're looking for. It's basically the 'frame number' of the Object, as it were.

I also believe that Rex updated only the one in his main site, not the Github one, last I checked.

faulknermano rexrainbow

Thanks! I'll poke around with it and see if I can get it working.

This works to set the animation, but what do I need to do to set the animation frame? I'm getting the right tileset name to reference for setting the animation from TMXImporterV2.TilesetName( TMXImporterV2.ObjectRefGID ), but not a tile ID to reference as frame number.

digitalsoapbox

Bit of an old thread, but I just noticed this and saw that you are iterating through TMX Objects (not Tiles). I had mention this to rexrainbow recently about adding support to reference Tileset-related parameters for Objects. At the moment, if I'm not mistaken, only Tiles properly reference their Tilesets. In Objects (and in Tiled, that's the Tile Image Object), the plugin is required to make a connection with the 'gid' parameter to the Tileset.

Anyway, I was wondering if you solved your issue and how.

(For personal use, I modified Rex's code and got Image Objects to reference their frame, but I think Rex might be doing his own modifications, if indeed what you're experiencing is rooted in this.)

I missed this comment originally. I still can't get the correct frame from objects using this importer.

I already have it set to that.

This isn't a bug, it's because you're using point sampling and whatever the original size of the sprite font is can't be divided evenly when scaling it. Though in your example, it's scaling just fine because it's using letterbox integer scale.

Problem Description

Performance drops a little in FireFox and dramatically in Edge when using included shaders that effect color and blending. This seems to have more to do with the way the shaders are working than the size of any objects on-screen in relation to overdraw - without the shaders, performance is consistent and greatly improved. This issue appears using only the shaders included with C2, no 3rd-party shaders. This could possibly be related to browser differences but I wanted to report it because performance is so different in Edge and this may impact anyone who ports to XB1 when the ability to do so is officially released, and I definitely remember this not being an issue the last time I tested in Edge around 6-8 months ago.

Attach a Capx

https://dl.dropboxusercontent.com/u/14245368/performanceissues_colorblending.capx

Description of Capx

Creates 75 randomly-tinted sprites & changes their blending mode. Randomly chooses between Screen and Multiply blend modes on each sprite, then turns off the shader that isn't in use.

Steps to Reproduce Bug

• Launch Capx
• Launch in Chrome, FF, Edge
• Observe performance in debugger

Observed Result

Low CPU usage/high performance in Chrome. Higher CPU usage/Draw Calls but high fps in FF. Much lower performance in Edge, and if for example a single additional layout shader is added (eg the noise shader included with C2) performance can reach down past 10fps on a beefy PC. Maybe something broke in Edge?

Expected Result

Better performance with standard shaders. A further example can be found here from which the .capx is derived: http://fars.pixelmetal.com - go to the map screen and compare draw performance in the browser debuggers in Chrome/Edge.

Affected Browsers

• Chrome: NO
• FireFox: YES, somewhat
• Edge: YES

Operating System and Service Pack

Win10 1607

Construct 2 Version ID

243

Frankly I'm just confused now. The thread seemed to start as having concerns about how to import spritesheets. I think importing over the existing animation frames from a spritesheet is a useful idea. Beyond that, I'm still not clear what you want.

Those screenshots you showed look exactly like what the importer would do. You set the cell sizes and then the editor knows what individual frames are. Whether or not it displays the entire spritesheet in the editor doesn't seem particularly significant to me - why is it useful to see the rest of the frames when editing a collision poly, for example? What does that make possible that was difficult before? It seems fine to just edit that kind of thing frame-by-frame. That seems like a useful view to see when importing a spritesheet, but once the editor knows what the individual frames are... what's the benefit of still treating it like a whole spritesheet?

Also as I said before, if you force C3 to use an unmodified spritesheet, it effectively is a deoptimisation. You also can't do things like "crop all frames" which allows for a much tighter automatic spritesheet packing which saves memory, and also actually decreases the GPU fillrate which improves rendering performance. Your screenshots could probably save at least half the space, since there's a lot of transparency there. And with other images there could be issues with color bleed. So as far as I can tell, a better spritesheet importer would solve your problem and not have any significant downsides. Am I missing something?

The issue may be the optimization being forced when the user may already have constructed an optimized spritesheet. There's also the question of whether such optimizations are really need in a desktop environment where saving a few MB isn't all that big of a deal. Being able to easily update a spritesheet and having C2/C3 import it without wiping out collision shapes, or being able to turn off what are occasionally problematic optimizations that end up causing seams in sprites, would be a big step forward in the way Construct handles spritesheets. It's also possible to manually process images through sometime like PNGGauntlet to provide more optimization (of file size on disk) that Construct provides, and currently this optimization is lost when importing into C2. This optimization can be re-applied after export, but this can be time-consuming when a lot of images are in use, and it has to be done every time.

In terms of seeing the entire spritesheet in-editor, this could be useful for users to ensure that they're using the most updated spritesheet visually, instead of having to, for example, go through every frame of an animation to make sure they're all up to date. It's a quality of life feature.