Texture tiling problems

The problem described in this report is still around: http://sourceforge.net/tracker/index.ph ... id=1003219

Basically the tiling textures don't display properly. I'd like to know if there is a solution other than the ones used in my examples. Stretching the textures and in some cases doubling the memory with textures that are sized in the power of two usage this way doesn't count as a solution.

Attached picture has a detailed explanation.

http://planar-studios.com/files/example/tiledbug.png

<img src="http://planar-studios.com/files/example/tiledbug.png">

Example cap http://planar-studios.com/files/example/tiledbug.cap

The problem described in this report is still around: http://sourceforge.net/tracker/index.ph ... id=1003219

Basically the tiling textures don't display properly. I'd like to know if there is a solution other than the ones used in my examples. Stretching the textures and in some cases doubling the memory with textures that are sized in the power of two usage this way doesn't count as a solution.

Thing is though, video cards work better when they are, and very few of the newer ones can handle textures that aren't. You should limit your imagery to:

1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, etc. (though anything bigger than 1024 is going to cause trouble on all but the newest cards, and anything above 512 is going to cause trouble on the older cards, though as construct requires DX9, you should be ok up to 1024). That can be either square or rectangle shaped. So the power of two "solution" isn't really a solution, it's a rule.

It's not a bug with construct, or directx or anything, it's just how these things work and how they've always been done. Try changing your texture sizes to fit one of the above numbers, if it works then yay, if not, THEN it could be considered a bug.

Thanks for the quick reply.

Still makes me wonder why the last pixels are clipped. I've been under the assumption that no matter what size the sprite/texture is it's dimensions are always stretched to the power of two in the GPU memory. What I meant is that if I'm tiling a 256x256 texture and I want to display properly without the clipped 1px lines on the sides I'd have to change the dimensions to 257x257 to correct the tiling and thus using 512x512 worth of memory. This is what I meant with the unacceptable solution.

All in all the problem is fixable in the demonstrated way but it makes accurate level designing a lot of trouble since the things are not working the way they should be.

Edit: Also yeah, I'm very precise with my work and want the outcome to be good and I of course generally do use texture sizes that fit to the power of two. Regarding sprites I see no sense in trying to limit the looks with the sizing since it IS supposed to work no matter what the sprite dimensions are since, as said earlier, the dimensions are fit into the power two in the GPU memory.

Also, it's possible to do the things included in my examples with sprites and not use the tiled texturing at all but don't you think that that, if something, would be non-efficient? Instead of having a few big tiling vents I'd have to have tens upon tens of individual vent sprites. I'm sure you see this point of view.

Thanks for the quick reply.

Still makes me wonder why the last pixels are clipped. I've been under the assumption that no matter what size the sprite/texture is it's dimensions are always stretched to the power of two in the GPU memory. What I meant is that if I'm tiling a 256x256 texture and I want to display properly without the clipped 1px lines on the sides I'd have to change the dimensions to 257x257 to correct the tiling and thus using 512x512 worth of memory. This is what I meant with the unacceptable solution.

All in all the problem is fixable in the demonstrated way but it makes accurate level designing a lot of trouble since the things are not working the way they should be.

The reason for the power of two thing I think comes down to how binary and bits and all that fun stuff works. A 256x256 texture should tile perfectly *runs off to test it quickly* Yep, 256x256 tiles just how it should, then I tried 255x256 and it was suddenly missing a single pixel line. So yeah it's working as it should.

If you change your artwork to fit in the sizes given in my other reply, even if it means cutting out a few rows or columns of pixels. Then you should find everything is tiling correctly for you. For the most part you shouldn't have a problem with doing that, and if you round down to the nearest acceptable size, you'll probably save on memory. As you say, if you go over, then it gets rounded up, which you want to avoid (load in a 1024x1030 sprite and see it try stretch to 2048).

As for memory usage, I really wouldn't worry too much with something like this, unless you go crazy with hundreds of huge animated sprites and backgrounds, it's unlikely to make much of a difference memory wise. So if you HAVE to go over and round up on one or two textures, it wont be so bad (unless they're absolutely huge lol). Also the tiling object greatly cuts down resources required, and I don't think when it comes to the actual OBJECT size, that it matters how big they are, beyond the capability of the target machine to move large objects about. So a 32x32 textured sprite that's stretched to 1680x1050 would as far as the computer is concerned, still be a 32x32 texture.

Anyway I babbled lol. Have a go though, change your sprites to match the numbers and see how it works out, you shouldn't have any problems then. I just tested it, same version as you and it worked just how it should. So you should be ok.

You could also get into the habit of using .dds files, I don't think they even allow you to save in any size other than the correct ones. I don't know for sure with construct, but in other DirectX applications, using .dds is the better choice and tends to give improved performance. There's a very cool loader/saver plugin for Photoshop from the nVidia site which has tons of options that you can use for those too.

I tried resizing the sprite borders to the power of two and it works wonderfully! Using 32x32 instead of 32x24 fixed the clipping. Thanks for the hint. Though being forced to use square shaped borders kills a lot of possibilities with the tiling. I'd still like to see the possibility of being able to tile non-power of two shaped sprites without the pixel clipping problem.

I wonder if it makes any difference in the clipping problem if you load the textures externally instead of internally. The external resource management is far from ready in this project but we'll get there.

Edit: Right, next time I'll just go read the wiki word to word instead of swimming through bug reports.

[quote:nre42lnv]The tiled background plugin renders fastest with a square power-of-two sized texture, i.e. 16x16, 32x32, 64x64, 128x128 etc. Using a texture of this size also results in very smooth scrolling, since other sized textures may introduce "seam" artefacts along the edges of tiles.

I tried resizing the sprite borders to the power of two and it works wonderfully! Using 32x32 instead of 32x24 fixed the clipping. Thanks for the hint. Though being forced to use square shaped borders kills a lot of possibilities with the tiling. I'd still like to see the possibility of being able to tile non-power of two shaped sprites without the pixel clipping problem.

Glad it worked!

I don't think you're going to see none power of two textures working flawlessly for some time to come, not in real time anyway (pre-rendered it doesn't matter). Newer cards can handle it, but it's extra strain for them. Older cards however will probably just balk at them. Honestly being forced to use specific sizes isn't as bad as it seems.

[quote:2q2kf0ak]I wonder if it makes any difference in the clipping problem if you load the textures externally instead of internally. The external resource management is far from ready in this project but we'll get there.

Well no, cause this is a DirectX thing, and a computer thing, they've been using these set tile sizes since the beginning, and then when textured 3D games came along, those too used them. While I admit, some programs DO have different sized tiles available (I faintly recall some creator program from way back that allowed strangely sized tiles), but it's few and far between, and probably unheard of with modern methods. Like I say, it's just easier for the hardware to handle textures of those specific sizes.

There are a few tricks you can use though, unlike most 2D games or creator programs, construct doesn't force you into working in a tiled environment. Yes your textures should be power of two, but your tiled backgrounds can be whatever random size and it appears to make no difference. Also, overlaying other tiled backgrounds on top is perfectly acceptable and works just fine, even if they too don't follow a grid pattern.

Using that as an example. Say you've got your tiled floor, and you wanted a few manhole covers, but each one is rotated differently to the next (to avoid obvious repetition), traditionally you'd probably have to make new tiles for each and every one. With construct you just create a clone/instance of your manhole cover, rotate it and place it where you want. Do the same with a bunch of other random objects, leaves or trash or rocks or whatever and you can very quickly and very easily remove any obvious repeating pattern, just like how decals work in 3D games. From an artists point of view, that's an awesome part of construct, and being as they're instanced, they effectively only exist as a single entity, so that cuts down VRAM usage too.

Still makes me wonder why the last pixels are clipped. I've been under the assumption that no matter what size the sprite/texture is it's dimensions are always stretched to the power of two in the GPU memory.

Maybe some engines do this, but Construct does not, it places the texture unscaled with transparent edges on the smallest power-of-two texture that can accomodate it.

You could also get into the habit of using .dds files

Construct does not use DDS internally, so the file format you use won't affect this.

As for your original problem, the technical reason the clipping of 1 pixel occurs is this:

Construct supports scrolling to floating-point co-ordinates (this will happen centering the window on almost any moving sprite) for optimal display. It makes scrolling and motion very smooth. However, it causes a problem for tiling.

Graphics cards can natively tile any power-of-two texture seamlessly, a bit like using a mesh distort on a sprite with UV co-ordinates above 1. The problem is when the texture is not power-of-two, Construct stores it on a power-of-two texture with transparent edges, so tiling that would have transparent areas between each tile - not very useful.

So in that mode, Tiled Background resorts to an alternative tiling system which basically amounts to drawing separate sprites in a grid. However, when you scroll to a floating-point co-ordinate, you end up drawing these tiles at floating-point offsets, which overlap, but due to the way they blend, they have one pixel seams between them. There were a lot of complaints about the seaming - it doesn't look good at all. So as a fix, pretty much the only thing that I could do was move the tiling back one pixel, so the next tile covers up the seam. But you lose one pixel to the bottom and to the right of your tile. As far as I remember, if you stretch up an image to fill the power-of-two texture and tile that, it blurs the actual texture, so isn't any good either. Basically, there's no way to perfectly tile non power-of-two textures with floating point scrolling.

Note the layout editor does not support floating-point scrolling, so you always see it perfectly here. (it should probably preview the same as it'll appear in the runtime though, I guess that's a bug)

The only way around it is to use power-of-two textures. I can't even make it tile perfectly if you disable floating point scrolling by forcing scrolling to round(x) and round(y) - then applications which do scroll smoothly will see their tiles jittering by one pixel when it hits an integer scroll position.

So yeah, it's complicated. But basically you can totally side-step all the problems, just by using a power-of-two texture, as is documented (although maybe the object itself should tell you). Those tile perfectly on the GPU. So, there's your explanation, and your fix

>

> Construct does not use DDS internally, so the file format you use won't affect this.

>

Ahh, so it really doesn't matter if I use png's or other supported formats instead of .dds then, as far as construct is concerned anyway? I'm so used to using that format for anything realtime related that I didn't think to ask before.

Don't mean to hijack the thread, but since the issue was resolved I figured it wouldn't hurt.

As soon as you hit save in the picture editor, the image is converted to PNG and stored inside the .cap. They're also exported to the runtime as PNG. So what you use before importing it doesn't matter, although I'd recommend something lossless obviously.

As soon as you hit save in the picture editor, the image is converted to PNG and stored inside the .cap. They're also exported to the runtime as PNG. So what you use before importing it doesn't matter, although I'd recommend something lossless obviously.

Awesome, that's good to know! Thanks!

Thanks for the replies Ashley. We've drifting a little off-topic here but it doesn't matter since the conversation is productive.

Another question regarding the texture handling: if I use external textures as in load files to fill sprites are the external textures all converted to PNG before the app runs? Is it faster to use external textures instead of ones inside the cap? When I add a sprite to Construct it converts it to a PNG, but if it's loaded in the runtime will Construct convert it to a PNG as well?

if I use external textures as in load files to fill sprites are the external textures all converted to PNG before the app runs?

If you mean actions like "Load frame from file" at runtime, then no, they're decompressed and loaded directly in to video memory. There would be no point converting the file to PNG then loading in to video memory! That would be the same as decompress source file -> recompress source file as PNG -> decompress PNG -> load to video memory!

[quote:20r9lmez]Is it faster to use external textures instead of ones inside the cap?

Probably not, it would only affect the startup time, and if the startup time of your application is fine, there's no point caring.

[quote:20r9lmez]When I add a sprite to Construct it converts it to a PNG, but if it's loaded in the runtime will Construct convert it to a PNG as well?

As I said earlier, once images are saved in Construct, they stay PNG, and the runtime loads them as PNG.

Basically, to summarise the system:

Images in Construct are stored as PNG, given to the runtime, and then decompressed to video memory on startup or another time (depending on your texture loading settings).

Images loaded at runtime are immediately decompressed to video memory.

That's it!

Right, very informative. That's all there is I need to know, basically the start times with our current project ARE getting irritating in our test builds. The texture handling is more than useful to know in future development.

Construct is the most powerful tool for fast development I've ever worked with. I'm not much of a coder myself but I find the Construct's inner works very intuitive. Will look forward and support further development as much as I can.

Loading times are inevitable in projects which involve extensive assets. Consider creating a loading screen with animation, if the time exceeds 5-10 seconds to let the user know the game hasn't crashed on load.

My game was starting to take a long time to load/save/run, so I replaced all the big background graphics I had with tiny squares, then load the images at runtime instead. It now loads/saves/runs in less than half the time. This works with any object that has no animation, but it does make them harder to place. (Note: if you do this make sure that after replacing the images with tiny squares, make them 1:1. Otherwise construct crashes when loading images to them.)

Mipey: IIRC, construct freezes while loading assets. You could make a loading screen, but it couldn't have animation.