Aphrodite's Forum Posts

  • If you skip PNG recompression isn't it a near-instant export?

    I think the idea is to not reexport the images but keeping the already compressed ones obtained inna previous export

    Unless skip png compression checks the already present images sizes before replacing them?

  • You should not use only one event sheet, it will not help when you need more organisation, also if you really think you will go into performance issues, do it this way:

    First make a working prototype at a smaller scale, just working, do not think about optimising yet

    Then try to organise it well, so you can modify the needed part easily, read them quickly, and know where everything is

    Then see if there are redundancy of actions or conditions (you should not have to recheck the value of something twice inside the all event system, you can if that helps you organise it.)

    Then see if there are checks or actions that are done in case where it does not matter (exemple, checking if an the player is alive constantly is not needed, just check that when needed, same goes for updating the hud or other things.), if you do not find them all, it is not a problem at all, it is just to make the events of the prototype easy to read, and to write, yet performant enough.

    Do performances measurement, see if you need every element of the game to exist (pretty sure you don t need every thing to exist everywhere on the map at everytime), so if there is a problem, try to deactivate behavior or to destroy uneeded object, keep in mind that when you are not targetting old mobiles, performances are pretty good in C2 so don t go into try to optimise every event and go into micro optimisation, not only it takes time for absolutelly nothing and makes everything harder to read, but also it won t help you learn how to design correctly your game, try to see what is needed and when it is needed, so you can make the device have less calculations to do.

    Tl;dr : test early, see if it is working, organize, see if it can be optimised by not checking useless things, do not try to optimise every single event you make, learn to see what could cause a performance drop in which case, so you don t fall into the trap a lot of people fall into: "optimising everything, except what needs to be optimised"

    And remember, working code is your first priority, then organisation, then flexibilty, then performances adjustement, if you have a optimised code that is unreadeable nor flexible, you are going to have a worse time that if you have a code that is clean but needs performances adjustement.

  • So you are saying that if I use only one tile and rotate it, there would be only 1 draw call for it (instead of 4 draw calls for 4 tiles). Also, are draw calls used when the tilemap is invisible ?

    Rotated tiles are considered as different tile for rendering I think

    And the draw on screen is skipped for invisible objecs, so the draw calls should not be a problem

  • Identical tiles within the same rectangle are only drawn in one call (as long as the tilemap is setted for that, which is by default), I am not sure about collisions, but I would think than less collision points and less tilemap with collision enabled would be better (enough to make a big difference that justify doing it? Not sure.).

    I personnaly remember doing once in a bubble bobble type of clone (never really gone too far yet into it) having different tilemaps (one graphical only with collisions off and one that used collisions but set to invisible), that would let you have a collision different than the graphics if you want it that way.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I remember a time when I could not run some virtual servers with skype, I had to reconfigure skype so it does not use the same port, not sure if this is related though.

  • If your global variable name is Timing (in seconds)

    Use floor(Timing/60)&":"&zeropad(Timing%60, 2) to display it in a minute:seconds format

    I did not test it out but it should work

  • Thanks, will try to see if there are other unconsistency between the manual and C2 itself

  • loved the first one, pretty sure I'll love this one too ^-^

  • The page of the system expressions ( https://www.scirra.com/manual/126/system-expressions ) state currently that CanvasToLayer and LayerToCanvas functions take (layer) as a parameter, in fact they take 3 parameters:

    CanvasToLayerX(layer, x, y)

    CanvasToLayerY(layer, x, y)

    , same parameters for Layer to canvas.

    Not a big issue, but since it is correctly stated in C2 itself, I might as well indicate it inside the manual.

    Also an exemple for the lerp would be appreciable, since I see a lot of people using it in a non intended way (just an exemple saying if x = 0, returns a, if x=1, returns b, if x = 0.5, returns (a+b)/2 ), but it is only a suggestion (the way people are using it is to set x to a constant, and set a to lerp(a, b, x), which results in a movement towards b, slowing when approching b, never reaching b, and that leaded the community into saying sentences like "the sprite is lerping to this position", "lerp is meant to be use to do an ease in movement", which just does not make any sense, and also tends to make people think x should be multiplied by dt to be framerate independant, which won't work since x is not a time of any kind).

  • this page of the manual, in the Math paragraph, is quite useful in some cases (since it shows the predefined math functions you can use in C2 directly): https://www.scirra.com/manual/126/system-expressions

  • I would say 3 things:

    1/lerp is not meant, and should not be used the way I think you are using it (set Y to lerp(Self.Y, finalYposition, speed) I presume?), and it will also result in an anormal curve.

    2/a quadratic formula to increase the player speed to the bottom should be used in this kind of movement

    3/ The platform behavior actually does the 2/ by itself, so I think it would be wise to consider using it.

  • In C2 angles are in degrees, basically,an angle + or - 180° is the opposite angle due to the cyclic nature of angles(adding 360°, aka a full rotation, is the same as adding 0, (360+0)/2=180 so you have half a complete turn, thus the opposite direction)

    And angle(x1, y1, x2, y2) return the angle between the two points

  • This post was originally going to be on another thread, but I went off track so I decided to post a topic in the open topics for it, so ladies and gentlemen, shall we begin?

    I think the chrome audio issue was a sort of honest mistake from scirra (using a beta feature of chrome in a good chunck of versions), but even then I still think relying on chromium devellopers not breaking things is an issue.

    With node webkit, you have even more things to consider than in a browser, and same goes for all wrappers out there.

    The problem IMHO is that while those wrappers sort of work, they are still just an ease of distribution: Most of them don't have a big advantage compared to the browser themselves except from their "appearence" (not sure how to call that). Crosswalk suffer the same problem compared to chrome for android, and cocoonJS is ... cocoonJS, not really much to say, and awesomium was just not up to the competition.

    Node webkit is a part of C2, as it is distributed with it, but it is like free advertising for node webkit that is hurting scirra more than it helps it, at first it could be done without the need to be implemented with C2, you can still do it yourself, only the node webkit plugin justify its presence, and even then, it could have been just a third party or optionnal plugin.

    At first glance from my side, if I am correct, C2 was shipping with some third party wrapper for mobile only, because due to html5 performances on mobile at the time, it wasn t possible to say "mobile compatible", heck even on desktop it was not clear since webGL was not implemented in all main browsers (chrome only?).

    Today I fell like those wrappers are not needed, I know, they are needed in a way, since there is no good platform to sell html5 games, but it is funny how people at first were (and still are) saying that html5 and browsers is not good enough for "real games" while it is currently the "better" version in C2 performances wise (unless there are weird forced limitations).

    In fact, it is not that they are not needed, it is that they shouldn't had been shipped with the software itself in the first place (again, my 2 cents), since you should be able to convert them on your side, I think there are html5 wrappers outside of C2 compatible with what C2 produces, sure they may not work, but I feel like a non working wrapper not included is still better than a non working wrapper included (I remember someone trying to do a wrapper based on firefox, not sure how that went, I think it was working, but I do not remember of the licensing), some will say that everything is based on a third party (windows, the hardware itself, etc..), which is true, but we are adding yet another third party over that, no, it is even worse, we add multiple third parties that are concurential and even worse, not really working as they should (node webkit on other OSes needs some tweaking, cocoonJS is..dammit it is cocoonJS, it has been broken long enough for the name to speak by itself, crosswalk is trying, but nothing prevents that to fail us someday, phonegap actually call directly a browser inside the device so devices will advance, the phonegap export should become better...if it does not break, but I am more confident on browser compatibility than on third party compatibility, since that is for browsers that C2 was intended to work, ejecta I do not know, and html5 itself is working quite well as long as browser's betas feature are not used in stable versions for too long).

    As for a solution, I do not know, scirra cannot just make a wrapper from scratch, they could base it on something I guess, since it is too late to retract now, a native exporter could be nice but really hard to maintain correctly, I would say the wrapper not third party based of an existing wrapper would be fine enough, since scirra would have control over it, but again all of this is just my opinion.

    If you have an opinion on the subject, you can reply ^^

  • What I meant was fixing the size to 800xX in the project proprities beforehand, with a scaling mode (like letterbox scale, scale inner, or scale outer), so the objects will adapt to the screen size if it is different compared to the specified screen size, and using the node webkit action set width and set height at the beginning of the game, you could ensure having a different size that the one you have chosen for the web version.

    The fact being that the assets themselves don't have to be changed from one version to another, just make them big enough for the exe version.

    I hope I am clear enough

  • You can set the window size to not be over 800 px wide, while keeping your assets at the size you want, the exe version if I am correct, can be increased in size with the set width and set height actions, which could result in what you want.

    PS:that works because C2 by default will scale up and down the graphics before rendering, so the assets quality will define the graphic quality, not the window size setting.