Reduce Lag, higher FPS

Discussion and feedback on Construct 2

Post » Sun Apr 07, 2013 1:36 am

I've read up on it, as as far as I understand it, that's still incorrect, as I don't think C2 is blitting at all, I'm almost 100% positive it's billboarding instead (using flat texture mapped camera facing polygons). Even from the link you posted, it describes rendering being the process of having a scene file that is converted into a raster image, the drawing of the pixels themselves being a part of the process. I've rendered stuff in plenty of 3d packages, and none of them have ever wasted time rendering offscreen pixels, which would be a completely pointless waste of time, and I showed that C2 does not do that in my example above.

It's my understanding that first, a scene 'file' is generated that contains all of the vertex information for all of the objects in the scene (Ashley reuses the data generated for collision polygons as an optimization). Then that data is used to draw the screen from, drawing the parts of each object that are on screen back to front. This can cause overdraw by drawing the same pixel multiple times if that pixel is overlapped by multiple objects. While the vertex information for offscreen objects is still there, it isn't used for the actual drawing of the image itself because the graphics card only draws what is inside the screen.

I could easily believe that the graphics driver would cut down the undrawn vertex information to only what objects are on screen, which would make sense, but the drawn image itself? No. Cards have limits to their pixel fill rates and drawing offscreen pixels would be terribly wasteful. Also, the graphics driver or card having to check if the geometry is onscreen is a calculation that the driver can likely do far faster automatically than anything that could be done to try to optimize with JavaScript while still having the objects available to process in code/events.

In practice, it doesn't matter even if either of our understanding is incorrect. Not even minecraft draws things out into infinity - it, like games all the way back to the nes and earlier, create/generate and destroy/store objects based upon distance because even writing the most optimized assembly possible wouldn't be enough to overcome the fact that computers have limits. If someone wants to have a million objects in a layout like Bobofet, then they should implement a dynamic system to load and destroy objects as they get close to/far from the screen, same way everybody else does it.

@Bobofet - if you're using a grid like minecraft, saving/loading the instances to/from an array would work great for that. Also, you might want to do a distance check for the tiles you're checking for collisions with to reduce the number of collision checks. Also, tiled objects render faster than lots of small sprites taking up the same space, or as Tokinsom suggested, paste the tiles to canvas then load the canvas image into a sprite.

Rexrainbow was actually talking about possibly making a plugin that would load/create or save/destroy instances based on distance automatically - I reccommend bugging him for it, because I want that plugin too. :)Arima2013-04-07 02:03:08
Moderator
B
87
S
32
G
33
Posts: 3,005
Reputation: 27,397

Post » Sun Apr 07, 2013 4:09 pm

I would just like to officially confirm that objects off-screen are not rendered at all. This seems to be such a common misconception I think I'll add it to the manual.

For the record, here's how it really works:
- if any part of an object is on-screen, the CPU issues a command to tell the GPU to draw it. If it's offscreen, the GPU never even knows it exists.
- the GPU only draws objects that are on-screen, but is still smart enough to only draw part of an image if it goes offscreen. So if you have a tiled background the size of your layout, the GPU knows only to draw the part of it that is in the window. So off-screen content is still not rendered.
- even if Construct 2 issued draw commands for objects that are off-screen, the GPU is smart enough to just completely ignore it, because it can tell it doesn't appear in the window. However this is a waste of CPU time issuing a pointless draw call, so pretty much every engine that has ever existed will simply not issue draw calls for stuff that is off-screen.

You could probably measure a really tiny performance impact from having lots of objects off-screen (like, tens of thousands). This is only because Construct 2 is checking if they are off-screen and then deciding to ignore them, which is such a tiny amount of work it usually doesn't factor in to the framerate at all. But they're definitely not being drawn.Ashley2013-04-07 16:11:47
Scirra Founder
B
359
S
214
G
72
Posts: 22,949
Reputation: 178,544

Post » Sun Apr 07, 2013 8:34 pm

Thanks for clearing that up, Ashley. Definitely a good idea to add it to the manual.
Moderator
B
87
S
32
G
33
Posts: 3,005
Reputation: 27,397

Post » Sat Apr 27, 2013 1:02 pm

please forgive me for being so dumb, but I need clarification one more subject related to this one. Made a search on the tutorials and forums but it was not a deep search. Here goes:

Do behaviours like solid or phsycis still try to calculate for objects out of the screen and how can I disable this if I need to? Imagine there is an enemy on the other end of my level which is a couple screen widths away, and I don't want construct to check collision of that enemy with my player. I understand it's not drawn but since all other logic keeps working for out-of-screen objects, things like collision checks will eat some cpu power, right? I don't know if the perf hit is worth the effort to do such a thing...

Quick edit: So I want the collision checks to be made with a distance condition. (or on screen condition)

Thanks in advance :)
Windwalker2013-04-27 13:03:23
B
16
S
4
G
1
Posts: 332
Reputation: 3,016

Previous

Return to Construct 2 General

Who is online

Users browsing this forum: bilgekaan, digitalsoapbox, shinichild, TRMG and 10 guests