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

This forum is currently in read-only mode.
0 favourites
From the Asset Store
Create a game inspired by great arcade classics as Operation Wolf
  • Ok, so I was making an example of why you shouldn't use huge none pow2 textures. When I noticed the following.

    The examples have unlimited frame-rate mode on intentionally.

    First example:

    2000x2000 png on a tiled background (or sprite for this first example, it makes no difference as it looks the same) at 2000x2000 size.

    <img src="http://steamgauge.com/misc/construct/images/tilebug1.jpg">

    Notice the frame rate. The VRAM can be ignored as it's obviously going to be 16mb

    Second example:

    16x16 tile png on a tiled background (tiled background only this time obviously) at 2000x2000 size.

    <img src="http://steamgauge.com/misc/construct/images/tilebug2.jpg">

    Notice the frame rate. The VRAM can be ignored as it's obviously going to be 0mb for a single 16x16 tile.

    Third example:

    128x128 tile png on a tiled background (again, tiled background only) at 2000x2000 size.

    <img src="http://steamgauge.com/misc/construct/images/tilebug3.jpg">

    Notice the frame rate AND notice how it's not tiling correctly. Bare in mind both 16x16 and 128x128 are pow2 sizes.

    But most importantly is the HUGE drop in frame rate when doing it correctly, yet next to no difference when doing it wrong. Now I can understand tiling a 16x16 image would use some resources. But effecting the frame rate this much?

    Also copy/pasting (not cloning) the 16x16 tiled background doubles the fps loss each time. (As does cloning but that's more likely to be expected).

    This has been tested by others in chat and it's happening to them too.

    Version 0.9.83

  • Why is this strange?

    Its still going to draw each texture each frame, you've just varied the size. So instead of drawing one texture, your drawing 70 each frame.

  • Why is this strange?

    Its still going to draw each texture each frame, you've just varied the size. So instead of drawing one texture, your drawing 70 each frame.

    It's strange because a none pow2 texture, at the horribly large size of 2000x2000 has utterly NO effect on frame rates.

    While a 16x16 texture, tiled and therefore SUPPOSED to be using less resources, as is the point of tiling and the tiled background object. Kills frame rate almost completely.

    It's like a religious person realizing there's no god. All those times we've told people to use pow2 textures and keep them small. Besides less VRAM usage, why bother. The big shit causes less damage to frame rate than the small optimized stuff, lol! Does that not seem utterly backwards to you?? Does to me!

  • Yes its a trade off, 16x16 may not take up much memory, but then your using the processor to generate the texture. 16 x16 is not good for tiling, it eats up frame rate, and it makes up patterns, even though its seamless.

  • Yes its a trade off, 16x16 may not take up much memory, but then your using the processor to generate the texture. 16 x16 is not good for tiling, it eats up frame rate, and it makes up patterns, even though its seamless.

    It's a pretty big trade off if you ask me. The tiled background object is meant for this kind of thing, but not at the expense of such a frame rate drop. And this is just one tiled object.

  • It's more likely a problem with the FPS counter. I remember reading someone else was having trouble with it reporting wildly inaccurate results recently.

    Anyway... post your .cap!

  • It's more likely a problem with the FPS counter. I remember reading someone else was having trouble with it reporting wildly inaccurate results recently.

    Anyway... post your .cap!

    I thought it might be to do with the fps counter too, but I'm not so sure. For some reason I've always been able to hear a high pitch noise (barely noticeable but it's there) when frame rates are very very high, such as 4000fps or something. Which it does in the 2000x2000 version, but not the 16x16 one.

    Anyways, here are both the caps. Though as I understand it, this is repeatable and happens to others when they try it too. Though of course it's not as noticeable as nobody would use such large tiles or images normally. I only noticed it because I was doing a very over the top example for a tutorial, on why tiles are better than single big images. But now I'm all like, Santa isn't real?? lol.

    16x16 version cap

    2000x2000 version cap

    Didn't bother uploading the 128x128 example with the funky tiling issue, as I recall that's a known recent problem.

  • I guess it is because it still redraws each tile to fill the screen. Since one tile fills the whole screen (the 2000x2000), it doesn't have to redraw at all. In the case of 16x16, the tiled background behavior interacts with renderer to draw each of them.

    Just a wild guess.

  • Supposedly your graphics card only has to keep one copy of the tile in VRAM and can produce several hundred copies without much slowdown. Slowdown should only start happening if the graphics card has to keep swapping textures back and forth to start blitting different objects in proper Z order. Since that's not the case, tiling shouldn't be a problem. The 16x16 tile version should be much more efficient than the large image. As I said before, it's probably an error in the FPS counter.

    But yeah it'd be nice to have an official word on this one, instead of guesses and conjecture.

  • The highest I got with the 2000x2000 version was 357 FPS. I opened up the tile and cut size to 16x16 then ran it again and it had a higher FPS of about 430.

  • Your 16x16 .cap actually uses a 16x18 texture 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.

  • Your 16x16 .cap actually uses a 16x18 texture 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.

    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

  • It still had a similar slowdown for someone else who did their own.

    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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Your 16x16 .cap actually uses a 16x18 texture

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

    Hehe, I kid!

  • 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:

    http://dl.dropbox.com/u/1328856/32x32.cap

    http://dl.dropbox.com/u/1328856/512x512.cap

    http://dl.dropbox.com/u/1328856/1024x1024.cap

    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).

Jump to:
Active Users
There are 2 visitors browsing this topic (0 users and 2 guests)