Very strange behavior with tiles and fps (Ashley, David)

For questions about using Classic.

Post » Sun Feb 28, 2010 3:08 pm

Your 16x16 .cap actually uses a 16x18 texture :P That's not power of two, so power of two rendering is disabled! If you resize the texture to actually be 16x16, the framerate goes up.

Just to clarify some of the comments here, in practice the framerate for tiling power-of-two textures (16x16, 128x128...) should be roughly the same. Power-of-two textures can be drawn more efficiently - there's basically a single command which is "tile texture N times". That doesn't work for non-power-of-two textures though, so instead for each and every tile Construct has to issue a separate "draw this texture once here" command. That introduces a very large overhead of command data going to the GPU which is the main cause of slowdown when many tiles are visible on-screen.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,590

Post » Sun Feb 28, 2010 6:48 pm

[quote="Ashley":c0w2sbgi]Your 16x16 .cap actually uses a 16x18 texture :P That's not power of two, so power of two rendering is disabled! If you resize the texture to actually be 16x16, the framerate goes up.

Just to clarify some of the comments here, in practice the framerate for tiling power-of-two textures (16x16, 128x128...) should be roughly the same. Power-of-two textures can be drawn more efficiently - there's basically a single command which is "tile texture N times". That doesn't work for non-power-of-two textures though, so instead for each and every tile Construct has to issue a separate "draw this texture once here" command. That introduces a very large overhead of command data going to the GPU which is the main cause of slowdown when many tiles are visible on-screen.[/quote:c0w2sbgi]

Well that is even weirder then, cause it was 16x16 when it was saved, lol. Though assuming it was user error on my part. It still had a similar slowdown for someone else who did their own.

Though I am hoping it is user error on my part :)
B
3
S
2
G
3
Posts: 628
Reputation: 2,531

Post » Sun Feb 28, 2010 6:53 pm

[quote="Lost my Keys":3sdl1lj4]It still had a similar slowdown for someone else who did their own.[/quote:3sdl1lj4]
Or rather Somebody else :) I did some tests with 32x32 tiles and every time the tiled stuff was slower.

Like - single 32x32 sprite - 5000fps
Same sprite stretched - 4800fps
Tiled background of same size as the stretched one - 4000fps

Each new instance of the tiled background ~ 20% performance hit according to the fps shown in title.
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Sun Feb 28, 2010 6:57 pm

[quote="Ashley":37bf6fdy]Your 16x16 .cap actually uses a 16x18 texture :P[/quote:37bf6fdy]

Nice. I think maybe you should look at a tutorial before you make your tutorial LMK :lol:





Hehe, I kid! :P
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Sun Feb 28, 2010 7:38 pm

Ok, did some extra testing on the desktop machine (which has a 7900 unlike the laptop which has a 9800M GTS graphics card, so less muscle) and the results are pretty interesting.

Here are some pre-made test caps, btw:
[url:2ym4if2n]http://dl.dropbox.com/u/1328856/32x32.cap[/url:2ym4if2n]
[url:2ym4if2n]http://dl.dropbox.com/u/1328856/512x512.cap[/url:2ym4if2n]
[url:2ym4if2n]http://dl.dropbox.com/u/1328856/1024x1024.cap[/url:2ym4if2n]

So it's basically a tiled 32x32, 512x512 and 1024x1024 texture.

When the layout is power of 2 size the fps is pretty much identical on this system for all the caps ~800 fps. If the layout size gets changed to something more common like 1024x768 the fps get cut in half.

Copy-pasting the tiled background does the same, as long as the position isn't centered perfectly (in that case fps is about 70%).

If a non power of 2 texture is used the fps is about 90% of that. Which is strange.

Basically it looks like the GPU just really dislikes anything that isn't power of 2. Be it texture or layout size. It's happiest when it gets to just render what's inside its memory straight up, no cropping. Also the performance seems to vary quite a bit among graphics cards (logical, of course).
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Sun Feb 28, 2010 8:19 pm

I can't reproduce any performance difference by changing the layout size. The layout size is pretty much just used to enforce scrolling limits - it doesn't have much to do with rendering, so I'm not sure why you'd see a difference there.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,590

Post » Sun Feb 28, 2010 8:44 pm

Ok, it seems to really show itself when the layout size is changed, but not the application size. Here are some samples:

Default 1024x1024 application and layout:


Now only the layout is set to 1024x768:


And now both application and layout are 1024x768:


Some visible difference right there. And the fps shown is pretty much an average, I waited a moment for it to stabilize.

Edit: Also just noticed that it suddenly starts to need 4 Megs of VRAM in the second sample - why is that? Sort-of drawing the application "background" and the layout as different things or something like that?
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

Post » Sun Feb 28, 2010 8:49 pm

Well I'm willing to concede that I screwed up and made it 16x18 and not 16x16. BECAUSE, it perfectly shows why pow2 should ALWAYS be used! ;) Oh yeah, I came out of this smelling like roses, lol.

But seriously though, it does clearly demonstrate how very easy it can be to be off by just a few pixels, and what a big negative effect that can have on a game.

So if/when I do do a pow2 tutorial, I'll be references this thread as a perfect example of why pow2 should always be used. See cause like.. I made this thread as part of a tutorial.. you believe that, right? RIGHT?? ;)

[quote="deadeye":3n868fn3][quote="Ashley":3n868fn3]Your 16x16 .cap actually uses a 16x18 texture :P[/quote:3n868fn3]

Nice. I think maybe you should look at a tutorial before you make your tutorial LMK :lol:


Hehe, I kid! :P[/quote:3n868fn3]

Haha, it was intentional, I swear *hides* :P
B
3
S
2
G
3
Posts: 628
Reputation: 2,531

Post » Sun Feb 28, 2010 8:52 pm

Oh right, it shows black bars when the layout is smaller than the window. Those black bars are drawn as well, and each weighs up to about the same performance impact as the tiled background (a four vertex quad). In such an intensive test, they're bound to show up as making a difference. Always keep the layout bigger than the window if you want to keep it a fair test.

Edit:
[quote:7mikr2h8]Edit: Also just noticed that it suddenly starts to need 4 Megs of VRAM in the second sample - why is that? Sort-of drawing the application "background" and the layout as different things or something like that?[/quote:7mikr2h8]
When the layout is smaller than the window, it draws to an offscreen surface first, to ensure nothing is drawn outside the viewable area. It's this offscreen surface you're seeing VRAM usage for. It's also going to further reduce performance copying this offscreen surface to the main window, which also explains the FPS dip.

In short, these performance/VRAM usages probably won't make much sense unless you know how the engine works.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,590

Post » Sun Feb 28, 2010 8:53 pm

[quote="Ashley":vi1x17k8]Oh right, it shows black bars when the layout is smaller than the window. Those black bars are drawn as well, and each weighs up to about the same performance impact as the tiled background (a four vertex quad). In such an intensive test, they're bound to show up as making a difference. Always keep the layout bigger than the window if you want to keep it a fair test.[/quote:vi1x17k8]
Ok, but what exactly eats up the 4 Megs of VRAM in this case?

This is some good stuff to know, to be careful of when trying for max performance, hence all the questions, Ashley :)

Edit: Got it, buffering of sorts.
B
19
S
6
G
6
Posts: 1,101
Reputation: 5,646

PreviousNext

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: GameOverBeast and 1 guest