Ashley's Forum Posts

  • We could implement a Construct Classic-style limited ability to do some basic 3D transforms (e.g. Z height, mesh distortion) but that would require dropping support for the canvas2d renderer, which is about 10% of all devices in use today, while dropping support for non-WebGL browsers (IE9, IE10, old Android browsers). On top of that adding 3D features is a rabbit hole that leads to developing an entirely new product and taking the company in an entirely new direction, which is not something we're keen to do right now.

  • A .capx is worth 1000 posts. If you have a performance problem, reproduce it in a minimal .capx and share that. Then I can profile it and get some actual data on what is going on, rather than just aimlessly speculating. You should also not use any third party plugins in such .capx files (as per bug reports). If the performance problem is caused by a third-party plugin, it's not our problem at all.

  • If you think it is a bug, please file it in the Bugs forum following all the guidelines.

  • Why is this information not in a FAQ or anywhere that is visible? Why have potiential C2 licence buyers, like myself before purchasing C2 licence, have not been informed about this?

    Because I don't think it matters. I don't think it makes any meaningful difference for downloading, installing or runtime performance. What meaningful difference do you think it makes? If it doesn't make any material difference, I don't see why it deserves to be specifically highlighted.

    If you still wanted to distribute on CD then the compressed overhead is under 10%, which seems reasonable. It's about 1% for DVD, which I think it's fair to say is negligible. Your stated estimated final size of 300mb will still fit comfortably on a 650mb CD with room to spare, even including the overhead of NW.js, so I'm not sure why you're worried about this. Still, I was under the impression most of the industry had already moved to online delivery for games - it saves the cost and logistical difficulties of burning discs, packaging them, and making international post deliveries. I'd imagine most gamers are already accustomed to large install sizes too - GTA V on PC requires 65 GB!

  • What exactly is the problem with some large files? Sure, I guess it's quite a large number, but what really is the concern? If you're worried about download size, then you'd be crazy not to compress it, in which case the total numbers are 46mb for win32 and 55mb for win64 for moderate compression (just Windows' add-to-zip feature, so you could probably get it lower with better compression), still not a lot compared to the average desktop game download and not long to download on broadband. For the uncompressed size of ~130mb, are you worried about the disk space it uses up? This is a drop in the bucket for most modern desktop systems, which easily have hundreds of gigabytes of permanent storage. Maybe you think it affects performance? It's large because it's bundling the entire Chromium browser engine, which has generally had the best performance of any browser - file size does not itself affect that. For example modern operating systems are efficiently designed enough to not even read from disk parts of a DLL/executable file that are not executed, and CPU caches are only concerned with the data that is actively in use. So it's perfectly possible that a very large file still be highly efficient. (Consider also most operating systems themselves are very efficient these days, but have colossal install footprints in the gigabytes.)

    If you are anticipating a 200-300mb project (presumably the compressed figure, since usually most of that is already-compressed PNG, Ogg Vorbis, etc) then an extra 55mb is only a moderate overhead relative to the size of the game itself. If you had a small project then it can be a high overhead relative to the size of the game, but then you can work around it another way: everyone in the world already has a browser installed on their computer, and you can publish as a HTML5 game to the web, with no overhead at all.

    We've been using node-webkit/NW.js for a long time now, and very few people have complained about the filesize. I don't think it really materially affects anything.

  • NW.js is based on the same Chromium browser engine Chrome uses, so in theory should work identically. Does the Chrome browser have the same problems?

    If a feature isn't working for you, like the debugger, please file a bug report following all the guidelines so it can be investigated.

  • I think it would speed up workflow if you could select a group of events and replace all references to a variable to another variable.

    I'm not sure I understand why you would want to do this. If you want to change the name, you can rename it and all references update. If you want to change the type, you can't, because it would make events invalid. So then all there is left to do is to replace references to variable with references to another existing variable. Why would you want to do that? Presumably if you made two variables, it's for two different purposes, so I'm having a hard time imagining a useful example of wanting that.

    That and an option to filter variables by event sheet while picking them, sort of a folder category.

    So if you have 3 event sheets with variables, and they are to run together, when picking variables you can toggle tick which to view.

    That would help with searching through the gazillon variables.

    That is what local variables were specifically designed to do. Make them static and they work like global variables. Put them in a group or subevent and they are scoped to that level only.

  • It should be faster on iOS too - the 2-10x faster figure I gave is after testing over a wide range of platforms including iOS, and I have data to back it up. Have you seen performance issues on iOS?

  • skymen - please report any problems to the Bugs forum following all the guidelines, otherwise the issue will be forgotten.

  • It should work on x86 tablets, and will be easiest to use with a keyboard and mouse. So something like the Surface Pro should work well, but that's mainly because they're closer to laptops than a normal tablet.

  • It looks like you've just reinvented a browser that requires Java... you can do all that with Chrome

  • The RTS behavior was renamed to the Pathfinding behavior in C2, since that's what it really does. So it's always been there in C2, just with a different name.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I don't think you understand how Construct 2 works. Almost everything is done via rendering to a canvas. There is no substantial text or HTML content involved in running the game.

  • Crosswalk is only needed for Android 4.x compatibility. It uses the same Chromium browser engine that Chrome uses, so in theory it should work identically. I'm not sure why they would end up using different renderers - perhaps there is a difference in the Chromium version, or the GPU blacklists work differently.

  • WebGL is usually 2-10x faster than canvas2d, so I don't know why you would want to turn it off...