Plugins/effects and C3

They have shown both the last Penelope and airscape both running, and both projects use 3rd party plugins, so i would say its safe to assume c3 will support c2 plugins.

They have shown both the last Penelope and airscape both running, and both projects use 3rd party plugins, so i would say its safe to assume c3 will support c2 plugins.

Its likely they would be supporting the 3rd party plugin. Keeping free, bored developers contributing to scirra is a big plus. I am more curious how will offline c3 perform with service workers supporting the offline platform.

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.

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

> 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've had collision issues before and even played around with making a custom 8move to fit some needs of mine due more control over it and how it handles pushing it out of the blocking object, but it's more of a hazard of how it actually does collision vs ticks with polygons rather than pixel-perfect collision. I can't say how many times i had to make an object slightly smaller to fit into a gap that in a pixel-perfect environment would fit perfectly (gap of 8 pixels wide, object of 8 pixels wide, polygons of 7.96 or so) or make sure it's sprite stops perfectly against the wall rather than going over the edge slightly.

Most of the time it's only an issue depending on tickspeed and movespeed of the object it's tracking. There's always room for optimization and isolating edge cases so they don't drag down the system, but it's just a limitation of the engine.

I do wish Scirra would introduce some sort of pixel-perfect collision or something similar as an optional alternative. The pixel rounding they do in the optional settings for it simulates it visually but the collision box itself is still a polygon.

I do wish Scirra would introduce some sort of pixel-perfect collision or something similar as an optional alternative.

I don't remember exactly which behaviors use it, but definitely the platform behavior does even better than pixel precision - it goes down to 1/16th of a pixel, IIRC. So it's actually kind of sub-pixel-perfect.

> I do wish Scirra would introduce some sort of pixel-perfect collision or something similar as an optional alternative.

>

I don't remember exactly which behaviors use it, but definitely the platform behavior does even better than pixel precision - it goes down to 1/16th of a pixel, IIRC. So it's actually kind of sub-pixel-perfect.

Well from what I remember and was able to test using grid placement in the platformer template, it still requires a 32x32 player to be either slight smaller than 32x32 for it's collision box to fit in a 32x32 hole or have the hole be slightly bigger. You can adjust the player size to 31.9x31.9 or so to have it smaller but relatively the same size so it can fit in.

It's just a limitation on how the polygon collision system is designed when focusing on lower resolution projects and it has great benefits for high resolution games where traditional bitmap collision masks would be too cumbersome.

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

I know, in fact most of the time it depends by the abillity of the developer to make the best performance for the game... is someone make a simple 2d mario with a simple gameplay and runs bad, could be 2 reasons:

bad "code" or some bad performance with construct2

check this video:

I make the donkey kong country engine and look how run, 5400 objects animated and looks how runs... also I can make ad editor for ad users who want to make his own map and play it... (I made that method for make the level designer easier)

I "remade" the same engine with half of event (before was like 1200 and it was wunning perfect) and the gamaplay is not easy, 2 players, the player can crab stuff, different kind of enemy and ability, jump on the animals,ropes...etc...etc... and also, there is no physics, I just use solid and platform behavior, I avoid to use all of third party... most of the time I make a fake physics and I never use a particle effect... I make my own..

I fell frustrating just because of the bad performance (sometime the framerate change without any sense) and for the export... for the rest, construct2 is the best software for make game and app very quiclky and you can get work... but the exporter is another story so...

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

>

I know, in fact most of the time it depends by the abillity of the developer to make the best performance for the game... is someone make a simple 2d mario with a simple gameplay and runs bad, could be 2 reasons:

bad "code" or some bad performance with construct2

check this video:

I make the donkey kong country engine and look how run, 5400 objects animated and looks how runs... also I can make ad editor for ad users who want to make his own map and play it... (I made that method for make the level designer easier)

I "remade" the same engine with half of event (before was like 1200 and it was wunning perfect) and the gamaplay is not easy, 2 players, the player can crab stuff, different kind of enemy and ability, jump on the animals,ropes...etc...etc... and also, there is no physics, I just use solid and platform behavior, I avoid to use all of third party... most of the time I make a fake physics and I never use a particle effect... I make my own..

I fell frustrating just because of the bad performance (sometime the framerate change without any sense) and for the export... for the rest, construct2 is the best software for make game and app very quiclky and you can get work... but the exporter is another story so...

Wow the game looks great! great job!

Mind if i ask what do you use for fake physics? (like throwing the barrell)

If construct3 has one big advantage, that would be backward compatibility. Being able to use construct2 plugins and effects in construct3 is a big selling point to me

Well from what I remember and was able to test using grid placement in the platformer template, it still requires a 32x32 player to be either slight smaller than 32x32 for it's collision box to fit in a 32x32 hole or have the hole be slightly bigger.

This comes down to the math involved in the collision engine: two exactly aligned objects like you describe will have their edges at exactly the same position, and two things at the same position count as overlapping.

Even if we changed that case to not count as overlapping, I don't think it would actually help much. All movement and calculations in C2 use floats, which is nice for precision and smooth movement, but as with the entire field of programming, float calculations are not exact. So you could easily end up computing the player's position as 32.0000001 or 31.999998999, and it will still no longer exactly fit inside a 32px gap, even if the collision engine specifically allows exact-fits. So I don't think there's really any easy fix to that - you just have to adjust your collision boxes to not require exact-fits. So shaving 0.1px off the collision box is a good workaround, and one you'd likely still need even if we changed the engine.

Maybe do this shaving part automatic?

maybe add as option.

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.

>

> 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.