Aphrodite's Forum Posts

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

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

  • Toddler while it would make sense to have trigger for everything asynchronous, I will admit that it can become a huge bother, and being able to stay in the realm of synchronous events would be nice when asynch is not needed and will be bothersome to implement.

    Or rather, finding a cleaver way to make those asynchronous events work would be a benediction, for now we just have AJAX, and saves, and now local storage, and yet people stuggles when dealing with that, sure a trigger is the current way of doing it, and it is not a real issue with storage (as saving datas should be something done at one specific point rather than constently in game) but as more and more feature would go that way, it will become unusable pretty quickly.

    Async storage is not the problem, Async events are in general tricky to use, as they go against the spirit of the event system. And we cannot just say "No" to those, as they can be pretty useful, so a solution has to be found.

  • I am not convinced, I mean would not that be exactly like using a dictionnary to store the keys while saving them? And if so, would that not compromise the whole point of it being asynchronous (Aka:whendealing with a lot of keys)?

    unless I misunderstood and you mean having basically a dictionary with a "Push to Local storage" action when needed, but even then, I feel something is not quite right..

  • I will admit that everything asynchronous is something hard to keep up inside C2's event system (which is based on a from top to bottom logic, with events needed to be complete before the next)

    Toddler maybe you could use a dctionnary, and save that dictionary to the Local Storage (since the dictionary values are setted ASAP, you will not have that much trouble).

  • While tile maps don't benefit from render cells, they work in a same way with collisions cells, and so, by default, tilemaps are scalable easily to a far larger world size than the screen.

  • I woukd have thought that you would rather just increase the layout size in that case, but I agree this limitation, while not problematic, is just weird.

  • If you are using crosswalk, I think you need to upload both architectures on the google play or else some devices won't be able to run it.

  • i'd always use math.pow (pow in events), using ^ sometimes gives wrong results because in javascript ^ is not pow really.

    If it is not in javascript, that is not an issue, the issue is that the C2 manual says it is in the context of C2, also, the issue is not the returned result itself, but the wrong order of operations, which is plain incompatible with how maths are defined.

    https://www.scirra.com/manual/78/expressions

  • Valerien the out of sync audio especially is an issue with html5+JS browser games on mobile (like, lets say, chrome for android that needs an awful time to decompress the audio, or with weird limitations of browser that though it would be better to wait for touches to start a music), not talking of games wrapped inside canvas+ or crosswalk since, let's be honest, we choose the wrapper while we do not choose the browser the user can use.

    However, one could argue that some definitively bad games can prevail while good games can fail (I won't give the flappy bird exemple again, there are others), while this case is rare (and should stay rare), it exists and can be a real moral killer.

    Just read your juiciness tutorial, pretty much what i call "polishing" the game, however I always struggle to describe what a game can do to feel more complete, less amateur, this is basically enough infos for people to understand now!

  • Round(Value/100)*100 will return:

    For value being 33.33333333333, it will return 33.33

    for 66.666666666, it will return 66.67

    for 10.50, it will return 10.5

    Round(value) will returnthe value rounded to the nearest integer.