tunepunk's Forum Posts

  • You can't argue with Pixi's performance, simply amazing:

    Would be very interested if C3 can take advantage of whatever magic is allowing this

    Yeah, If C2/C3 could implement whatever voodoo, witchdoctor, hocus pocus they are using for Html5/webGL performance, Construct would slap all other 2D engine competition on the fingers big time. :p

    Right now Construct is pretty much on par with most html5/webGL solutions i've seen out there I think, but pixi.....is just ..... mindblowing.

    I mean if you can hit 5000 moving on-screen sprites at 60 FPS, how many games are going to need more than that?

    It's ok on desktop, but html5 for those of us who develop for mobile.... we need some of this kind of optimizations. I think Ashley is assuming that everyone doing mobile games want to do flappy bird clones with max 100 sprites on screen for decent performance.

    This is pretty much what a midrange phone can handle.

  • And now for the phone results. Nokia Lumia 830. Pixi does way better again.

    C2

    UnityWebGL - Not even working on phone.

    Pixi

    I don't know what it is, but there's something Pixi is doing that seems to be superfast. about 10x-20x faster than all other webGL I've seen.

    It's free and opensource, so I hope C2/C3 can take advantage of it in the future

    http://www.pixijs.com/faq

    https://github.com/pixijs/pixi.js/blob/dev/README.md

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Woah, that was a huge gap.

    C2 in chrome on my iMac

    Unity WebGL on my iMac

    Pixi in chrome on mt iMac

    5000 vs almost 200.000 both are webGL, it's not even a fair comparison? What makes one so much faster than the other... that's what I would like to know. But after all the C3 sales, maybe he can hire someone to optimize and bump those numbers up.

    I think what's being measured from this is the speed of events or gdscript.

    Maybe, but there seems to be something in C2 eating all the resources. Overhead, draw calls, who knows?

  • Interesting, Did you investigate why some where better than others? Did you use a WebGL inspector? My conclusion on another thread was draw calls. Less draw calls/draws = better performance, maybe this can help me investigate this further.

  • That's what they tried to explain. For every light source you have. Also use a line of sight behavior on that object. If your character is in the shaddow, that means he is also not in the line of sight, looking from any light source.

  • Did you try with C3? It has a better spritesheeting engine. Again though, there's still no evidence this is actively causing any performance issues. Each individual draw call as a tiny overhead.

    Avoiding texture swaps is really hard and makes potentially worse tradeoffs. For example the ultimate way to avoid texture changes is to place absolutely everything on to one single giant spritesheet, so there is only one texture which never needs to be changed. However that reverses the benefits of layout-by-layout loading and guarantees that your game will use the maximum amount of memory at all times, which is wasteful and can cause many games to crash on some devices. Then there's the maximum texture size, so sometimes you have to spill over to another texture.

    So there is no evidence this is actually too slow, and "fixing" it could easily make things a lot worse.

    I'd be happy to try in C3, as I did notice that it bundle even art from other sprites in the same sprite maps. But my project is currently stuck in C2 because of plugin dependencies (photon cloud, and raytracer). Would It be possible to have an option in export for C2/C3 to manually set a target sprite map size? That way we could have a little bit more control and reducing number of sprite maps, and swapping/draws?

    What's the current maximum?

    So would you recommend me trying to bundle most/all of my artwork into the same sprite in C2 for now, or sprite maps as that seems to be the only thing I could do so far to control it somewhat? fewer sprites/swaps/draws seems to equal a better performance especially on mobile.

  • This is unique to C2 preview mode only.

    No, that's from an exported html5 project on my host. I'm gonna run this gif by some other dev friends of mine for a second opinion, if this looks normal.

  • Yeah as I stated above I use Photon at present, but their plans are quite expensive for what you get. $95 for 100 concurrent users.

    Whilst I don't expect that much, it's still expensive.

    95 is not really a lot. If you have 100 players ccu you should be earning enough to cover that pretty quick?

  • SnipG Hmmmmm... I'm getting skyrocketing draw calls on edge when I change sprites, both on windows phone and my surface. but not in chrome. That's odd..... And that's my main developing devices... Is there something in the way the rendering works that is not supported in edge probably? Because it's only this case.....

    I think I need to buy myself a few more testing devices.

    I think I'm going bonkers soon... Been struggling like a madman for months to optimize the game on my windows phone to get the draw calls down and it's an edge/windows phone issue?? God dammit....

    EDIT: Is it possible to have some mobile specific optimizations, because I still think that the texture swapping and too many draws still could be a bit of an issue on mobile, maybe not very noticeable on desktop devices, but as I said before, Those doing large projects, and mobile projects seem to notice "something".

  • photon cloud, very easy to use and understand. you can have games running as long as there is players in the room. no host or peer.

  • I FOUND IT!!! AND I WAS RIGHT!!!!

    I created a completely new layout with the same kind of sprites that i use in my game, only this time much tighter packed, on different layers so there should be a lot more overlap and fillrate even. Wholla, way lower CPU for draw calls.

    Now for the fun part.

    Then i selected some of the sprites and changed their animation frame to another one where there is other sprite artwork. WHOLLA! Draw calls shooting through the roof!!! with same ammmount of sprites. It is FOR SURE something with the draw calls, and texture swapping!!!

    Ashley you need to look over it. I knew I wasn't crazy!

    The more different kind of sprites I use have the slower it gets, and it's because the draw call overhead and texture swapping seen HERE! I could even recreate it. EDIT: Maybe it's specific to Edge and Windows phone, but there must be some thing to mimimize this, as it doesn't seem to like it.

    Here is a link to capx, to confirm. The only thing you need to do i select some groups of random objects, and change their initial frame.

    https://www.dropbox.com/s/q5fr4y6mks63q ... .capx?dl=1

    Is this proof enough? My game is not badly coded, I'm not using a lot of unneccesary effects and blend modes. What is causing this?

  • I'm not talking desktop, I'm talking about mobile. Draw calls according to debugger, uses A LOT of CPU time, amost on par with all my game logic, collission checks and everything else combined. And I don't understand why..

    No effects, No Force own texture, No blend modes, Not a lot of sprites, no webGL effects.

    This test on my mobile... 7500 sprites, no problem.

    https://www.scirra.com/demos/c2/quadissueperf/

    Bunnymark 1500 sprites juping around, no problem.

    http://www.goodboydigital.com/pixijs/bunnymark/

    My game. rasing spritecount from 300 to 1000 sprites, in the entire layout.

    then the fps drops to 30 on the same phone.

    It can't be fill rate, the game is pretty barren so far, not even all of the sprites in yet. The only thing is a little bit of texture overlap, since it's isometric perspective.

    So what is it? The only thing i see on the debugger is draw calls, draw calls, draw calls, way up there. Fill rate? Bottleneck? What is causing it, and how do I lower it? If it is something that I'm doing, there should be a comprehensive tutorial on how to lower it.

    It's driving me nuts!

  • There is nothing to gain by improving this. It looks like it's submitting about 2500 sprites at a time, which means the draw call overhead is about 0.04% of the naive case of one call per sprite. If we increased this to say 5000, it would make such a tiny difference it is totally irrelevant (0.02%), while increasing memory usage and latency. So like most engineering tasks there's a tradeoff here, and we've aimed at a good sweet spot.

    I can understand why you're doing that, with a lot of sprites. Bunnymark is doing the same thing, only their limit is a lot higher. They are doing 3 draws for 60.000 sprites.

    But in my game, I don't have a lot of sprites... currently 350 in layout, only a few on screen. But the draw and texture swapping is still apparent, quite a lot of texture swapping and draws for very few sprites, so even if the drawing workload is pretty small, for a mobile phone that's pretty weak, something is causing it to slow down. Even with just a few sprites on screen.

    How to get around it? Can it be the texture swapping that has overhead?, Looking at the WebGL inspector, it's drawing a few sprites, switching texture, drawing a few more sprites, switching again, drawing a few more sprites, over and over like that, each frame, in multiple layers. Not even near 2500 sprites per draw. Maybe maximum 10. So there must be something causing the slowdown.

    I imagine, if I were to put all my sprites into one spritesheet this wouldn't happen. I'm curious to try it on C3, as it's much smarter when generating the spritesheets, but I can't test this project there yet, as there's no photon cloud plugin so far.

    Exporting from C3, I can see that even separate sprite objects are on the same sprite sheet, In C2 this is not the case.

    So is it possible in C2 that the overhead is caused by the texture swapping, and unnecessary many draw calls due to that.?

  • Ashley - if the GPU fillrate is bottle-necking literally everything, then how do we fix it?

    Have all your artwork in 1 sprite object, seems to help. A pain in the ass to work with though.

    But I think it's starting to lean more towards some texture switching rather than GPU bottleneck.

  • [quote:28hu49fx]Your screenshot shows FPS < 60 and CPU well under 100%, which is typically indicative of the GPU hardware being the bottleneck.

    [quote:28hu49fx]Sorry, but I don't think you actually understand how WebGL rendering works.

    You're absolutely right I don't, that's why I'm doing everything in my power to investigate why I'm getting bad performance on mobile.

    I made a gif to try to show you what I mean.

    This doesn't look very efficient to me. And I'm not a WebGl guru, but from what I've read, you should be minimizing draws to a minimum for webGL. This doesn't look like 1 draw per frame from one array, This ilooks like several drawElements, layer upon layer. You can see the blue dots building up to the right.

    But anyway, so your example is rendering 7500 sprites but my game only a few hundred, on the Same Phone!? I doubt it's GPU bottleneck. Other webGL examples and games are not bottlenecked, why only C2 games with lots of different sprites?

    I'm only guessing it has something to do with how the rendering is done.

    As I said. Merging most my artwork in to the same sprite, by using Animations and frames, seems to have a positive effect. So the only way to get around the bottleneck is to merge all sprites to one huge spritesheet? I want to go to the bottom of this. I shouldn't be getting 30fps with a couple of static sprites on screen.

    Anyway.... I'm going to set up a few different capx tests to further test this.

    Maybe that will help in finding out why, performance is dropping significantly, when using a lot of sprites from diffrent spritesheets, but not when using 1 sprite or 1 spritesheet (texture)