>

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

> >

>

I mean Alpha/Beta are all fuzzy terms. We did run a private alpha before the beta. We're happy to call it a beta. Expect rapid improvements.

They didn't used to be fuzzy terms . Beta used to mean feature-complete with some bugs, and it doesn't feel feature-complete right now. I think the biggest issue with what's publicly available for C3 is how locked-down it feels, even compared to the free edition of C2. Some of the usability seems a step down from C2 as well. I'm sure it will improve over time. Right now it's a bit underwhelming to say the least, though I'll admit part of that is because of the lack of third-party plugin support (currently) that adds features that I've found to be absolutely necessary to make Construct a complete and functional development tool (raytrace, canvas access, some filetype import options, etc).

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