Ashley's Forum Posts

  • Construct 2 already closure-compiles the javascript on export, so even when exporting to the browser it should be very difficult to reverse engineer a .capx or any code. (It's easier to get images out a browser, but those are covered by copyright law and generally easier to spot if being abused.)

  • Just want to point out use of MP3 can incur a fee of $2500. You should never even think about using MP3; just go for AAC instead (aka MP4 or MPEG-4 AAC), which is better than MP3 and doesn't have any fees!

  • There are over 2 million pixels on a 1920x1080 screen, which in 32-bit color mode 60 FPS is a bandwidth of about 500 MB/s - not including things like intermediate rendering for effects. You need hardware which can reach those sorts of numbers to do that. It's not specific to Construct 2 or HTML5! If you use Unity, your users will still need graphics hardware that can push those sorts of numbers. And note rendering happens entirely on the GPU, so having lots of CPU cores and loads of system RAM doesn't help, only the graphics chip does. Graphics chips also typically have special pipelines for rendering video, since it's simpler than rendering games (where you have factors like over-draw, shaders and multitexturing).

    BTW in our latest betas we've dropped Awesomium in favour of node-webkit for desktop exporting. Not only is it faster and working better overall, there's also no fee for commercial use.

  • You do not have permission to view this post

  • I only just caught this thread. It looks like it's had some random posts deleted on the first page too?

    C2 is fast superseding Classic in every way. I do think it will exceed Classic in every way eventually, such as having sprite distortion (disclaimer: not saying I'm working on it any time soon, just I'm sure it'll turn up eventually). There's already an API for accessing a sandboxed filesystem in Chrome, but I haven't implemented it yet because it's very much just a Google experiment at the moment and it's not clear if it will become standard.

    C2's architecture is vastly superior, and it's far better written and a lot faster, even than native code on some systems. I know that's not true of older systems, but look to the future: today's devices are the old junk of tomorrow, and fast forward a few years and it will be true for almost everyone. Why think about other technologies when it's clear eventually that will be the case? Something like haxeNME could see us maybe a 5-10% performance increase for 6-12 months work - it's totally out of the question - and in the same time HTML5 technology would probably improve so much as to exceed those gains, making the whole project pointless.

    I noticed recently Classic doesn't work out of the box on Windows 8 (not sure about 7). There's a security update on Windows Update you need to install before it starts up, because we screwed up some of the dependency management. The reality is it's very unlikely Classic will see any more maintenance. The future is very much cross-platform mobile. Yes, there are problems, such as Android's stock browser sucking really badly. But Chrome Beta for Android has amazing WebGL support. You really can get a 60 FPS game on a phone or tablet, with shader effects and all. Android systems are now outselling Windows systems. The market is moving on. Windows-only is dead (at least in exporting - I know C2 as an editor is Windows-only, and we're thinking about changing this in the long term - disclaimer: again not working on this any time soon).

    Tradition changes, and technology moves on. I strongly encourage everyone to upgrade to C2 if you're still on Classic. If there are quirks or missing features or things you miss, post about it in the C2 discussion forum and we can talk about how we can improve C2. We're doing approximately weekly updates, and HTML5, especially WebGL, are getting pretty damn awesome at the moment.

    The way things are going, eventually these forums will fall silent and we'll probably see fit to discontinue Classic completely. We're not doing that now, because it's virtually zero work to leave these forums running and people still use them. But I think it's inevitable.

    If you're worried about C2 being commercial and having a price tag, I would have to point out: the only reason Classic is free is because we worked it in our spare time as volunteers while students. We lived off our student loans. I'm not a student any more, and luckily I get to do this professionally, which is great. But like everyone else that means you have to make money or not do it at all. So I don't think it's unfair. If we had started Classic a few years later, it probably would have a price tag too. So I guess just count yourselves lucky it was free!

  • Pathfinding only uses one separate thread (web worker). The main reason is Javascript doesn't have a good way to determine the number of cores/optimal number of threads to create. Creating too many workers could result in sub-optimal performance, and one thread on a single core machine shouldn't drag it down too much, so it's the only safe number to go with. The majority of devices are dual-core these days anyway so it's probably a good compromise.

    The event system is relatively well optimised: once an instance has been de-selected by a condition, it is never iterated again (not even just to pass over) by any subsequent condition or action. Events with lots of conditions filter down the selected instances efficiently, only iterating those which met the previous condition. This means you can use a really small micro-optimisation of putting the least likely condition at the top, to reduce the instance count as low as possible initially so later conditions have fewer instances to iterate. However you'd better have tried *everything* else before thinking about such small optimisations, your time is far better off spent on things like rendering (as I'm sure you know).

  • I don't think there's anything we can do. It seems definitely to do with either our UI library or the graphics driver, neither of which are our code.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • tanoshimi - it's already separated, the pathfinding happens entirely in grid world then the movement moves smoothly along the grid-aligned nodes that are returned. I have experience with writing separation features from Construct Classic's RTS movement, and it's extremely complicated to pull off in an efficient and realistic way (i.e. objects never drive through each other or wedge too far inside another object). But it's still and interesting problem I want to look at!

  • You do not have permission to view this post

  • There's more information about the Steam build in this blog post: https://www.scirra.com/blog/106/construct-2-on-steam

  • It's because it has to collision check every cell on startup to test which are obstacles. As tanoshimi says that means you're checking hundreds of thousands of cells on startup, so increasing the cell size should help.

  • Hmm, I haven't heard of anyone else having the same issue. Have you installed all updates from Windows Update?

  • tanoshimi - that's a good idea - also added to the todo list. I've also been thinking about features to separate bunches of objects (someone mentioned flocking) but that's pretty complicated.

  • You do not have permission to view this post

  • Added to the todo list.