Ribis in the scope of C2, unless webGL is off, the game is not entirely loaded into memory, it only loads the assets that the current layout is using, and unloads the ones that will not be used on the next one when swtiching layout.

Toddler funnily enough, I am pretty sure the destroying mechanic actually works like that, it just appear to be destroyed when you call the action, but actually is not yet (and might not be due to recycling).

as for the save, for retrocompatibility reasons, having a seemingly synchronous in option would be nice, as webstorage, while still being there, is still likely to be dropped.

I keep on searching but there seems to be no useful IE11 based alternative to NW. Sigh...

IE is not something as open as chromium, so finding a solution using it is unlikely, however, I wonder how a windows webview would work with C2 games (As I think it might be possible than the basic web control in windows is actually the internet explorer version associated).

C2 is meant to run at the V-sync, however, at 30 fps, the framerate may not be stable enough, and unstable framerate is worse than stable framerate.

That and the browser might f*ck it up, why do consoles go with 30 fps is something I wonder, a console is completely fixed hardware.

Also, dt is not here to cover varying values of the fps at first, but to make games work on different refresh rates (120 fps vs 60 fps).

winkr7

I wonder, not sure I get what the issue is, but do you mean the size of the elements on the screen (in cm) are too small while the size in pixel is enough?

Aphrodite

Thanks for the read, that makes sense to me now!

Interesting stuff, might try to read up some more on this stuff.

So we are basically hoping that the Chrome browser will improve and be developed with games in mind, and not something else!

- and if chrome someday, shuts down, or make radical changes. Then we are all screwed

If chrome shuts down, there are other browser engines that technically could be used so not really screwed, to be honest, we (by that I mean the people using wrappers) should already be looking for other alternatives for chromium, and since C2 is not a chrome only engine but an html5 one, it should be doable.

Irbis agreed on the fact some features are below what people might expect, and that sticking to one platform would have been better (I would have prefer sticking to pure html5 for the Web platform rather than trying to look like native, as it is primarily advertised as such, but that is just an opinion, now it is a mess, and wrappers can be just worse than Web, either way, something has to be done, right now it seems that the Web platform, the heart of C2, is something none of the actors want to improve, instead of having a valid Web platform, we have this nonsense )

Agreed also on a scirra full game, would be nice to prove us wrong on all fronts while knowing where we have issues.

— agreed fully on the "good practices", we should have some design indications like "a save should be done only at specific points, not constantly.

Reasons:

-reading and writing from the memory is fast enough to happen on a quick regular basis, but from a physical disk it is slow and you should not try to access those constantly

-if something goes wrong, you might prefer that the user have a valid savepoint rather than a save with elements that may contradict each others due to the fact a part of the save happened mid level before crashing, and another at the start."

xanxion my guess is that unity games are compiled with a custom compiler (or whatever it is called), which removes the browser issues entirely, after all, compilation is the way to do an executable.

C2 does not create an executable, it just place an executable that reads the web game (that is true for every single export method of C2), and wrappers in the context of C2 are:

-chrome (nw.js, for windows linux and mac os)

-chrome for android (crosswalk)

-chrome for android (cordova on android 5)

-something else on iOS8, not sure we can call it safari as the engine may be different (cordova)

Nothing is direct, and those wrappers can change (which explains why it worked sort of fine until chrome 44)

Where others are generally compiled, so direct (sorta, there are still the drivers in between) communication between the game and the hardware, no variations over time apart from a buggy driver, but since that can affect the entire system you can imagine they are careful enough to not break everythign as much from one update to another (Can still happen, but would happen also with the wrapper layer).

Unity can do html5 games too i think, but those are meant to run inside a browser and not to look like executables (and that is the way it should have been for C2 too I think).

xanxion my understanding of the situation is more this:

-native apps have a more direct control on the actual hardware, there are the drivers bug and other things, but it seems they would rather work around those (or the compiler do this behind the scenes maybe, I am not a native expert at all) so the result is tolerable, this and also almost no layer of abstraction can slow the app down compared to another app.

-html5 on the other hand, have a reliance on the browser or wrapper that reads it and compile it at runtime, which does compile something not done for that purpose at first (it still works fine), however, browser vendors are unreliable (same goes for non browser-based wrapper), which means if there is a bug, you simply cannot work around it, and ashley will not do it either (for understandable reasons browser wise, yet still stupid due to the concept of official support of a wrapper), then you have the incompabilities between a specific hardware and the wrapper (that can happen as browsers are an environment with a very large number of things that can happen, and most of those are not simple instructions being compiled but rather a large number of different things that every browser does differently), but since those incompatibilities are not the number one issue of said browsers (the V-sync issue in chrome only affects canvas content that refreshes every frame, not everything inside the browser If I am correct), and so they can simply decide that "this is not a big issue for now compared to this one".

Betting on html5 is not a mistake at all, far from it, however betting on browser vendors, or focusing on one, or even directly saying to the users that it is a good thing to use any kind of wrapper, and so take full responsability for it when facing your customers, is the weirdest thing I have ever seen, and I still do not understand how this happened. A webapp can have browser related issues, it is a layer you cannot control as the user chose it, but a webapp looking like an executable will have the same issues, and the worst thing is that by wrapping it, you have chosen to accept that as the "standard way the app should work", too bad in most cases, you did not choose that but rather just followed the suspicious "official support".

This is only my opinion on it, others may have more infos.

rexrainbow your cache plugin seems even more confusing compared to simply load the values from the storage when needed, save them when needed, and not using them otherwise since.. well, those are saved infos that you only need to load at certain times, caching them is not something I would want as I woukd rather use the original info rather than even trying to call this one, could be useful for somebody though I guess.

It's true that this new system is definitely overall harder to work with. However, maybe what we should be asking is, are our current Webstorage practices bad? I currently use Webstorage as a replacement for variables all over the place, and very often set its values every tick. Maybe that's acually in general bad practice? Disk I/O is expensive after all (afaik), and (maybe?) won't show up in CPU usage tables.

Could just be another case of C2 making something 'too' easy.

I think the manual could do with a lot more written on 'best practices'. It could alleviate a lot of confusion at times like this.

Indeed saving the datas in other places than memory is something you normally do on specific occasions, not on a current basis, here are some exemples:

-save points in many early games

-pause screen with a save option in most PC games (the user chooses when to actually save, and so, no need to save constantly)

-automatic save of data between level transitions

-in game and watch gallery, the game would actually save when pausing the game, so if the player quits it, when turning the power on again, it will remuse the gameplay.

-etc..

All in all, treating a save (and this local storage one Particularly) like a non-local save seems to actually be the way to handle it: when you save data over to a server, you cannot think it will be back instantly, this seems to work in a similar way, perhaps having this in mind may be easier, having the lowest number of data to save, and knowing when it is a necessity to actually save them or retrieve them, the same way you would do if they were on a distant server.

At least this is how it seems to work.

Nobody has answered my question and I'm genuinely curious.

Why is mobile performance of C2 games so bad? Is it the fault of the HTML5 wrappers?

Partially, users are partially faulty but wrappers in their current state are not that great, it was also hinted that it could be because C2 games runs only on one core, but that is something I am not sure about, more profiling tests and comparisons between wrappers and browsers would be nice to have to awnser that question exactly.

LittleStain

"The biggest challenge of programming is working within limitations and making it appear there are none.."

Very true, however, said limitations seems pretty blurry at the moment, which does not help as two systems can react differently while having the same type of hardware, and sometimes a better hardware will not support correctly something, hard to define the limits and so, to work with them.