Ashley's Forum Posts

  • What waits? It shouldn't wait at all - the UI should respond immediately.

  • I'm not sure what you mean. There is no new conversion between pixels/tick and pixels/second. As ever, the pixels per tick is the speed in pixels per second times delta-time.

  • Hmm, I guess it makes sense to move it to the properties bar, yeah. Added to the todo list.

  • You can turn off the animations in settings if you prefer.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
    • Post link icon

    Okay, wow, now a 17 page thread.

    I'm not sure what anyone here thinks we should actually do. We've already announced things like our own mobile app build service and new IAP/ad plugins for C3, so that is on the way. We've got Xbox One support just around the corner. Mobile support from what I've seen is pretty solid with WKWebView and Android 5.0+, all supporting JIT-compiled JS and hardware-accelerated WebGL. Maybe we could tweak the way we advertise certain things. Maybe some people have bugs, or unoptimised cases, in which case please file reports, or send me .capxs to profile for performance improvements (as ever, I always ask, and either get sent nothing, or just projects with silly performance-destroying mistakes, hence my skepticism).

    Do you want us to rebuild the C3 editor? I would go so far as to say that would probably ruin us, and waste a brilliant opportunity. Do you want us to build native engines? I've covered that in this blog with our rationale around that, which nobody ever really directly argues against, there's just vague accusations of how HTML5 is "poorly optimised" or something, which really is not the case given the potency of modern JIT compilers and the native-equivalent performance of WebGL.

    So what have I missed? What do you think we should actually do differently that isn't something we've already covered? If I can't make sense of any specific complaints or clear suggestions on what to do, then I don't see why we shouldn't just carry on as we are - I think we already have a strong plan for the future.

  • It's an array of [width, "characters"], e.g.:

    [

    [6, "ilj"], [12, "oeua"], [15, "wm"]]

    (not real data, just an example)

    • Post link icon

    It's hard to adequately respond to a 6-page forum thread that springs up over the weekend, but I'll do my best. Also these threads often turn in to everyone throwing in their own different concerns and it's pretty exhausting to even try to address everything - often I reply to the OP and then everyone piles in afterwards with "what about X? Y? Z?", and this happens a lot even when I do try to address everything... so anyway, here we go, focused on the OP:

    HTML5 on Wii U: the main problem here is Nintendo's weak support of HTML5. Technically we're under NDA so I don't think I can go in to too much detail on this, but I think by now it's common knowledge that the NWF doesn't support WebGL, and that's really just one of several aspects. It's possible to publish smaller scale games on the Wii U, but larger scale stuff will run in to these limitations. There are similarly-specced mobile devices that can far outperform the Wii U due to having better browser tech. Things like this are really frustrating because they unnecessarily make HTML5 look bad. If Nintendo used modern web support, it'd have been far better. Yes, this is a shortcoming of HTML5 that we get stuck with browser engines like that sometimes. Yes, users don't care whose fault it is and just want it to work. But I honestly think it would have been impossible for us to write a native engine with the size of team we are within the timeframe of the Wii U being replaced by the Switch. In other words, it was that or nothing, really.

    Wider console support: it's an interesting time to complain about console support, because the only reason we don't already have Xbox One publishing (which does use a modern browser engine!) is we've been busy with the C3 launch. See this Microsoft announcement which specifically mentions Construct 2 from early March.

    Wider HTML5 reliance: I would actually credit Scirra's entire success to our reliance on HTML5. Sure, it has some downsides, but no technology is perfect. We've seen other competitors with native tech fade in to irrelevance with limited features and dragged down by difficult bugs and development inefficiencies. I'm actually really glad we went this way. Also HTML5 was laughably bad when we started in 2011 (and some people literally laughed at us for choosing it over Flash). Originally, we never even expected to support mobile at all. Things have come a long way and it's still going strong, so I think HTML5 still has a bright feature.

    I also have to wearily point out again that graphics drivers are a concern everywhere, and we have direct experience of that given we've worked on native tech in CC and the C2 editor. It's actually worse in native than it is in HTML5. It's so bad, it has actually ruined AAA game launches in the past. Most indie game developer's post-mortems I read, when they used native tech, almost always involves some kind of section excoriating the woeful situation with graphics drivers, to the extent they say things like "I wish I just had never even tried to release on Mac because the OpenGL support is so bad". Big companies can usually (even then not always) muscle through it by putting several engineers permanently on the problem, but when you're small, HTML5 probably actually makes this better than it would be otherwise.

    Not listening to customers: this is pretty hard to take, as the original company founder with over 23,000 posts on this forum, as high as a constant 10 posts a day on average in some cases. How many companies can you go on the forum and talk about something directly with the original founder of the company? We try to make ourselves available to customers, and I do my best to read all the posts and feedback on the forum, but it's pretty tough to respond to everything with hundreds of posts a day. I do in fact hear everyone's concerns loud and clear. There's a lot of reasons why we can't always immediately do something, ranging from the technology to overall direction of the company, but I am here, and I do listen, even when that involves quite a lot of criticism. Sometimes even when I explain the case, it doesn't stop the criticism. For example some users hit graphics driver related issues and then say they wished we had native engines; these people would be in for a very nasty surprise if we actually did that! But it's never stopped the criticism, so I think to some extent I've just come to accept that some users are going to be unhappy and won't understand some things we do or the reasons behind it, and that's part of the nature of running a company.

  • Well, seeing as how the earliest available version of C2 was released 26th Jun, 2011, if this can be compared to the earliest versions of C2, I'd say about 6 more years. lol which that's not even considering the fact they will also be working on C2 alongside it.

    The early versions of C2 were far, far more primitive than what we are launching now with C3. r45 came out in June 2011. We didn't add core features like audio support, animations, collision polygons, WebGL support, and more until later down the line.

  • Like I said, regardless of who it matters to, I don't want to add features that break other features.

    Why can't other files be hosted alongside index.html? This sounds like an arbitrary restriction that could potentially break other C2/C3 features as well, so it seems the best solution is to allow this.

  • We intend for the content to work like this:

    Manual - essentially a detailed description of what individual feature does (but with some overviews/other content, e.g. a summary of keyboard shortcuts)

    Tutorials - how to bring together sets of features to achieve useful results

    I don't think tutorial-type content belongs in the manual.

    Also I prefer not to go in to extreme detail in the manual, such as to describe the particular algorithms we use, because it changes regularly. Community knowledge takes years to build up, and I can easily imagine everyone still saying "feature X works like Y" when we changed it to "Z" a year ago. So we try to limit the manual to saying what things do, but not how. From time to time we do blogs going in to a lot of the detail around "how", but then even that changes often - for example there's some old blog posts about the collision cells optimisation, and it's probably 20% wrong by now. The details change a lot over time. Blogs kind of suit that actually because they're more a snapshot of "here's how it works at this particular point in time", rather than a long-standing manual entry.

  • Pressing reload or closing the tab should show a confirmation prompt if you have unsaved changes.

    We do have an autosave feature in case of crashes, similar to what C2 has, but I'm not sure there's a clear way to see what it's saved and recover it yet. We probably need to review that during the beta.

  • but who knows, maybe they had an intern there who they let have a go in the tabs. :p

    No, the tabs are all my fault C2 has multicolor tabs too, and this was meant to be the C3 equivalent of that. But the main thing is our designer Paulo hasn't had a chance to go over the editor UI yet, so it's all programmer-art equivalent of UI design at the moment. We'll get Paulo to look over it soon.

  • If you can't at least put sw.js next to index.html, then it will break offline support. I don't want to add official features that break offline support.

    If you can at least put sw.js next to index.html, presumably you can put a few other files there too?

  • We thought people would be even more upset if we let them build up big projects over several weeks and then pulled the rug out from under their feet and withdrew access to their projects until they subscribed. I can easily imagine the posts accusing us of "holding projects to ransom", "weeks of work held hostage", etc.

    So the compromise is to use the free edition - which should be fine for finding out the bugs, it's already turned up a lot! - and enable the full version for one week later on in the process when C3 should have stabilised a lot.

  • The bars swipe in from the side, and you can keep swiping in again to switch between different bars, like going from the project bar to layers.