> I'd be willing to bet most people here use Construct in spite of it being html5 than because it is html5. I'm here for the event system.

>

It must be easy as a customer to ignore the practical realities of software development. Honestly, the whole reason the event system is so good, is because we've never been bogged down by multiple codebases. Think about this: we're doing better than most other non-programming tools, some of which even have native codebases and make a point of it. Some have had up to 10 times as many employees, even. Why don't they "just" make the rest of the tool better? Because their technology choices cause massive development slowdowns.

So I think this is actually completely wrong: we're all here *because* Construct is HTML5. Everyone can gripe about various aspects of HTML5 - no technology or set of technologies are perfect - but until you actually work on such a big software project, you'll probably never understand just how unreasonable it is to imagine that we could "just" have the same product with alternative technologies, or anyone else with multiple codebases could "just" make their product as good as Construct.

I'd say the event system is the main reason. Not having to worry about integration or initialization of various components, HTML5 or not, is the main selling point to me, and I know how to do those things in HTML5/JS, Flash, etc. You're overselling your decision to use HTML5 as a basis for C2. HTML5 was a nice bonus, because I know what's possible with it, and C2 has some shortcomings compared to what the technology is capable of. Until the rewrite, those shortcomings will also effect C3.

It is what it is. You're being snippy with your customers right now, but criticism is not necessarily a personal attack or inherently negative. We're not all Lamar, looking to get banned, and I never would have okayed use of Sombrero as a showcase for Construct if I didn't believe the product has the potential, as yet only partially realized, for a long and bright future.

As for solid products with multiple codebases, built by small teams: I started using Unity when it went cross platform with v3. At that point, it supported Windows, OSX, Linux, Android, and iOS. So it is possible - they were not a large team at that point at all. To run in a browser, they have to write their own plugin - a problem you don't have to deal with, which is good for both you and users of your products. But these days they're doing some pretty interesting things with WebGL/HTML5, and have 3rd-party plugins that allow event-like and node-based development. Just something to keep in mind while you're commenting on Construct's abilities and the benefits of basing it on HTML5. To be clear I'm also not using Unity as an example to suggest that you should work on adding 3D support.

"I can't believe Scirra chose a HTML5 runtime instead of Flash. It just doesn't make any sense. Everyone is doing everything in Flash so obviously that was what they should have done. Also they have started charging money when Construct Classic was free, especially when C2 is so early on at this stage of development compared to CC. Obviously this will drive away users. I think I'll choose another tool. HTML5 also only runs in Chrome and Firefox right now so it seems needlessly limited, and we don't know if other browsers will ever support it. It seems like it was a desparate afterthought. It's sad to see Scirra making such crazy choices. It seems like they'll just fade in to obscurity to be overtaken by other tools. Too bad they're doomed."

- Everyone in 2011

I wasn't here in 2011, and I'd have disagreed with that statement then, as someone who was already transitioning away from Flash in my professional career-related work.

It's also entirely unrelated and dismissive of my statements above, and ignores relevant concerns. Yes, believe it or not, some Construct users aren't just ignorant hobbyists expecting the world for cheap, or asking for features they'll never use. So maybe don't do that.

The default preview window size is meant to be the viewport size exactly, but if you're on a high-DPI display there's probably this bug that affects it: https://bugs.chromium.org/p/chromium/issues/detail?id=677381

This hasn't been my experience with the C3 beta on multiple brands of normal DPI monitors (and high DPI is basically unusable on an SP4 because of text size being far too large). It seems to be taking the title bar of the preview window into account when setting the initial size for the window, and if it's resized, it doesn't self-correct to to the proper size when preview is restarted. I also see no way to set a custom preview window size as requested in my OP to more quickly & easily preview different resolutions during desktop preview, which would be extremely useful.

Yes, I understand that, but why? Why tell your user base that had all those expectations about a new program "here is C2.3, rent it for an undetermined amount of time (the first year is only 50$), and eventually a desktop version (that will be able to save your files to disk) will come up, along with a brand new run-time, which in turn will probably bring new, exiting things to C3 (yet sometime later)!".

Why not announce C3 and start sales when the new run-time is ready, and spare the users the wait and see (while renting), I just can't understand this approach...

I've wondered about all of this too. It seems pretty backwards. Subscriptions kind of kill off most hobbyists. In the end I just decided they've shifted markets and are going for the educational dollar, not the developer dollar. Unless the new runtime is a lot farther along than they've announced. In which case waiting to release anything may have been better instead of a half-measure that breaks everything, and then will break everything again when it's updated at some unknown future date, so that's probably not it. It certainly makes any kind of long-term development plans by users unrealistic.

¯\_(?)_/¯

I wonder though, is this vague development road-map attractive for the professionals here? How can you plan your next project not knowing when and if the tool will carry its weight and what the technology will bring in the future? I've always felt like Construct was the tool for the days to come, not for the present, and this feeling is more evident nowadays, with the introduction of C2.3 (not C3 yet...)

No, it's not attractive even in the slightest at this point. It's 2 steps forward, a few hundred or so back. We'll see what the future holds, I'll be keeping my eye on C3, but as of now I wouldn't even consider a purchase/subscription, half price or not. It's nowhere near ready for prime time.

I don't believe c3 will be usable by serious devs for at least another 2 years - runtime re-write anyone?

I have a similar feeling, but for different reasons- They are using the latest browser tech which isn't supported across all devices/computers. So it might take a couple years for everything to balance out. It's a good strategy for Scirra if they want to get a headstart, but I think it just means that for a while it's going to be messy.. Not everyone is going to have the right setup to use C3.

Agreed, though the issue extends past people being able to use C3 to make games - it extends, to I think a greater degree, to people's ability to run games made in C3.

C2 wasn't capable of anything past a simple, low-end, highly buggy games for the first few years of its existence, but that was a LONG time ago in game dev tool years, and I have strong doubts any users will be willing to put up with those kind of issues these days in any substantial numbers. Certainly not enough to encourage buying into a subscription service.

So it's C2, if you're willing to deal with potential consumers not being able to run games on hardware that runs output from other engines just fine, with serious limitations on what platforms Construct-created games can run on, or switching engines. It's not realistic to expect users to wait years for a product they're paying for/subscribing for to hit a point where it's usable in commercial products. Even then, there's a strong chance it won't perform as well as other engines that are much farther ahead in terms of features and performance. Repeated, easily disproven claims that Construct can run as well as native apps doesn't help engender any real trust on the part of users towards Scirra, either. Misleading claims of what "benchmarks" show just makes it worse.

I can't really imagine how anyone thinks C3 is ready for prime time at this point. It needs months or potentially years more work before I'd consider it worth paying for. Even compared to C2, it's just so far behind where it needs to be. Maybe after the engine rewrite, which is really what should have been launched to begin with, and definitely after plugin support is full-featured and we see the more useful stuff come over from C2 that allows the kind of features a game engine should be expected to have.

> I feel your are right: even the performance of a simple platform game (Kiwi) is very underwhelming on a i5 machine with 4gb.

>

Please provide actual benchmark numbers, otherwise this kind of statement is worthless.

My office machine can render over a quarter of a million on-screen sprites at 30 FPS in Chrome, so you can get great performance in a browser. A single actual measurement is worth more than an entire forum full of vague statements.

This argument would be more valid if 30fps was the target, possible to achieve steadily, or possible to lock a game at. With an entirely variable framerate, and with the default (and uneditable) target being 60, this doesn't really mean anything, as a performance benchmark or for what's possible to achieve in a commercial product. Wildly varying framerates, which is what we currently have to deal with any time a Construct project drops below 60, looks like absolute garbage and is a great way to get lots of complaints from anyone who purchases a game with a variable framerate. We don't live in 1996. Slowdown and frame drops aren't expected 20+ years later in 2D games.

This is of course aside from the suspension of disbelief required to refer to 30fps as "great performance in a browser" on even a mid-range desktop PC with a decent GPU for a strictly 2D project. An "actual measurement" would hold more value - or any value at all - if it were based on usage more related to real-world performance. Which is exactly why performance-related benchmarking tools use real-world scenarios instead of (or in addition to) just spawning a bunch of static objects and calling it a day.

That said, Kiwi Story seems locked at 60fps, unless the debugger is open and updating all the stats on the default tab (that we can't switch off of in the free version and it heavily impacts performance) so there may be some other issue going on here than anything C3 or Chrome is causing. Memory usage hovers around 160MB if C3 is launched from a desktop shortcut with no plugins enabled, and that looks about right and is less of a memory footprint than I'd expect from Chrome by itself.

I noticed that the preview window when C3 is set to preview as a popup doesn't go to the proper viewport size. This made me think that it might be handy to allow developers to set the preview window size so that it could be previewed 1:1 with the viewport size set in the project (if that will fit at monitor resolution). Being able define a specific size would be useful for testing cases where multiple screen sizes are being developed for, like desktop previewing of aspect ratio differences between mobile devices, or if a web game is being developed at a lower resolution and scales up based on window size so devs can test to make sure graphic assets have high enough definition to support higher resolutions. We can drag the window but we don't really get any feedback on correct size and can't currently set the size with actions.

Best-case scenario would be having a dropdown with common resolutions in the Project properties panel, and some way for C3 users to add their own as needed, that can be used for setting preview window size. The Viewport size defined in the Project properties could be the default option. And if it's in an easy to reach place it'll be faster to test multiple sizes.

Sorry for the delay, been in personal hell recently but have now emerged.

My thoughts on this are based on an older build, installing the latest now, but what I wondered was if it was possible have a system by which we can create a separate logic tree dedicated to dialogue and be ableto trigger segments of this, rather than draw text objects to the screen and hide them for triggering in an event later. The last I tried this, I was making a merchant screen and was drawing text to the screen for every item the merchant sold, manually, and it was rather cumbersome given I'd have to do it for 40+ planets.

Installing the latest C2 build to have a poke and see what else I can do to accomplish what I had in mind, but that is what I was thinking of.

It's possible to put together a dialogue system with events that can be used for each of those 40+ planets - there's no reason you should have to create a unique dialogue with events for every single one individually.

Collision filtering would be good. Collision filtering by tag would be the best.

> Salty!

>

For anyone who missed the context, Lamar was back posting accusations that we're a scam company. Was willing to reconsider his ban at end of beta but not anymore. He's permanently banned now, account and IP address.

FINALLY. Thank you.

Ashley

I'm happy to manage spritesheet images myself and all of the memory issues that may arise from it if it means no seams, which I emailed you about a couple months ago, and I ended up implementing image loading myself separate from C2's spritesheeting with no issues and lower memory requirements than I had before, though I think what you're suggesting with image limits on desktop PCs is not, generally, an issue in most desktop games. The best solution (from a dev perspective) is to allow users to create their own spritesheets, even if they have some position/rotation/scale/limitations to work properly with Construct. Put simply, other software does spritesheets better, and it'd be nice to be able to update a single spritesheet that can keep collision shapes instead of having to re-import a spritesheet, have C2 split it up, and then have to redefine proper collision for each sprite. Even though C2 supposedly creates "optimized" spritesheets, I haven't found that to be the case and to shrink file size, I tend to find myself running all exported PNGs through PNGGaunlet which can reduce the size even further, with some images compressing another 90%. Yes, I know this doesn't affect memory usage, but it is a missing optimization for size on disk and it can be a bit of a pain to have to do it after every export because C2 may create differently-organized spritesheets if any images have changed due to re-import or additional spritesheet images being generated if more content is added.

As for working exports: we're not really presented with much info on export, and I've had issues where one export works and another done minutes later (for testing) fails on startup (red loading bar, for example) doesn't work, even though I may not have made a single change in either C2 or to whatever nw.js version I'm exporting to. Believe me, if I could figure out a way to more clearly report that issue, I would do so in a second.

Also, while it's good you won't defend a 4yr-old blog post that isn't accurate, it'd be even better if you walked back claims that WebGL performance is equal to that of OpenGL/DirectX, because at just the base level of that claim, the idea that a graphics functionality wrapper on top of another graphics wrapper is as fast as a single graphics wrapper is...well, it's just silly.