Aphrodite's Forum Posts

  • I would guess this only makes a difference for high-DPI displays (aka: display with a lot of pixels for a relatively small surface), where the result may be in the order of being a detail, so I guess for devices with an awfully large resolution for a really small surface setting it to no could improve performances at a cost of the graphic quality.

    as for the mythical low res, I would guess it would be the actual width and heinght divided by the "DevicePixelRatio" (I looked that expression inside the manual page of the browser object

    "The number of physical display pixels per CSS pixel. This can be a useful indicator of display density. For example, 'retina' displays report the value as 2, whereas ordinary displays report the value as 1.")

  • "Can't fix it

    Don't care - the fix can wait till google is ready

    HTML5 is not ready for serious workloads - like games"

    We all know that 2 is the anwser, they broke it so they can fix it, and html5 before that went really great for gaming, however that is getting ridiculous at this point, it is not like they think of chrome as a simple browser, how could that kind of things go into the stable channel, the nice part is that there does not seems to be a way for us to fix it (so nobody will simply workaround that).

    I know the situation will get better, and as a non-wrapper and non-profit user it really does not matter for me what happens to node-webkit or crosswalk, but that makes me wonder about who is really trying to do what, like it is not the first time the chromium takes décisions that bothers everyone (the XP and Vista dropped support, sure XP is not backed up by microsoft anymore, but Vista I am not sure.), however the fact is: if firefox got broken, or even opera, the situation would not be as bad, that is plain stupid, we should not have to rely on how one browser is performing, how did that happen?

  • Do not include that much license details in your post please.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Prominent

    "However, triggers are an exception. See the green arrow to the left of Keyboard: On Space pressed from the previous example:

    Note the trigger.

    This indicates the event is triggered. Rather than running once per tick, this event simply runs (or "fires") upon something actually happening. In this case, the event runs when the user hits the Spacebar key on the keyboard. It is never checked any other time. Since triggers run upon an event happening, they aren't checked in top-to-bottom order like other events. This means the ordering of triggers relative to other events is not important (except relative to other triggers of the same type, since triggers still fire top-to-bottom)."

    https://www.scirra.com/manual/75/how-events-work

    and yes, there may be work behind the scene to make sure the trigger actually occurs, but in their essence, they rely on something happening rather than on state checking.

  • Also, more events is not obligatory a bad thing, if done right, for starters, one could think the number of events is a direct representation of performances, and that would be completely wrong, as the number of events is for the entire project, not for every single layout, and due to how event works, it is more than likely that if you code the right way (avoiding unnessecary work for the browser), the events really have an impact only when they are needed.

    also, always prioritize in that order:

    -organisation, first, never think "yeah, even if it is badly written, that is fine", and NEVER EVER think "if I organise it I might lose performances". Groups, Includes, functions, global and local variables, all neat tools you have at your disposal can help in some case.

    -flexibility: can you make some parts of your code more flexible? if so, you should try, that may really helps in the long run

    -use features, they are here for that, but don't overdo it. Sometimes I see people using features just for the sake of using them even when this is not the case where it is meant to be used (I will not talk about "lerping movement" again, but keep in mind that if a feature does what you want, use it, however if it is not it is meant to be used for, either do not use it or add a comment to be sure someone can read it correctly).

    -reduce redundant code, functions and families are great for that for instance (might not reduce the actual number of events, but at least it will be cleaner).

    -and last:performances, performanes should always be your last concern, you can optimise clean code every time you want, but dirty code is unusable.

  • Sumyjkl , up until now I've naively assumed that adding the "Trigger once while true" somehow "converts" the event in to a trigger! Can you please confirm that adding the "Trigger once while true" condition into an event doesn't affect how often the system checks if the conditions are met and that it does indeed update/calculate every tick?!?

    a trigger just happens (the on collision being the black sheep of the list, as it stil requires quite a lot of work), where an event with trigger once requires to check every tick if the conditions are true or not.

    also, you can put a triggered everywhere, the result will be the same (unless you have two of the same trigger), while an event with trigger once still depends on its place inside the event sheet. Triggers can happen multiple times per tick(function object being the all time representant of that, on created and on destroyed too), trigger once cannot (Is overllaping with trigger once will not work if multiple overlaps exists, as the event will be read only once in total for this tick).

    triggers are almost always better than their cousins "check but trigger only once" when you can use them, as they do not check things every tick, they just happen (and can happen outside of the every tick logic, like you press a button, it should fire even if you are not currently reading the event sheet.)

  • Merry christmas to you all!

    my plans? family.

  • I can confirm that when the window size was bigger than the window size parameter, I could see it (never reported it as I though it was really just my computer since nobody talked about that a lot in the past, not sure if the ratio between the real window size and the specified one is the culprit, or directly the real'size itself)

    however, with no scrolling actions, it is not as visible

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

    https://www.scirra.com/manual/126/system-expressions

    I think it will work without you needing to change anything.

  • Ashley when the player dies in sbperftest, it seems it restarts with a very large amount of ennemies and projectiles, is tgat a part of the test, or should that be ignored?

  • the "on destroyed" is a trigger, it will fire when the instances are destroyed, this happens just before the layout ends (so using an "on end of layout:destroy" may work), IIRC it has already been reported but was closed as wontfix, but that could change.

    other workaround that is cleaner:having a variable that changes just before you ask for a layout change, the value of the variable influencing if the "on destroyed" will work.

    Still hoping for a definite fix.

  • "As simple as one text object changing every tick getting the same frame rate?"

    IIRC drawing a text object is not an easy task at all, it has to recalculate entirely how to render it for each character, if you try with a spritefont instead, you might (should) not have that issue.

  • sqiddster so you mean they are directly affected to the number of pixels to draw on screen for each frame, or to the total surface of the viewport?

  • well, browsers (or wrappers), have their own rendering engine, which explains the difference greatly (for instance, the current version of node webkit and chrome have rendering issues that really are problematic, smoothness being completely impossible, maybe crosswalk inhereted that bug too), on the other hand, IE seems to be pretty fluid, basically it is not really a performance problem, it is just that the current rendering method of chrome is an "epic fail" if I can say so (three months ago for instance, we did not had that problem), as for performances wise, I do not see really anything wrong with it currently, crosswalk did a good job (until recently maybe?) to have smooth gameplay on every game I tried, where canvas+ was jerky all over the place (this seems to occur only on some devices If I believe what others says), but then again wrappers are secondary, and I think the fact every wrapper suggested by scirra relies one way or another to chrome only was really a bad choice (it is a freaking html5 engine, why should we have to rely on one specific engine that may fail us once again), heck, even the fact scirra recommands only a specific list of wrappers is questionnable.

  • Aurel

    sqiddster

    I was more asking about not the input lag, but the general feel of the game with out-of-sync or variable framerate ( aka framerate drops) under firefox (terrible under chrome, definitely).

    since if we can find at least one browser engine where the situation is not terribly wrong, that will give more weight to the argument itself!