tilled background glitch when scrolling

This forum is currently in read-only mode.
  • its because of the antialiasing created when you zoom in

    There's no zoom in this .cap, though...

  • Its quite simple. Tiled backgrounds render in a special way such that the uv co-ordinates wrap instead of clamp. So when a tiled background is rendered at a decimal place co-ordinate, the texture interpolation is grabbing colours from the right. You notice this something in low quality 3d games when people accidentally setup the wrapping incorrectly and you get trees that have a semitransparent line above them etc.

    This isn't necessarily a bug in some situations. If you have a tiled background that is a seamless texture, you expect the texture in calculated the interpolated pixels, to account for the pixels that are wrapped on the other side of the image.

    Ultimately when it comes down to it though...why are you using a tiled background for these tiles which you dont actually want to tile at all? The tiled background object is really for images that you want to repeat over and over again.

  • why are you using a tiled background for these tiles which you dont actually want to tile at all?

    Well, because sometimes you want to have an still image with no animation and doesn't need any special hotspots or image points or other features that a sprite has.

    I mean, should we be using sprites in this case?

  • [quote:1fwdqh3u]I mean, should we be using sprites in this case?

    Same thing happens when you use multiple bgtiles, that are actually tilled.

    Example: Lets say you want to make a border with one tileable image on top, one on bottom, one on the left, and one one the right. Your still going to get the one pixel difference where the corners meet.

  • > why are you using a tiled background for these tiles which you dont actually want to tile at all?

    >

    Well, because sometimes you want to have an still image with no animation and doesn't need any special hotspots or image points or other features that a sprite has.

    I mean, should we be using sprites in this case?

    i agree - from my simple calculations sprite is much heavier than tilled bg becous have more options.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Sprites don't really add any more rendering time than tiled backgrounds, so it's fine to use them.

  • Hmm this is something someone should test. Create 10,000 sprites with a single image, check fps, then create 10,000 tiled backgrounds with the same size, check fps. They should be the same...if not then it should be looked into.

  • They're the same on my machine.

  • Actually on my machine (P4 3Ghz, 7600GT 512mb) 10,000 sprites (64x64) run at 70fps in unlimited mode, and 10,000 tiled backgrounds (64x64) run at only 15fps in unlimited mode

  • Well, that's enough to dispel the "sprites are slower" myth!

  • that's very unexpected ... why would tiled background impact framerates more than sprites?

  • That was unexpected, and I didn't believe it at first. So I ran my own test.

    10,000 64x64 sprites, unlimited framerate: 300fps

    10,000 64x64 tiled bg's, unlimited framerate: 230fps

    P4 1.3 Ghz, GeForce 6200

    I'm stymied. All I've ever heard is that tiles are lighter than sprites. I'm also very curious why mine ran better than BenH's, because he has a better computer and a better graphics card.

    Oh, and Mipey... if my crappy computer can handle 10,000 tiles in a layout that well, then you pretty much don't have to worry about your game.

  • That is good news!

  • I'm also very curious why mine ran better than BenH's, because he has a better computer and a better graphics card.

    Wow, that is weird! The only thing I can think of is that it's not running as well as it should do on my computer. Maybe my graphics drivers need updating or something

  • I guess it's because the tiled background object changes renderstates for a tiling render process. Otherwise I don't know why. Optimisation is a very tricky area - you can never know for sure something is faster until you measure it. I've had cases where removing code made it go slower. You can't know till you measure.

    It's worth also looking at non-power-of-two tiled background sizes, because they draw completely differently.

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