Aphrodite's Forum Posts

  • Softloulou Aphrodite

    Gianmichele wrote about auto updating webview in Android 5.0:

    Honestly I'm a really scared that an auto updating webview, more than nodewebkit, could break a perfectly working game without any action from the user (or even knowing it really).

    Ashley replied:

    Google already manage to do this without breaking the entire Internet, so I'm sure apps will be fine too.

    ***

    so everything is fine...

    not related to webapps/webgames but more to webview-based exporters (exporters which are not something I can really think is great, since they are prône to monopolising and they sometimes just interprets standards the way they want and they break the multiplatform support, as cordova based projects will run on android and iOS only, so you have to export one more time for other platforms, while a web game just runs on all platforms that possess a browser supporting the standards, the only reason to justify their use is either to sell them, or to use lower level interactions with the system).But again, if you choose an exporter suceptible to break when the webview update, you should already know that beforehand.

  • how do I compare the values of an instance variable for all the instances? I want to know if a certain var has the same value for all the instances.

    condition

    Sprite>instance variable equal...

    system: compare two values (Sprite.Count = Sprite.pickedcount)

    may work.

  • Softloulou as far as I understood it, if you plain to make an html5+js browser game (your last post makes me think that), even without C2 this chromium issue will be on your way (unless you rely on somekind of plugin to make your game work, but that is another constraint for the end user, and even then other issues will be presents I would think)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I think that, internally, layouts do not exists like we think they do, so " change layout" is basically just destroying the objects that are not global, destroy the layers, changing the LayoutName value, change the event sheet (already too late), creating the new layers, creating the new objects, apply the on start of layout.

    could be wrong though.

    still thinkiing that a internal flag verifying that this transition is not happening could be nice to have, but maybe it would be bad regarding general object destruction perfs wise.

  • not sure that would work, but maybe editing the index.html to change the part where it calls the c2runtime.js to make it call the Source/Runtime.js, and placing the c2runtime.js in the source subfolder and rename it Runtime.js ?

  • jayderyu agreed, C3 is not even a clear concept yet, it was just pronounced from times to times by ashley as a potential next generation of the editor, so the hype is just wrong, too early to even start thinking about things, all we can want is for C3 to improve what C2 could not during his lifetime (which is far from finished).

  • to be honest, even without the Wkwebview bug itself, a condition to test if a save exists, and an action to delete a save are still something people can expect to find by themselves rather than having to build it with the webstorage (some people say it is not hard, true, but it is just troublesome and feels like a feature incomplete, the same way being unable to reset persistents objects was).

  • well, to be fair, micro-optimisation is always context dependant, if there is really a check of every instances with pick by uid, that would be bothering if your game needs it, but nothing if it was not that used in your game, same goes with collisions optimisations (even though those can be easily the bottleneck), etc... But in that case, if the pick by uid would be wasteful, that would be dissapointing.

    always have a critic eye over ashley's blogposts, as he tries both to talk to people that can go really far in wasteful design and also he tries to be general and so, something true can become false depending on how you did your game (the recent render cells are a micro optimisation for a lot of games, it can even be worse, but in some defined cases, it is nice and can save out a lot of time), learning to identify what is really causing trouble is something that will help you in the long run.

    also have a critic eye over other people talking about their experiences too, for the same reasons.

  • How can we find out how the Object.PickByUID action specifically works? If it has to iterate every object instance, it's pretty bad. And I agree, being able to pass object refs into functions would work perfectly. If it iterates all instances, I'll be forced to building some kind of behavior like I described in OP.

    one solution would be to try to pick it (no associated actions) with an awful large amount of instances, and compare that to not doing anything.

    even though I think it was pretty much direct IIRC.I would think that is what C2 actually does behind the scène everytime a picking is doen: get the list of selected objects, and for each pick by uid.

  • Would my project run if webgl would be set as render but wouldn't be supported? Cause my projects run.

    if webGL is not avaliable, it falls back to the canvas2D which should look the same (but slower and without effects) even if you set webGL On in C2, the renderer system expression returns either canvas2d or webgl, so you can check it is using webgl or not with it.

    alternatively opening a new url with chrome://gpu as url in node webkit might say the informations regarding the gpu compatibility (by doing it in node webkit, not in chrome)

  • I guess technically could be possible (after all, a sprite is showing part of a spritesheet when you think about it), not sure that a behavior would do it however, I think more of an effect or a dedicated plugin for that use, not sure someone did one.

    alternatively, the paster plugin could work:you paste a part of the big image.

  • well, there is an experimental plugin for that it seems:

    never used it, but some people in the thread seems to have good results with it.

    hope that helps

  • sqiddster would just using the browser object "go to URL" chrome://gpu/ works to see that (I am not on my computer right now)?

  • I kind of fail to see why there is still those "get rid of html5", no, it is not "fairly new technology" the thing, but relying on 3rd party was one of the most important aspects, and I could be wrong but everyone should have already known that fact at the time they bought it (if not, it is not my problem but either scirra's or yours so I feel like I can say that without too much trouble), not that it does not bother me, but I knew it could have been an issue. And also I would bet if scirra did not had gone for html5, there would not have been C2, but nothing at all, not like it was a choice, but that is not even the issue.

    The same way I would not use a screwdriver to pin a nail on the wall, C2's problem is not html5, it is not relying on 3rd parties either, that is what made it altogether, C2's issue might be trying to go outside of its realm while not doing it completely: you either go full and rely only on the operating system itself (natively), or stay in the browser realm, by taking simply the browser out of the customer equation (as you choose it for him, which is not your job at all), you break that chain and become responsible for no good reason.

    When I saw first time the awesomium export (which was the first exe exporter), I liked the concept but feared 2 things, and who would have known, both happened:

    -html5 is still an unviable target for multiplatform games (not because of performances obviously, but because it is easier to go squatting other platforms rather than using this one), C2 can handle really nice games on desktops and mobiles and tablets (won't run on iphone4? only useful if you target it), yet most of non wrapped games are simple templates it seems.

    -rely on 3rd parties when it should not be the case: browser gaming (or browser activities in general) rely on the browser interpreting correctly everything in a fast way, that is completely fine for reasons I should not have to describe on an html5 game engine forum, however, wrapping your games just does not cut it, the performance improvement do not exist (or is very low), you still rely on an interpreter to do the job correctly (and it can fail pretty miserably), even if they are working correctly:What is the point? distribution and selling? Seems more like a shortcut to NOT correct that issue in the html5 platform. Functionnalities? Makes sense, but most of what I saw were just adding advertisements to android games, which is doable in an html5 game (even on a webpage), and if that is not the case, that is not the technology that is limiting us, again.

    The same way emulators are not affiliated with the consoles manufacturers (apart from SEGA and their genesises emulators), wrappers (which emulates a web environnement) should be the responsability of the end user of C2/or the end user of the game itself, and not something that is a "feature".

    however if they go into C3, they can do whatever they want, since it would be a new program subject to another license, other objectives, etc.. but for C2, deleting html5 would be not only sad, but would also counter what they are saying they are selling (which is an html5 engine).

  • Well, as long as we don't throw away the html5 export, it is fine (that is what I paid for, and that only).

    however I would love to see the end of wrapper support alltogether:

    not saying replacing them with native exporters (it can be done, but that is not the point of my request), just throw them away, wrapper specific or browser specific features are not something that should even have been done in the first place, if someone wants to have a wrapper specific feature, either let them implement it themselves, or give them a base to work with delivered AS IS with no warranty whatsoever, same goes with the exporters, wrappers are made by third party, and none are to be supported by scirra, C2 produce Javascript which I would really hope is based on defined specifications, then the wrappers interprets that, so "official support" just means you are doing the work backwards.

    actually, phonegap is not the future at all, it is either based on the OS version (and so will be outdated with time like IE was), or is updated without the app itself, which can be disastrous too, crosswalk and node webkit are fine, but I still do not see much point in using them for more than half the applications (speaking technicity wise, the browser can do almost the same for most apps I saw, only being paid can justify that use, and sometimes it is not even the case), and custom engines are also prone to issues and incompatibilities too, my point: do not support what you cannot, the users can make them work, fine, they cannot, too bad, not your job, when cocoonJS canvas+ got deprecated, it went better for a time it seems, see the pattern?

    3rd party exporters are to banish from C2 itself, from the homepage too, if that means not being replaced with anything, that is fine: wrapping by hand is not something that should be known by the users I think, as it is not related to C2 at all, I just want to see that being completely done (there is no real complete support anyway, so the change is minor).

    apart from that, not many complains on my part.