Track pixels drawn per frame/second?

Discussion and feedback on Construct 2

Post » Tue Aug 30, 2016 7:17 pm

No they don't, they use OpenGL and OpenGL most likely clears screen buffer and rasterizes vectors and adds fragments every draw call, you are confusing the memory used to store those Images for quick access and the memory used to handle fragment shaders and vertex shaders, there's definitely multiple passes with effects and that can slow down things especially on devices that do not support OpenGL effects
Posts: 2,249
Reputation: 17,585

Post » Tue Aug 30, 2016 11:42 pm

@Tinimations - Glad it helped! :)

@newt - Bitrate and pixel fill rates really don't have anything to do with each other though. Bitrate is all about compressed video and the resulting accuracy of the compressed image in comparison to the original, and game engines don't compress their rendered frames when they're sent to the screen. Even having thousands of small sprites like the snow or confetti he showed might slam the draw calls, but the resulting number of pixels drawn would still probably be quite small compared to what the gpu can manage because of the empty space between them. With that many sprites on screen it's probably going to be a cpu bottleneck calculating their positions or telling the gpu to draw them instead of the actual process of drawing them, which is what we're talking about here. If you meant developers should avoid tons of objects to optimize though, that's correct but for different reasons than the pixel fill rate alone.

@Whiteclaws - A draw call is made for each on screen object, not once for the entire screen, so if you have 100 instances that's a hundred draw calls each frame, or 6000 per second.

That's not exactly right about RAM/VRAM being cleared each frame - it would be a huge bottleneck to do so, as the process is so slow most games have to show you a loading screen. I suspect you meant the framebuffer is cleared (the RAM/VRAM allocated to the drawn image). Even if that is what you meant I thought I should clarify for anyone else reading. If you have 'clear background' set to yes it clears the framebuffer (which also takes more work, so disabling it can help performance if the background is covered anyway), but you can turn that off and watch objects smear around.

As mentioned, the framebuffer is stored in memory, so the higher the resolution the more memory it uses.

@saiyadjin - At that resolution with no overdraw it's 124,416,000 drawn pixels per second. The Tegra 3 - which is an older chip - could draw 1.04 billion pixels per second, the Tegra 4 can draw 2.68 billion, and there are two generations of chips that have come out since then that are even faster. Mobile gpus have had the power to draw the entire screen multiple times per frame for quite a while.

Also, C2 does not only draw moved pixels. I've never heard of the technique used anywhere except compressed video and even then it's not exactly the same thing as it's encoding the movement of pixels rather than just drawing the moved pixels, as far as I know. If anyone's using it for rendering it's unusual (aside from frame warping in VR to coverup missed frames, but that doesn't work properly for rendering new material). If there's any difference between the current frame and the previous one, C2 redraws everything (with the exception of any pixels that are not covered by an object if you tell it not to with the clear background setting). If everything is the same, it skips drawing completely.
Posts: 3,007
Reputation: 27,931

Post » Wed Aug 31, 2016 7:30 am

@Arima - that is correct - but Tegra 3 is a pretty hardcore chip, while mobile chips are usually way weaker. example - mali 400 (which was a high end chip at one point) - Pixel rate scalable from 275 Mpix/s to 1.1 Gpix/ which would usually mean it can render ~ 10x more fps per second ~ 530 frames. but the problem is that draw calls are deeper then it is supposed to be -> graphics usually takes more then one "pass" to render the final pixel. and that takes time and slows down process. on a fullHD picture if you use 5 effects on different parts - > 6 passes, default render + 1 for each effect + maybe some other -> huge drop in fps. it's not all in pixel rendering, and that data that providers give you is - still image pixel rendering with 0 effects which is just to show bruteforce power of the chip.

didn't say about C2, i think that's more of a 3D engines idea, or i might have misread that somewhere something, not so sure anymore :) i think it's just alpha blending or something, where you redraw only parts that were invisible / visible after they moved. it doesn't matter anyway :)
Sea Monsters template - Isometric
Also includes 40 pages PDF of optimizations and "how-to" for your games, and how the "sea monsters" template was built. Follow link for details :)

Posts: 631
Reputation: 9,467


Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 3 guests