digitalsoapbox's Forum Posts

  • > Any issues you run into with XDK will likely exist with any other web-based exporter, because you don't have control over it, and if you're doing anything it's not expecting the build will fail. The idea that Scirra will be able to provide better maintenance than Intel? What makes you even think that's possible, given the resources of each company?

    >

    Nope you don't understand... Scirra is not hosting a new wrapper, what in the world are you saying there will be better maintenance on Scirra compared to Intel... Try reading it before answering. I did not say that, in fact you said that!

    I said :

    > And since we are in a cloud subscription, the exporter is supposed to be well maintained so there would be lesser bugs and no more workarounds for supporting third party plugins and building.

    >

    That means, if you have tried exporting before on C2 for Cordova and building it on IntelXDK, in your case I'm not sure anymore... You'll notice that there are bugs on the export files of Scirra that needs workaround for supporting third plugins / core plugins during building. For example: The InAppBrowser plugin, before you have to manually edit the config.xml but now that Scirra has better connection with Intel (If the blog post wasn't false advertising) and we can safely assume that any updates on Intel, the Scirra Exporter would be updated also especially that we are in a subscription method, so maintenance should be reliable.

    > If you want the option to optimize your builds as much as possible, you're better off installing node.js, cordova, java & GIT on your local machine and compiling locally, which takes much less time and doesn't require uploading your assets to a 3rd-party server (that may potentially be unreliable), which is going to be configured to support a more generalized build as opposed to something specifically for your game projects. Reliability aside, if you're working on a bigger project, uploading over even a fast connection adds a lot to the build time - whether you're using Cocoon, XDK or Phonegap.

    >

    > Once set up locally, Cordova isn't difficult to use, and just requires a few command-line options or your setting up a batch (.bat) file when you want to compile. If you're interested in doing this, install in this order: java, GIT, node.js, then Cordova. Installing Cordova last allows it to set up the connections to the other components automatically and no manual configuration will be necessary. Plugins can be installed from the command line/powershell, and I'm sure there's a GUI-based installer for them as well if you're more comfortable with that after setup.

    >

    That is too advance for non-programmers... I know most people here using C2 aren't programmers and only want to make games.

    If they were, they'd be using Unity by now.

    Do you expect they will have time or at least interest in learning this? No!

    In fact doing this manually might even be more time consuming and inefficient and more unreliable if you don't know what you're doing. Do you think you can outmatch Intel's build option? Then you make me laugh! You're not even neart trustworthy compared to Scirra I'd rather go with C3's Export + IntelXDK's build.

    And how come you know it will be unreliable, you haven't even tried to use it... In fact, no in the community has.

    — , Zebbi was asking about the benefits, not your build purportedly build option.

    If it's HTML5 and being exported/compiled for Android, it's a wrapper. That's how it works. If you're expecting that to be flawless, you're using the wrong technology (referring to HTML5 here, not C2).

    The workarounds are due to the way XDK/Cocoon/etc. builds, not due to how Cordova builds. No workaround are necessary if you export to Cordova (no need to use the workarounds required for XDK) and compile locally.

    It takes around 10 minutes to install the programs I listed. All of them have publicly accessible documentation. If you're too lazy to figure it out - and there's little to figure out, because the entire build process can be documented on a single page, and executed with the 2 or 3 listed commands, and you only have to dig in deeper if you want to customize builds - that's on you.

  • The Surface Pro 4 is a good all-around choice. The Surface Book is probably not worth the money unless you have cash to spare, the additional GPU in the keyboard isn't especially powerful, so it may be better to wait until the 2nd or 3rd release of the platform to really invest that much in its hardware; the Surface Pro line had performance and overheating issues until the SP4, and I've noticed similar issues when really pushing the Surface Book. Asus also makes a Win10 tablet with Thunderbolt support, so you could plug in an external GPU if you're feeling it's worth the extra cost to invest in an external GPU cage & GPU, but it's not especially portable. Overall, I've found the SP4 to run pretty much everything BUT C2 games quite well, as the recent Intel embedded chips have pretty decent performance and can run Overwatch, DOOM, every Valve game, etc. at acceptable resolutions. Unity also performs fine, as does most Adobe software, though there's no CUDA support due to the lack of nVidia tech.

  • digitalsoapbox Don't get me wrong, I always like to see improvements. I also encounter the jump thru bug and some other weird problems. I wrote TNP's recommended specs because you said: "Recommended specs will always be high." And It sounds like every polished game should have VR Ready PC specs.

    Well...maybe not VR for a 2D game .

  • >

    > > Short Answer : No.

    > >

    > So, benefits? Besides less effort?

    >

    The Export would become more reliable than before since it will directly be connected to IntelXDK.

    But that still depends on what kind of exporter it is. Whether it is single click build inside C3 or a separate program from C3.

    Another benefit is that we can file bug reports directly to Scirra if their Export isn't working. So lesser excuses from Scirra.

    And since we are in a cloud subscription, the exporter is supposed to be well maintained so there would be lesser bugs and no more workarounds for supporting third party plugins and building. It should be as easy as pie to export if Scirra wasn't false advertising. That's the greatest benefit.

    But regarding the performance... It stays the same.

    Any issues you run into with XDK will likely exist with any other web-based exporter, because you don't have control over it, and if you're doing anything it's not expecting the build will fail. The idea that Scirra will be able to provide better maintenance than Intel? What makes you even think that's possible, given the resources of each company?

    If you want the option to optimize your builds as much as possible, you're better off installing node.js, cordova, java & GIT on your local machine and compiling locally, which takes much less time and doesn't require uploading your assets to a 3rd-party server (that may potentially be unreliable), which is going to be configured to support a more generalized build as opposed to something specifically for your game projects. Reliability aside, if you're working on a bigger project, uploading over even a fast connection adds a lot to the build time - whether you're using Cocoon, XDK or Phonegap.

    Once set up locally, Cordova isn't difficult to use, and just requires a few command-line options or your setting up a batch (.bat) file when you want to compile. If you're interested in doing this, install in this order: java, GIT, node.js, then Cordova. Installing Cordova last allows it to set up the connections to the other components automatically and no manual configuration will be necessary. Plugins can be installed from the command line/powershell, and I'm sure there's a GUI-based installer for them as well if you're more comfortable with that after setup.

  • >

    > > digitalsoapbox I just saw Sombrero's recommended specs on steam.

    > >

    > > OS: Windows 10

    > > Processor: Intel Core i7

    > > Memory: 8 GB RAM

    > > Graphics: Nvidia GTX 980 or equivalent with 8GB VRAM

    > > DirectX: Version 11

    > > Network: Broadband Internet connection

    > > Storage: 500 MB available space

    > > Additional Notes: Best played with a 2 stick controller

    > >

    > > I think you should definitely use something other than Construct.

    > >

    >

    > Recommended specs will always be high. The minimum specs should be able to be much lower considering the 2D nature of the game, however because of serious limitations that are endemic to Construct's codebase, which are continuously denied but easy to spot just by looking at the engine code, that hasn't been possible. Even low resolution pixel art games stutter, and that's not just due to garbage collection.

    >

    > It's simply not a tool for any sizable - or sustainable - game development, period, in its current state. Or seemingly in C3, based on the expectations of either a browser-based or wrapped-browser IDE, on either desktop or mobile, and certainly not on any console, marketing claims aside.

    >

    > I'm not even sure the appropriate words exist in the English language to fully express the frustration I had getting even acceptable, let alone good, performance in Sombrero - and I've been dealing with web-based tech professionally for around 20 years. While I understand some (Ashley) will blame others for performance issues, that's simply not the case here - the engine just can't cut it for anything large, and definitely not anything that is meant to run at resolutions expected out of modern desktop games, 2D or otherwise.

    >

    > Don't even get me started on collision (or often, lack thereof) issues, unstable frame rates, buggy native behaviors that Scirra refuses to fix (jumpthrough issues, for example), or missing features that are common enough that I can comfortably say they're available with any other option natively - and by "natively" I mean the actual definition of the word, not the one that Scirra misuses all too often to obfuscate performance issues that can be linked directly to C2.

    >

    > Anyways, live and learn. There's other tools out there without these issues. I'd suggest looking into them. The event system is cool, but the albatross it's currently shackled to is held together with duct tape and bubble gum that's icky and gooey and the seams are showing.

    >

    This is the kind of dialogue that should be promoted and out in the open between high level developers and Scirra - have you provided isolated cases of your concerns?

    I have, but my experience so far has seen a refusal to admit need for improvement or understanding of what users who aren't just making simple mobile games or re-posting store templates on app stores are looking for in their development tools. It may be beneficial for Scirra to work more closely with some of their developers to understand what's needed, but maybe that's happening and we're all unaware...though it's not like there's really all that many larger games in C2 either way, which isn't a great sign.

    Here's a great example of the kind of issues I repeatedly run into when trying to push C2:

    • Create a new layout
    • Set the window size to 1280x720.
    • Add some sprites with collisions across all of it, or a tilemap with collisions enabled and some tiles placed in it that span across the layout.
    • On the start of the layout, resize the window size to 640x360.
    • Congrats! You've just broken collision cells.

    Of course, this could be easily remedied by providing an action to force a recalculation of collision cells...but we don't have that. I have at least a dozen more examples I could put down off the top of my head, but based on my experience with trying to get things improved/fixed in the past, I don't see any value in spending my time putting them together to then be ignored or called "not a bug" or "not a supported behavior." For example, issues with the jumpthrough behavior where the character just falls through platforms with no real explanation, especially on slopes - which has been reported multiple times over multiple years by multiple users. In the case of jumpthrough, it's clearly a bug being hidden behind a statement of "it doesn't support that," since it works 99% of the time but the desire to put forth the effort to fix the 1% of the time where it doesn't (edges of collision cells, certain angles at certain x/y locations, etc.) doesn't exist.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • >

    > Recommended specs will always be high. The minimum specs should be able to be much lower considering the 2D nature of the game, however because of serious limitations that are endemic to Construct's codebase, which are continuously denied but easy to spot just by looking at the engine code, that hasn't been possible. Even low resolution pixel art games stutter, and that's not just due to garbage collection.

    >

    > It's simply not a tool for any sizable - or sustainable - game development, period, in its current state. Or seemingly in C3, based on the expectations of either a browser-based or wrapped-browser IDE, on either desktop or mobile, and certainly not on any console, marketing claims aside.

    >

    > I'm not even sure the appropriate words exist in the English language to fully express the frustration I had getting even acceptable, let alone good, performance in Sombrero - and I've been dealing with web-based tech professionally for around 20 years. While I understand some (Ashley) will blame others for performance issues, that's simply not the case here - the engine just can't cut it for anything large, and definitely not anything that is meant to run at resolutions expected out of modern desktop games, 2D or otherwise.

    >

    > Don't even get me started on collision (or often, lack thereof) issues, unstable frame rates, buggy native behaviors that Scirra refuses to fix (jumpthrough issues, for example), or missing features that are common enough that I can comfortably say they're available with any other option natively - and by "natively" I mean the actual definition of the word, not the one that Scirra misuses all too often to obfuscate performance issues that can be linked directly to C2.

    >

    > Anyways, live and learn. There's other tools out there without these issues. I'd suggest looking into them. The event system is cool, but the albatross it's currently shackled to is held together with duct tape and bubble gum that's icky and gooey and the seams are showing.

    >

    Checking the spec required by your game it seems odd to me it requires so much. Me and my team mate work on a large project as well (check DinoSystem on Steam), which simulates a whole ecosystem with dozens animals roaming, eating, hunting, mating and doing their buisiness, hundreds plants growing, a dynamic weather system, seasons, thousand objects on the map. Still, the game runs fine on my mid-range laptop.

    I agree C2/3 with html5/wrapper is not the more efficient engine to work on a large project, but still seems strange Sombrero needs that specs. Maybe its the destructible world feature or collisions, i'm quite curious about it and would like to know more.

    You're referring to features that are not GPU heavy, so that's not really the same thing. It also depends on your resolution, which I've said in a couple different posts now is the issue in terms of performance at expected - and common - monitor resolutions.

  • Ribis If you're not going to optimize your effects, particles and graphics, even you use the most optimized engine, you will fail.

    digitalsoapbox The Next Penelope rec. specs on steam

    OS: Windows 7/8

    Processor: 2.4 GHZ

    Memory: 2 GB RAM

    Graphics: Nvidia Geforce 600 series or higher

    DirectX: Version 9.0c

    Storage: 1 GB available space

    The Next Penelope is locked to 1280x720. Sombrero is not. The next update of Sombrero will also including resolution switching (which, in C2, was a giant pain in the ass), which will help get the required specs lower. It's also helpful to keep in mind TNP is a very different kind of game, with a very different feature set.

    Currently, if a user manually drops their monitor resolution to 1280x720, Sombrero would run on the same specs as TNP, but developers cannot expect users to do such a thing, which is why I battled through adding resolution switching (altering canvas size, along with stuff to continue placing objects at the correct X/Y position, including parallax/scaling layers) to Sombrero, which C2 is most definitely NOT designed to support, partially as a side effect of the tech, partially due to the design not being entirely thought out in terms of common, real-world usage in desktop game development. It's also good to keep in mind that the developer of TNP has moved on to other projects (and development tools) as well.

  • digitalsoapbox I just saw Sombrero's recommended specs on steam.

    OS: Windows 10

    Processor: Intel Core i7

    Memory: 8 GB RAM

    Graphics: Nvidia GTX 980 or equivalent with 8GB VRAM

    DirectX: Version 11

    Network: Broadband Internet connection

    Storage: 500 MB available space

    Additional Notes: Best played with a 2 stick controller

    I think you should definitely use something other than Construct.

    Recommended specs will always be high. The minimum specs should be able to be much lower considering the 2D nature of the game, however because of serious limitations that are endemic to Construct's codebase, which are continuously denied but easy to spot just by looking at the engine code, that hasn't been possible. Even low resolution pixel art games stutter, and that's not just due to garbage collection.

    It's simply not a tool for any sizable - or sustainable - game development, period, in its current state. Or seemingly in C3, based on the expectations of either a browser-based or wrapped-browser IDE, on either desktop or mobile, and certainly not on any console, marketing claims aside. When playing YouTube videos can crash a browser on a monster of a machine (with no browser extensions installed), maybe that's not the best platform to base a professional IDE on.

    I'm not even sure the appropriate words exist in the English language to fully express the frustration I had getting even acceptable, let alone good, performance in Sombrero - and I've been dealing with web-based tech professionally for around 20 years. While I understand some (Ashley) will blame others for performance issues, that's simply not the case here - the engine just can't cut it for anything large, and definitely not anything that is meant to run at resolutions expected out of modern desktop games, 2D or otherwise.

    Don't even get me started on collision (or often, lack thereof) issues, unstable frame rates, buggy native behaviors that Scirra refuses to fix (jumpthrough issues, for example), or missing features that are common enough that I can comfortably say they're available with any other option natively - and by "natively" I mean the actual definition of the word, not the one that Scirra misuses all too often to obfuscate performance issues that can be linked directly to C2.

    Anyways, live and learn. There's other tools out there without these issues. I'd suggest looking into them. The event system is cool, but the albatross it's currently shackled to is held together with duct tape and bubble gum that's icky and gooey and the seams are showing.

  • >

    > > Since we can import Construct 2 projects into Construct 3, it seems to me that the plugins will also be compatible.

    > >

    > > I think, however, that most plugins should be updated by their authors to take advantage of the new editor plugin sdk. I can't wait to get my hands on it!

    > >

    >

    > They've never said that C3 will import C2 projects with 3rd party plugins.

    >

    Thats a good point.

    The structure of existing plugs isn't too bad for uploading.

    The use of the .ico type for icons might be an issue.

    Then again the blog mentioned the use of svg, and webgl doesn't play well with that either.

    That would be a huge feature if they got that to work together.

    But as Zed said the new sdk may change the whole thing, and if it's got editor/event integration then ....well it's got a lot of implications.

    Not as many implications as expecting large projects to be uploaded to a third-party server for "export," in terms of either reliability of said server (just the website goes down quite a bit), bandwidth use (a huge issue on mobile, especially outside of the US with data rate charges - not that anyone in their right mind is going to work on games on a phone), and legal (providing game assets to an unlicensed 3rd party just to get the game to "export").

    I'd suggest you download Unity. Learn C#. Get your games on more platforms, more reliably, and with measurably better performance.

  • Since we can import Construct 2 projects into Construct 3, it seems to me that the plugins will also be compatible.

    I think, however, that most plugins should be updated by their authors to take advantage of the new editor plugin sdk. I can't wait to get my hands on it!

    They've never said that C3 will import C2 projects with 3rd party plugins.

  • The next post is up,

    it talks a little more about backward compatibility and shows some screenshots

    "We imported its Construct 2 project in to Construct 3, and as you can see it looks great "

    Show it to me running a complex C2 project, not a screenshot of a title screen.

    >

    > > MY GOSH LOOOOOL buildobox is so crazy expensive XD even my 3dsmax or photoshop are less expensive than that i definitely stay with cnstruct 2 & 3

    > >

    >

    > Their pricing is similar to Unity's pricing for a license that doesn't require Unity branding or a revenue cap.

    >

    Which is a crazy high price for a 2d game creator that doesn't do half of what Unity provides.

    Only if you have no interest in making money with it, in which case it's fine. Unity is also not a dedicated 2D game development tool. It also doesn't depend upon 3rd-party export options.

    MY GOSH LOOOOOL buildobox is so crazy expensive XD even my 3dsmax or photoshop are less expensive than that i definitely stay with cnstruct 2 & 3

    Their pricing is similar to Unity's pricing for a license that doesn't require Unity branding or a revenue cap.

    Well, I still don't know what that is supposed to mean.

    I know what "populating an array with data" means. That makes "coding sense" to me.

    I still don't know what "populate C code as you work". It pops C code in your notepad when you are creating events ? If so, I find it a strange formulation.

    It means that it converts to C code as you complete lines of code or on-demand, so that when you preview, you're previewing the end result of the conversion to C, not the scripting language. As near as I can tell, it's a complicated way to say they're compiling to native rather than using an interpreter when previewing or exporting. It's a marketing line, much like those used by any other for-profit software when discussing its feature set, including C2, although here it does seem to be converting to C for, theoretically, native device performance.

  • >

    > > Anyone have a fix for this? I'm trying to use the hexagonalpixelate effect and it is change when scrolling.

    > >

    >

    > The shaders still haven't been updated. More than 2 years later.

    >

    As expected. And it won't be fixed. Ever. The same way 48273453 other C2 things won't.

    Funny fact - it all worked flawlessly in Construct Classic, around 5-6 years ago. Then again, CC had DirectX behind his back. So a lot of "new" stuff to WebGL are old news in DirectX.

    More on topic - I remember finding an actual solution to this Warp problem. But I also remember it was very user-unfriendly and CPU intense. So I dropped it. It had something to do with putting an extra Effect BEFORE the Warp. The effect was there with all param's zero'ed, just for the sake of "being the first before Warp". Sadly, I cannot remember which effect that was. I am not even sure if it was one of default or some custom made. So if you have a spare day or two for experimenting - you might want to follow that lead/direction.

    PS: about this "thing", that it soo complicated to fix - to call it gently, that is not true. Go and browse user-made, distortion Effects. Most of them doesn't have this issue.

    There was a point where they worked properly in C2 as well, then something undocumented changed. There was also a point where they ignored timescale, and then, at some undocumented point, they didn't...shortly after I sent a video of it occurring in-game to Scirra. I'm sure that was just a coincidence though...

    Anyways, I think a lot of these issues get dropped because of a fundamental misunderstanding of what more advanced, or at the very least more informed, C2 users want and need (a separate issue from listening to what beginners with no experience think they want), even though such people can be the biggest cheerleaders. It is what it is. There's a reason those who release bigger games end up moving on after using C2 for one, unfortunately. I think we'd all rather use an event-type system similar to what C2 uses over C#, but we're not developing the software, so.....yeah. ¯\_(?)_/¯