Isn't construct 2 support the 96dpi assets?

I planed to make a HD game but my friend told me that construct 2 doesn't support HD game. if you use the hd assets, the game will crash aften. Isn't it true? Please tell me what is the limit

Dpi refers to the number of dots a printer can produce.

If your computer supports "hd" graphics, then yes the engine will support it.

The limit is based on the individual device used.

Developers design around a common spec in order to reach the maximum number of users.

Construct 2 does support HD games. The most common reason people's games crash is because they use up too much memory on the device with inefficient game design. This is nothing to do with Construct, it's just not everyone is aware of the limits of their hardware.

Vasanthi Keep in mind when Ashley says: "Construct 2 does support HD games.", what he means is that you can run true HD games but with severe performance issues or even memory related crashes (mostly on low to medium-end devices).

While the "remember not to waste your memory" blogpost has lots of useful information on it that everyone should know about, you will simply at some point run into the problem that one or more of your layouts with true HD assets are reaching the memory limit. Obviously the most common response for this that you will probably get is: "downscale your assets and upscale them ingame!". If I had to translate that, it would basically mean that you have to turn your game's graphics quality down to 2006-2008's standard, which is obviously not what most game developers want to do but unfortunately are forced to do. (Your future customers won't be very pleased about that either.)

Currently Construct 2 and 3 both don't offer any way to customize memory management so that you can decide on the assets (textures/sprites) you want to load into memory on start of the layout or unload/load them on the fly. To come to my point: if you have any plans to create some sort of "open world" or generally a game with huge layouts and true HD assets, you're in a for long and frustrating ride...

Of course you have to take into account that those limitations are based on the platform, and the necessity of reaching the largest user base.

While it's possible to have a hundred thousand objects moving around the screen, or ultra high resolution assets in a game engine, the fact is that those are unrealistic expectations to most developers, and even gamers.

While it's possible to have a hundred thousand objects moving around the screen, or ultra high resolution assets in a game engine, the fact is that those are unrealistic expectations to most developers, and even gamers.

Only difference being that most game engines offer more advanced tools in order to work with high-res assets. Construct 2/3 doesn't even let us create custom loading screens in order to deal with the famous "loading-freeze" when loading into large layouts or as I said before, no on the fly memory management (yet).

In the end it all comes down to the type of game you're trying to develop.

Sure, it's even arguable that the png compression, and sprite sheeting are detrimental for some users.

It seems pretty clear that it's designed for a certain type of developer.

Is that the reason for so much turnover of users?

Some of it, probably.

Will that work with C3?

Dunno, how big is the hipster/ Chromebook market?

Sure, it's even arguable that the png compression, and sprite sheeting are detrimental for some users.

It seems pretty clear that it's designed for a certain type of developer.

Is that the reason for so much turnover of users?

Some of it, probably.

Will that work with C3?

Dunno, how big is the hipster/ Chromebook market?

The "desktop version" of Construct 3 could technically do everything that native engines can (e.g. on demand GC).

Without going too off-topic in here, I have a strong feeling that C3 will end up being a game engine for mobiles.

It's been a couple of months now and I see next to no focus on more advanced tools or features for desktop games.

The new runtime will reveal if Ashley has any intentions to implement features which were previously not possible.

I still remember the "poor runtime"

excuses that were being used in the past and even in recent times...

Surely building a mobile-first engine would benefit every platform? By designing the engine with the lowest spec / highest limitation platform the actual codebase will be super scalable.

With browser vendors and the internet itself shifting more from information to experiences*, I honestly believe a lot of the low level stuff we crave like browser memory management and FPS control will be implemented in the coming years - though I can understand this doesn't help the developers of today.

* I also think Construct is uniquely placed to become not simply a game engine, but also the world's first true web experience engine.

Surely building a mobile-first engine would benefit every platform?

I wouldn't count on it. Mobile games are usually much more simple when it comes to game mechanics and assets that are being used.

I honestly believe a lot of the low level stuff we crave like browser memory management and FPS control will be implemented in the coming years - though I can understand this doesn't help the developers of today.

Sorry but even basic features like gamepad vibration are still in the "draft" stage for years now.

As you pretty much said, only Dev's that want to wait years for certain features will surely benefit from them.

I also think Construct is uniquely placed to become not simply a game engine, but also the world first true web experience engine.

It might have been the worlds first true and best web experience but in 2017 it certainly isn't anymore.

Other game engines offer web exporting with almost the same or better performance and more advanced features next to their countless native exporters.

I'm personally predicting a grim future if C3 doesn't step up anytime soon with new cutting edge features, not just for beginners but also for more experienced users.

Vasanthi Keep in mind when Ashley says: "Construct 2 does support HD games.", what he means is that you can run true HD games but with severe performance issues or even memory related crashes (mostly on low to medium-end devices).

I just want to emphasise that if you see these issues, it's because you're exceeding the limits of the hardware. Often people try to make a game that uses 10 GB of memory, find it crashes, then think "Construct sucks". Or they make a game with dozens of layers and tons of overdraw and run it on a weak integrated GPU, far exceeding its memory bandwidth resulting in laggy gameplay, and then think "Construct sucks". The real problem is you far exceeded the limits of the hardware in a way a professional designer never would. I don't think you need to fuel these misconceptions.

I think you just want the "unload sprite" action? There's no need to proclaim the downfall of an engine over that, the layout-by-layout memory management works fine for many games.

> Vasanthi Keep in mind when Ashley says: "Construct 2 does support HD games.", what he means is that you can run true HD games but with severe performance issues or even memory related crashes (mostly on low to medium-end devices).

>

I just want to emphasise that if you see these issues, it's because you're exceeding the limits of the hardware. Often people try to make a game that uses 10 GB of memory, find it crashes, then think "Construct sucks". Or they make a game with dozens of layers and tons of overdraw and run it on a weak integrated GPU, far exceeding its memory bandwidth resulting in laggy gameplay, and then think "Construct sucks". The real problem is you far exceeded the limits of the hardware in a way a professional designer never would. I don't think you need to fuel these misconceptions.

Well professional game designers probably won't downscale or essentially "cripple" their games so that they work on every desktop PC, since as I've said later on in another post: "Only difference being that most game engines offer more advanced tools in order to work with high-res assets".

What you're basing your whole argument on is the case for beginners and they usually don't know much about memory management at all.

I think you just want the "unload sprite" action? There's no need to proclaim the downfall of an engine over that, the layout-by-layout memory management works fine for many games.

I've said multiple times in many posts in here that I want advanced memory management.

I as a self proclaimed mediocre game designer, don't want to rely on fully automatic loading or management systems and want to have as much control over my game as possible. Again I'm not saying that you're wrong when you state that systems like the layout-by-layout loader work fine for the majority of games but my point is that having more options won't hurt and could even make Construct 3 more attractive for professional game designers.

Any further questions regarding this can be asked here:

https://construct3.ideas.aha.io/ideas/C3-I-355.

I won't say it's the downfall of Construct 3 since that's pretty much assumption based and I have no statistics to prove my point anyway but from what I can see so far is that a number of people don't seem to find enough reasons (cutting edge features if you will), that gets them on the edge of their seat and gives them a reason to switch. If you actually ask some of the C2 Dev's, you will probably find out that they only did or consider doing the switch to C3 because of bugs or limitations inside C2.

Well professional game designers probably won't downscale or essentially "cripple" their games so that they work on every desktop PC, since as I've said later on in another post: "Only difference being that most game engines offer more advanced tools in order to work with high-res assets".

Given that modern mobile devices have about the same resolution as desktop devices (e.g. physical display size is ~1920x1080 or so), what additional tools for working with different resolution assets do you think are necessary?

> Well professional game designers probably won't downscale or essentially "cripple" their games so that they work on every desktop PC, since as I've said later on in another post: "Only difference being that most game engines offer more advanced tools in order to work with high-res assets".

>

Given that modern mobile devices have about the same resolution as desktop devices (e.g. physical display size is ~1920x1080 or so), what additional tools for working with different resolution assets do you think are necessary?

I would still argue that most mobile games aren't really comparable to desktop games. I'd really like to focus on desktop releases only.

Generally speaking I would like to see more customization and advanced options for our games:

• Customizable loading screens for each individual layout*, which let's us pick what to load into memory on start of the layout, to work around the before mentioned "layout-freeze" and possible memory limit crashes.
• Based on my idea, advanced memory management features for textures.
• GC calls on demand** using an action (e.g. Collect Garbage) inside the NW.js plugin.
• I'm not sure about this one but I've seen other engines offer specific editing just for ingame menu's and UI. I assume they do this because they use a more optimized, specific type of rendering just for those.

*This would be optional and can be enabled if necessary to keeps things simple for beginners. **GC can be forced using a JS-flag without affecting any other features,

see How To: Force GC To Instantly Unload Audio From Memory

Are you talking about C2, or C3?

You already know that's not going to happen in C2.

Not unless, something radical happens with it. A discussion for some other thread, obviously.