You'll need to collaborate with Scirra on this, let them test the capx examples on Intel graphics and see whats going on.. if its really an Intel problem, perhaps they can submit bug reports to Intel's driver team.

If its a C2 problem, then they can improve it.

Hopefully it's the latter, as Ash has said it's pretty tough getting help from driver vendors

[quote:2gkxfx5t]Browser vendors are far more receptive to bug reports than driver vendors BTW, so if you're worried about problems caused by third parties, driver bugs are a far worse and far more significant problem with native engines! I'll take the browser vendors any day...

They probably published from an old version C2, try downgrading (Save your file as a project folder, then edit the .caproj and change the version number of the C2 software) .

Well Alpha isn't in Construct Classic and this is really terrible because I can't seem to edit any of my sprites on my project. And even if I open a new project this problem persists...It's like my sprite editor in CC just broke out of nowhere.

Actually Alpha is in Construct Classic, it is different for each drawing tool though:

Fill tool - Alpha is set at the top

Paintbrush, Pencil, Lines - Opacity and Flow control the transparency

Shapes - Alpha 1 and Alpha 2

Welcome to the forums!

Try starting with this: https://www.scirra.com/tutorials/37/beg ... onstruct-2

Then you can find some good beginner tutorials here: https://www.scirra.com/tutorials/top/pa ... e=detailed

I think Construct 2 as an editor is one of (if not) the best for 2D games, I've used it as well as CC and similar tools for over 13 years now even though I also have done games in pure code before (well, with a few helpers like the Allegro C++ graphics library or Processing for Java, etc). Every few updates the desktop run-time gets a bit better too.

I'm still a novice with Unity, but it feels very alien to what I'm used to and tends to feel floaty to me, especially when you use the physics, from what I've seen it is very capable as well for 2D but is generally preferred for 3D or multi-platform games (consoles, phones, etc).

newt Yeah, that's true, same for every game though generally

jayderyu Well yeah, but Unity has a lot of first-party control over their own layers, although my layer list was actually based on exported games from Construct Classic Also, Node-Webkit is quite a bit bigger in size than 15mb but for large games it's probably the least of our concerns.

Ruskul Definitely to everything you said, also how some things that should work don't always work (eg: nested sub-events and loops, families, picking, collision, etc) and get really strange when framerate drops below target.

Good luck on your game Hasuak!

Since CC is retired this section is slower for people to reply, but I got your message on GameJolt.

Not many people have used GameJolt API in CC I think, especially not myself, but it could be good to try the plugin in a fresh cap to see if it's just not merging with your game or if the plugin truly is broken (are you using Construct Classic R2 from the sourceforge? R1.2 is the outdated version linked from the C2 website).

You will probably need the token to avoid crashing too, that can be found on the top of the GameJolt page here:

Click show, and then odds are the plugin will let you enter it via an event or maybe in the plugin properties, that should be how you authorize the app to work with GameJolt but I have never used the API myself.

newt Well yes but you can only optimize after each of the layers below have taken their toll, and also there have indeed been big games in C2 like the ones on Steam that are listed earlier in this thread.

The layers of a native engine:

Your exported game

DirectX/OpenGL engine (partially third party, but a lot of control is still there)

Your OS*

Your drivers (driver vendor issues)*

Your hardware*

The layers in a Node-Webkit desktop game:

Your exported game

HTML5 + WebGL "engine"

Node-webkit *

Chromium (browser vendor)*

Your OS*

Your drivers (driver vendor issues)*

Your hardware*

* = third party

I don't see how adding the extra layers that a third party controls will make it less likely for a game to run into issues that only a third party can solve.

Eg: If NVIDIA has an issue rendering OpenGL/WebGL, then I still have a driver vendor issue on top of whatever browser vendor issues I have. Sure, maybe it takes the "contacting driver vendors" part away on this end, but that just adds it to the browser vendor's side, which just feels like even less control over the situation no matter how big the browser vendor is.

How does C2 handle memory usage? Does it load all the layouts simultaneously? I have one layout where I put all the objects that need specific default settings and variables and it has become quite a mess. Is this a good way of handling stuff like this or should I set all those things at the moment of spawning objects? Also do I need to hide objects that aren't on screen seperately to save memory

If I remember right, Construct 2 has some built-in recycling to prevent as much jitter/jank as possible when Javascript does its garbage cleaning, it's handled internally so you wouldn't need to worry about it.

As long as those objects are just editor-side that layout shouldn't cause any troubles for you, I think it will be the default values if they're the only instance of them/set before copies are made in other layouts.

Construct 2 also handles the rendering on/off screen stuff itself internally in a manner that will probably be more efficient than events, but you can do extra things like making sure WebGL FX are applied to whole layers instead of multiple individual objects that are supposed to have it.

However, as for making big games in general, I would say give these a read:

native-desktop-exporter-for-construct-3_p879348?#p879348

native-desktop-exporter-for-construct-3_p879661?#p879661

Those are posts from developers of two of the three big "dream" game examples on the scirra homepage ( http://www.scirra.com/ ), and I too have a game on Steam with a friend I met on the forums here ( http://store.steampowered.com/app/334190/ ), and loading time can be quite a while for large games exported to EXE with Node-Webkit, we also had troubles with updates to C2 and updates to Node-Webkit (but this part should be better now that you can downgrade any time at: https://www.scirra.com/nwjs , we are currently using 0.10.5 for the best experience but 0.12.x is looking promising).

Even so, it should be possible to make a game like the one you referenced above, not sure how it would run in anything other than Node-Webkit though.

I can answer a few of those questions hopefully well enough to help you decide

1.) Yes, in fact it exports in a format Construct 2 will not be able to open, and does some tricks to make code hard to reverse-engineer.

2.) It does provide you with estimates of the memory usage of your game as you're making it, and I think you can load and unload images per each layout (level). As for CPU usage there is handy debug and possibly also profiling tools to help you optimize.

3.) Yes, I'm not sure if there's tutorials or examples around, but I did this for Insanity's Blade for future localization capabilities. I think I loaded the text straight into a variable with the AJAX plugin.

4.) Yes, these can be done as functions or by activating/deactivating groups. You can include event sheets inside of other sheets too.

5.) Not sure about this one, but you can use 9-patch to do rounded boxes that scale to different sizes!

6.) I'd say definitely, but can't remember that example. You can probably do it easy with Spriter too but it should work with just sprites + events.

7.) Yes, that's pretty straight-forward eventing.

8.) Not too certain I can answer this one, but you can create and import event sheets pretty freely once you have a full version of C2.

Hope that helps!

— would it be alright if I e-mailed you as well about getting cloud saves and trading cards working?