tunepunk's Forum Posts

  • #&#!? Apparently there's another studio making a game called same as mine, i just found out. So I might be needing a new name. *sigh*

  • From what I've read, around 80% of any appstore game downloads will be from organic traffic by people searching the app store. So It's better to invest in:

    * Good description, SEO, tags, and search words.

    * Nice app icon

    * Nice Screenshots

    * Possibly gameplay video

    After that, it's good to get people talking about the game, so try sending out a nicely composed email to reviewers, youtubers, magazines, maybe local newspaper with a small press kit, and link to the game of course.

  • Ashley Thanks for a great high dpi stuff in the r230 update but you forgot this one

    Families dialog still looks wonky.

  • Ashley I Found this. I dont know if it's of any help but worrh to check out, regarding the touch/stylus issues in win 10.

    https://msdn.microsoft.com/en-us/library/windows/desktop/dd371581(v=vs.85).aspx

  • I did some tests of that. Constantly turning on and off collisions for sprites out of screen gave me a little bit of stuttering on mobile. On desktop I didn't notice anything. Could be that my scrolling was not using dt. But in general frame rate went up a bit and cpu went down. For Visibility I'm not sure. Easy to test though. Is not on screen. Visibility off, - Is on screen. Visibility on.

    While picking from many objects i found out that some ways to pick are better than others. A bit more info in this thread.

    https://www.scirra.com/forum/picking-performance-test_t178183

  • Here's a quick capx to show an easy way to do it. Very sloppy but i think you get the basics

    https://dl.dropboxusercontent.com/u/20560446/Scirra/psuedo3d.capx

  • Shouldn't be any problem. What you need to do is break down the images (enviroment)to foreground and background, probably in several different layers. depending on if the player can move in front or behind a certain object in the scene, and rebuild it in C2.

    While the character is moving in Y axis (depth towards horizon) make sure to scale the character as he get's further away or closer to the camera, for the desired effect that he is moving in depth.

    Then you compare the Y of your character with the Y of the object. If the character Y is lower that means he is further away, so should be behind any objects with a Higher Y, so you sort the Z order accordingly. Make sure to place all the default imagepoint at the base/feet (lowest point of each object). If i have time I can make a quick example for you.

  • Covering the whole screen/layout with something Is usually not very good. Have you tried the webGl effects? I also think i would be better if each shadow is seperate to each building etc. A bit tideous to place all the shadows, or maybe if you name all the sprites smart you can have events place all the shadows with code to each object that is supposed to cast shadows?

  • Looks nice! How many levels are you planning to have? Any bosses?

  • The point seems to be the filtering. Here's an image and capx of different events doing exactly the same thing.

    1. First way is super heavy as it does not filter at all, goes through all and does it.

    2. Second way is a bit cheaper as it filters by is on screen first. Very useful.

    3. Even better is this weird way. On par with behaviours. First Checking opacity across the entire layout, picking the closest one setting it to 50, moving on to the next closest one setting it to 50, until it reached the distance limit of 150. Another event does the reverse thing to set it back to original opacity outside the distance limit. Super cheap and efficient.

    4. Using the Line of Sight behaviour to do exactly the same thing, sligtly cheaper than no.3. Line of sight can even replace "is on screen" as an even cheaper substitute for filtering by screen size if you set the radius slightly bigger than the window width.

    Conclusion, there are some good ways to do things and some bad ways. So far line of sight, and 'pick nearest/furthest' seems to be the most efficient ways to pick/filter.

    capx:

    https://dl.dropboxusercontent.com/u/20560446/Scirra/differentways.capx

  • I was having some performance issues and tried to figure out what caused it, but i was pretty sure it had to do something about the picking. So i created a new scene to test it out, and these were the results.

    In my game i was using evaluate a lot, which seems to be very heavy on CPU. I was using it mostly because it looked neat to have everything in the same condition. But after doing this test I probably have to rethink a lot of my picking. Could anyone with deeper knowledge explain why some method is better than the other?

    capx:

    https://dl.dropboxusercontent.com/u/20560446/Scirra/pickperformance.capx

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I turned off collisions for my weather effect "paricle" objects because they aren't needed... and CPU usage dropped from 15% to about 8% when the weather is coming in "heavy".

    Having un-needed collision checks does seem to make a difference, especially when there's a lot of them happening.

    ~Sol

    Yeah. Turning them off is always good when not needed, but constantly updating on/off is another thing. I have one project where i turn off collisions based on if they are on screen or not, and if you're moving around a lot in the layout, The turning on/off seems to be causing some jumpy scrolling.

    Sprite - Is on Screen -> Collisions Enabled

    Sprite - Is not on Screen - Collisions Disabled.

    So if you have a lot of sprites constantly moving in and out of screen, switching from disabled/enabled seems to cause some hiccups. Constanlty Z ordering all sprites in layout seemed to have a similar effect, so I optimized my Z ordering to only sort objects that actually needed to be sorted. For my isometric game, I'm only sorting 2 instances at any given time, the one in front and the one in back, and only if:

    Pick by evaluete: Family1.Y > Family2.Y & Family1.Zindex < Family2.Zindex

    or

    Pick by evaluete: Family1.Y < Family2.Y & Family1.Zindex > Family2.Zindex

    -> Call function Order (param 0: Family1.UID) (param 1: Family2.UID

    On function "Order".

    Pick Family2 by evalute: function.Param(0) &function.Param(1)

    Family2 is on Screen

    -> Set Family2 instance var "SortValue" to. Family2.Y

    -> Sort Z Order by Family2.SortValue

    // This causes the the function to trigger only 1 time, since the function will sort only any objects that does not have the correct sorting, and all the previous events will be false, so no more sorting is needed.

    This blogpost explains a bit why Z order has to be preserved in render cells. That's why I optimized my Z ordering, but it seem's turning collisions on and off, on the fly is heavier than just keeping them on, and could be causing the stuttering I'm experiencing.

    https://www.scirra.com/blog/ashley/14/how-render-cells-work

  • After a lot of testing I've found out that one of the cheapest if not THE cheapest in terms of CPU load for picking/filtering objects is using the condition "Is on Screen", so I use it everywhere and filter by this first, if I can. I don't know why that's the case, but It seems to be so. Even if you write your own equivalent doing the same thing with events that condition (is on screen) seems to be a lot cheaper CPU wise.

    Maybe it's because the "is On Screen" is working under the hood in a much better way.

    This is the case especially if you have many objects.

    So here's some useful Sprite/Family picking conditions that should be considered in the sprite/family conditions dialogue.

    * Is within distance/radius to (Filtering if XY are within a certain distance/radius)

    * Is Intersecting BBox (Filtering if other sprites/family intersecting the BBox) VERY useful.

    * Is within angles of sprite angle (Filtering if XY is within ## degress of ## angle) like the line of sight behaviour.

    * Is above/below 2 points. (Filtering if object is above/below or left/right 2 XY coordinates)

    These are some of the conditions I use mostly, which if done with event feels like they are more heavy than necessary.

    Maybe behaviours could be used to do the same thing? If anyone good with creating behaviours know's how to do this, I'd be happy to pay for it.

  • 2 finger operations like pinch for zoom, and scroll with 2 fingers works in the layout view, so it's a bit touch friendly already.

  • > How big is the game? Took me ages to load the Beta. Or maybe just my connection is bad momentarily.

    >

    Sorry for the late reply. It's around 60mb of data. It was about 45mb before the newest update... adding too many egg sprites.

    Thanks for playing! How do you feel about the game?

    Nice job, very well done. The only part i was judging felt a bit long, especially after you played a few times. I wanted the results quicker. It could be sped up a bit.