Disappointed over bad communications!!!

Discussion and feedback on Construct 2

Post » Wed Apr 15, 2015 3:45 pm

@winkr7 that sounds like you just haven't set one of the Fullscreen in Browser modes: https://www.scirra.com/tutorials/73/sup ... sizes#h2a1
ImageImageImageImage
B
57
S
19
G
51
Posts: 633
Reputation: 30,681

Post » Wed Apr 15, 2015 3:48 pm

winkr7 wrote:Heres the problem I'm having.

I wrote a game in C2 on a layout that was 1024 by 768. Everything seemed fine on my desktop. When I put it on my iphone though it was REALLY SMALL.

Ashley, can I send you my capx and can you explain why it is so small on my IPhone?

yours
Winkr7



I think this is nothing for ashley or this post... post this as a new thread
B
5
Posts: 42
Reputation: 313

Post » Wed Apr 15, 2015 3:52 pm

metameta wrote:For sure we want a html5 game maker but there must be a reason why 2 sprites are junking when i export a game with the prefered android export procedure intel xdk and crosswalk....



I would like to know why this is happening if anybody has answers?
B
7
S
1
Posts: 40
Reputation: 570

Post » Wed Apr 15, 2015 4:35 pm

Eisenhans wrote:The interesting question is: Why do so many people buy a HTML5 engine if they don't want one? The "we can export with wrappers!!!"-thing came as a bonus over time and is still just a bunch of hacks.


I have always wanted the sequel to Construct Classic to be something with native desktop export (even if just Windows), and that was one of the things that we were told would be "definitely" part of Construct 2 in the early stages of its development. In fact, C2 was supposed to support multiple exporters during its early plannings, rather than just HTML5, which is why all the plugins go inside "Construct 2/exporters/html5/plugins" rather than just "Construct 2/plugins".

There were many people who voiced this concern in the early days and we were basically told it was "a given" that proper desktop export was included.

After Scirra decided to focus on just the one exporter, were told that HTML5 would be better for portability and run better than Construct Classic ( https://www.scirra.com/blog/102/html5-g ... han-native ) , and it's true, I can now have a badly running game on a whole bunch of platforms, but the performance just isn't smooth, and eventually we are told that it's due to third parties.

Well, if we aren't using a native engine because it depends on "too many third parties" I don't see how this makes sense:
Image

A funny comparison would be to how (and why) Apple ditched Flash: https://www.apple.com/hotnews/thoughts-on-flash/

If you replace Flash with Construct 2/HTML5 in our case (because for them, HTML5 is something they directly code the native browser for) the words become

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.

Construct 2 is a cross platform development tool. It is not Scirra’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Scirra has been painfully slow to adopt enhancements to Apple’s platforms.
Last edited by Jayjay on Wed Apr 15, 2015 4:55 pm, edited 2 times in total.
"Construct 4 lets YOU make advanced games! (but not play them)" Construct Classic - Examples Kit
B
109
S
38
G
17
Posts: 2,172
Reputation: 18,989

Post » Wed Apr 15, 2015 4:47 pm

@Jayjay yup, all true. Probably most of early adopters bought it because it was the next evolution of CC (all the features + more + working better). Ultimately html5 is not that awesome as everyone is seeing it. But hey, WebGL 2 is coming! it's all gonna be fine in next couple of years. All we need to do is just wait (no quotation mark needed)
ImageImageImageImage
B
156
S
64
G
41
Posts: 2,589
Reputation: 34,603

Post » Wed Apr 15, 2015 5:00 pm

^^ That's why I'm starting my first Unity class tonight. I love the philosophy behind the design of the c2 editor and I hope the export options improve, because if they do I'll be back full time in a flash.

But with talk of improving the editor to "c3" it feels like the priority is a design journey rather than getting to an export-your-game destination. A journey that may well end in a couple of years in being able to quickly make awesome things that still play well nowhere.
I only occasionally visit - I'm learning C# for Unity, but c2 is still a respectable game engine imo....
B
69
S
18
G
65
Posts: 2,195
Reputation: 41,465

Post » Wed Apr 15, 2015 5:36 pm

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform.


I disagree with that statement completely. Reliance on third parties is only bad if you suffer from vendor lock-in (which we don't, by the way, the closest we get is over-reliance on chromium, which isn't even that bad since chromium is FOSS). What you're calling "third parties" actually means "abstraction layers" in this context, and those are the holy grail of computing, and has been that way since its inception.

It is obvious that the more layers of abstraction you have between you and the metal, the slower things are, but the more layers you remove, the more you start finding that writing software borders on the impossible, culminating in "real programmers use a magnetized needle and a steady hand". For example, buggy and bloated as graphics drivers may be, no one would dream of ditching them and pushing raw instructions directly to the GPU, even if those ended up being a thousand times faster than going through the drivers.

Same goes for the myriad of third-party-reliant technologies used by Scirra to provide fast turnaround, easy gamemaking capabilities and seamless portability. To implement those by hand would require titanic efforts that a solo programmer just can't cope with, regardless of his "rockstar" status. Ashley has stated multiple times: bringing feature parity to a native exporter amounts to writing a browser engine from scratch; and lest anyone thinks this is easy, remember that Opera is basically a wrapper nowadays, even their multi-man team and 2~3% market penetration (which is huge when you consider the numbers we're talking about here) wasn't enough to convince them to stay (nevermind "switching to") in-house.

If we go by what the market is showing us with regards to other game-making tools, as soon as you start writing native exporters, your product is frozen. Feature development slows to a glacial pace and all efforts are shifted to attempts to bring feature parity and bug fixes.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Wed Apr 15, 2015 5:47 pm

@Fimbul

Construct Classic, Craft Studio, Game Develop, GameMaker 6, Clickteam products (MMF, TGF, etc), Godot, and many other small-team-engines perform very well and generally use less layers of abstraction than Construct 2.

I'm just pointing out that the less layers involved above DirectX/OpenGL, the better the performance and control over his own program that Ashley will have.

Of course going down anywhere below C++ and a graphics API is entering into layers that I would never expect a lone developer to code for, but pretending that HTML5 works how it was supposed to at the export side of things has to stop.

Maybe if there was one console that could actually run REAL games (made in HTML5/WebGL from C2) well then we'd all be happy, but as long as everyone is using a million different devices and platforms, the ability to have my game work badly across all of them is no good compared to just one export platform running perfectly across the majority of my customer/userbase (eg: after they have been determined to have met a minimum of specs and updated their graphics drivers to the latest version and updated their DirectX and Windows Updates, after that point I should rarely ever see a complaint about bad performance)

Fimbul wrote:If we go by what the market is showing us with regards to other game-making tools, as soon as you start writing native exporters, your product is frozen. Feature development slows to a glacial pace and all efforts are shifted to attempts to bring feature parity and bug fixes.


I can do enough in Construct 2 to make my games, the bug fixing and runtime performance is all I need to be happy. Editor-side C2 works way better than any engine as-is for 2D games. I see no reason to update the editor aside from making it easier for plugins like Quazi's Q3D to control more of the GUI.
"Construct 4 lets YOU make advanced games! (but not play them)" Construct Classic - Examples Kit
B
109
S
38
G
17
Posts: 2,172
Reputation: 18,989

Post » Wed Apr 15, 2015 6:48 pm

Jayjay wrote: In fact, C2 was supposed to support multiple exporters during its early plannings, rather than just HTML5 (...)


Admittedly, I missed the early adopter phase and have no CC background, so I have no idea what C2 was supposed to be in the beginning. When I bought in Sept. 2012 I was looking explicitly for a HTML5 engine and it was relatively clear that native directx was off the table.
But if as you say this evolved from another announcement entirely, I can partially understand the frustration that some people seem to experience.
B
70
S
27
G
32
Posts: 476
Reputation: 19,573

Post » Wed Apr 15, 2015 7:48 pm

Jayjay wrote:I'm just pointing out that the less layers involved above DirectX/OpenGL, the better the performance and control over his own program that Ashley will have.

Yes, but at the cost of development speed. Also I think "control over his own program" is a bit of a dubious statement. By giving up on code provided by browser vendors to work around limitations, bugs and incompatibilities between different configurations/hardware setups, you're absorbing responsibility for overcoming those problems yourself, polluting your codebase with patches. The way I see it, you lose even more control over your own codebase, since you keep having to put dirty hacks to make it work with another set of "third parties".

Jayjay wrote:Of course going down anywhere below C++ and a graphics API is entering into layers that I would never expect a lone developer to code for, but pretending that HTML5 works how it was supposed to at the export side of things has to stop.

The future (for now) is javascript, that much is pretty clear - the discussion is whether things are moving at an acceptable pace (you say they're not, I say they are). Unless something changed and I didn't notice it, tech such as NaCl and PNaCl aren't moving forward. Even if you think HTML is a bad choice, what other option do we have? Haxe is a pile of garbage documentation-wise, just look at their tutorials and try to follow along - it looks like a graveyard of broken changes - nothing ever works like the docs say they should, and even the standard library is unstable, not to mention the libraries/packages (which are third parties, btw). So what about a native exporter for Android? Well there's no such thing: android apps run on top of a virtual machine, and even before that mobile games used to run on j2me which is now extinct. I pity the ones who developed an exporter for it. Oh wait...

Jayjay wrote:Maybe if there was one console that could actually run REAL games (made in HTML5/WebGL from C2) well then we'd all be happy, but as long as everyone is using a million different devices and platforms, the ability to have my game work badly across all of them is no good compared to just one export platform running perfectly across the majority of my customer/userbase

That's the whole point. Everyone wants that. Your choices are:
  • Haxe - broken spec, outdated/wrong docs, small community, not production-ready
  • Java - they haven't delivered on their promise of "write once - run everywhere" yet, why should they start?
  • Air/Silverlight/whatever - so, like, wrappers? Also, as you can see, they're all dead by now
  • HTML5 - big performance leaps every year, growing capabilities, multi-billion dollar investments, humongous community, and we already have dedicated HTML5 devices

Jayjay wrote:I can do enough in Construct 2 to make my games, the bug fixing and runtime performance is all I need to be happy. Editor-side C2 works way better than any engine as-is for 2D games. I see no reason to update the editor aside from making it easier for plugins like Quazi's Q3D to control more of the GUI.

The runtime already does nearly everything I want it to do, it's the editor that gets in the way. Developer time is much more valuable than machine time! When I making/use external tools to simplify development I feel like it's a huge waste of time, that I'm fighting the IDE more than being aided by it, especially considering there's no easy way to integrate tools to the IDE (without going through ashley, a la spriter) so you're forced to close the editor before using them (since they modify the XML directly). The interface is the biggest hindrance for gamemaking for the kinds of games I like to make.

Performance on the desktop, at least for me, is great. Mobile games have good performance as well, even on my comparatively ancient Galaxy Note 2, provided you keep in mind that mobile devices are basically toys

Image
Pictured: a modern mobile device compared to a modern desktop computer

Most mobile games are a joke, the top selling games rarely have more than 50 sprites on-screen at a time, and yet you see people here wanting to create mobile games with 1000 sprites, all with physics enabled and two/three effects, and hand-painted full-hd rotating backgrounds. Native isn't going to get you there, and even if you were a programmer god and could create and engine entirely in handwritten ASM, I doubt it would do it either.

If only people would publish their games for others like me (or Ashley) to pick apart, we could point out the problem and optimize them. Heck, I might even sell that as a service.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 9 guests