ca59eb38-e0ad-4975-9634-a2379c986d93's Forum Posts

  • You do not have permission to view this post

  • Well, because i'm using an older version, i really don't feel like checking the files out, but from a really quick glance at it, you could replace the series of repeated events with a function call (a separate object you have to add).

    Furthermore, you could nest the 201 and 202 events (drag the one below slightly below the 201, when it becomes a sub-event, delete the common conditions). This could probably be done in other places too.

    Sorry if this isn't much help, buddy... :/

    Update.

    Not related exactly to your inventory system, but you really should disable the retina display option - it's a performance hog.

    Just check the results in the performance benchmark that was done for C2 a while ago. The difference was 20x in some cases.

  • I believe that the above would be executed each tick, therefore you really should consider adding a "Every X seconds" condition to the event.

    Something like 0.05 should do nicely (done 20 times per second).

    Also, if you'd like something more complicated (with the paddle accelerating, instead of merely moving), you could try a custom movement behaviour and compare the axial speed and coordinates, if speed towards the needed point is below the maximum allowed, then add acceleration to the paddle towards it every x seconds.

  • Well, if no physics are used, you could basically monitor if keys are not held down + if the player is not jumping/falling (if you care about vertical speed too) - if both are true, then the player is not accelerating. Without external factors that affect the speed, this would be accurate until the moment when the player reaches the maximum speed (e.g. moving at the maximum velocity, which is constant), perhaps adding a "is speed < maximum speed" check could prevent this.

    However, these checks probably would be less efficient than just updating a single variable (e.g. "PreviousTickSpeed").

    Then again, none of this should be too important, as drawing processes usually take up most of the CPU / GPU resources (usage commonly said to be around ~90%).

  • Well, this is often said about threads like these, and i guess i'll have to say it once again: you aren't being very descriptive, bud.

    Could you provide us with a .capx file of the game in question?

    Or, if you don't want to do that, could you at least take a couple of screenshots of script sheets in question / what is happening on the screen?

    And if you don't feel like doing any of those things, could you at least say something more about your problem than the current "Turrets OP! Wat do? Halp!"

    Sorry if i come across as mean, but we really need more details to speak of a situation...

  • Here's some (probably bad) advice:

    why not a pre-animated, semi-opaque sprite (or a couple, across different levels) with blurred edges and blend mode set to something like additive?

  • Wow, the interface is just...

    ...so professional!

    I'm loving how well everything fits together,

    but could i inquire about the resolution you are making the game in (or did you just use the aspect option in C2)? What about the actual sprites?

    I am just curious about what's used by others for mobile games. :)

  • 1024x768? My netbook must be so bad... ;_;

    Either way, good luck with your game!

  • You really shouldn't use the tiled background object for filling the screen with a single color.

    You should either of the following:

    use the background parameter (in layer properties) to fill the screen with the color you want

    create a layer that doesn't scroll (don't remember how exactly, might have something to do with parallax settings (0?)), have a 1x1 pixel image of the color you want added to it, then stretch it to your screen size (point sampling might give you better results)

    And contrary to the beliefs of the guys here, i'd say that you should go with slicing up your image into smaller parts, here's why:

    i read on one of the threads you can find here that the objects that are off-screen are not drawn, therefore don't take up some of the time needed for rendering a frame (however the images are still in memory, so there's that), which means that if only a certain part of your whole level will be visible at a time, the images that are off-screen won't take up the systems' resources and you should, in theory, have better performance than if you just used a single huge image. Or something... /speculation

    Using a plain color background would still be faster than using a sprite... :/

    If you'd like to know more about the performance optimization, i made a thread recently, where i asked for feedback from others on my views, but it appears that it's gotten buried now.

    Here it is: scirra.com/forum/optimizing-a-game-for-mobile-platforms-your-tips_topic78778.html

  • I like how consistent it feels, however the performance seems somewhat bad to me (then again, i am currently on my netbook) for some weird reason - is it possible that you used a single, big resolution image for the background or something?

    Also, here's a tip - make the collision polygon for the character smaller, as it is currently possible to "hang" off of ledges, if you approach the edge slowly (or add a physics behaviour). Lastly, it would be nice if you added a death animation...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I am not entirley sure about this, but can't you just use the newly added debugger functionality to see how much memory/CPU power the game is consuming and just look at the file size on the exported/built app to see what the download size will be like?

    Of course, if you'd like this sort of feedback in real time while running the app without using the debugger, i'm sure that you could just create a text object on a static layer (always in the same position on screen) and update the text how often you desire...

    Something like:

    Every 0.1 seconds -> Set text to

    "Renderer: " & renderer & " FPS: " & fps & " Image memory: " & ImageMemoryUsage & " CPU use: " & cpuutilisation & " Objects: " & objectcount

    Which would show you the renderer being used (WebGL/canvas), the current frames per second, the memory used for images (works in WebGL only, apparently), the current CPU usage and the amount of objects...

    As for viewing the data in the editor, however, i am not sure...

  • You know, i made a post about this just today:

    http://www.scirra.com/forum/optimizing-a-game-for-mobile-platforms-your-tips_topic78778.html

    Sadly, the formatting was somewhat messed up by the forums, so i had to re-host the thread elsewhere, i opted for creating a gallery of screenshots on imgur with the links attached.

    The point of the post was to ask for more tips, but i guess most of what i've listed there is valid as well, even for PCs.

    Also, here are direct links to other articles about the subject:

    Best practices - scirra.com/manual/34/best-practices

    Performance Tips - scirra.com/manual/134/performance-tips

    Performance Tips for Mobile Games - scirra.com/tutorials/298/performance-tips-for-mobile-games

    Remember not to waste your memory - scirra.com/blog/112/remember-not-to-waste-your-memory

    Optimisation: don't waste your time - scirra.com/blog/83/optimisation-dont-waste-your-time

  • From all the people on this site i am probably the least qualified to answer your question, but after messing around for a couple of minutes i'd at least like to offer you something to pass time until one of the more skilled fellows comes along and makes everything right again. :)

    Well, first off, i opened your example, however i found that it ran too badly (my laptop doesn't support webgl), so i made my own one - a bit simplified, yet seems to work decently.

    dl.dropboxusercontent.com/u/80437109/mybuckets.capx

    Now, it is made on r142, so there might be bugs in later versions, but i at least tried. The example itself should be simple enough and i put in a comment or two there too (<30 events).

  • You do not have permission to view this post

  • You do not have permission to view this post