Tile with Variant

Get help using Construct 2

Post » Tue Jun 18, 2013 4:31 pm

Hi

The original half life used a tecnique to make rocks texture appear less tiley. They had 8 (or something) very similar looking -yet different- tiles, that all conected to each other. And when applying this to a rock wall, the engine would randomly choose a tile every "square" instead of using the same tile every time.

so far, I`ve been able to replicate this effect in Construct 2 using sprites, but was wondering if there is a way to do this using Tiled backgrounds.

Thanks.
B
7
S
3
G
3
Posts: 53
Reputation: 2,459

Post » Tue Jun 18, 2013 4:38 pm

This wouldn't work with a TiledBackground object since it uses only one image. Your best bet is to use a Sprite object for the stone with different animation frames, place it where you want it, then set a random frame on start of layout.

Edit: When I think about it, what you could probably do is have a TiledBackground object that defines the size of the area where you want the stone, then distribute the Sprite objects over the TiledBackground object using events. I can try and throw something together if you're interested.

Edit2:
Wanted to see how easy it was to achieve the effect so here you go, hope it helps:
RandomTiling.capx (r134)Nimtrix2013-06-18 17:21:01
B
27
S
8
G
8
Posts: 903
Reputation: 8,452

Post » Tue Jun 18, 2013 5:45 pm

@Nimtrix doesn't that mean you are also now using double the amount of pixels to do the same thing as the tiled background and the sprites both overlap eachother and even if transparent it still gets it's pixels rendered. Maybe not an issue on some platforms, but if you look to go mobile that could quickly cause performance issues. Just a thought...
B
49
S
12
G
10
Posts: 1,833
Reputation: 14,573

Post » Tue Jun 18, 2013 6:07 pm

@BluePhaze:
Well, sort of, but if you're developing for mobile using sprite objects as tiles is a very bad idea in the first place.

And as the manual describes, a TiledBackground object is a lot more efficient in rendering, so it wouldn't be twice the amount of pixels, only the equivalent of one extra sprite object, in this case 32x32.

But the TiledBackground object doesn't need to be 32x32, it could be 1px in size. Or you could set them to invisible, which if I remember correctly will skip the draw call so that only logic is calculated for that object (not 100% certain this is true).

[quote=Manual]Creating too many objects can cause slowdowns, and a common mistake is to use grids of Sprite objects instead of Tiled Background objects. For example, a 20x20 grid of sprites has 400 objects, which is a significant impact on the object count. A single tiled background can replace the grid of sprites and it only counts as a single object. Tiled backgrounds are specially optimised for repeating their texture so in this case it is literally 400 times more efficient than the grid of sprites. Always use Tiled Backgrounds instead of repeating Sprites wherever possible.[/quote]

So what I'm trying to say is; I don't think the extra TiledBackground object matters, but using sprites instead of tiles does.
B
27
S
8
G
8
Posts: 903
Reputation: 8,452

Post » Tue Jun 18, 2013 6:30 pm

The size of the object is different than the amount of video memory that is used. On a mobile platform you get overdraw if you render more than about 3 time the number of pixels on the screen. This is true regardless of the actual size of the graphic. This is about how many of the pixels on the screen are being drawn and how many times per tick.

A one pixel tiled image, still uses all the pixels of the screen if you tile it across the whole thing, so while the object itself uses hardly any memory, your video memory is using a lot as it is storying the value of each pixel rendered. Overlapping this with another object increases the video overhead for rendering the screen.

So regardless of tiled vs. sprites, the video memory is based on pixels rendered, not on the size of the object being used to draw them. Two different areas of memory.

You can refer to the following threads for more info, also here is a quote on the mobile overdraw issue:


[QUOTE=Ashley]
Mobile overdraw

While we're on the subject of mobile limitations, it's worth mentioning some mobile devices can only draw each pixels 3 times per frame and still reach 60 FPS. In other words, if you have four window-sized images on screen, you cannot reach 60 FPS on such a device. (Note Construct 2 renders scenes from the back to the front, so four overlapping objects are all still rendered.) Perhaps surprisingly, this includes transparent pixels. The GPU processes the full rectangle of a texture regardless of the content, and a transparent pixel still uses up your drawing budget, so four window-sized transparent images would still not reach 60 FPS. Similarly with memory usage, this is a device hardware limitation and you'll have the same limitation with any framework.

The solution here is again to prefer using small images instead of large ones. A large image will eat up lots of the mobile's drawing budget in one go, whereas it's easier for it to render several spread out smaller objects. For example, a window-sized sprite to add borders round the edge of the screen is very inefficient, since the transparent pixels in the middle still use up the draw budget; using four separate sprites for each edge of the screen would be a lot faster.
[/QUOTE]

You can find more about properly composing your backgrounds here:

The "Right" Way to do backgrounds in C2

And Ashley's blog post where the quote was taken from:

Remember not to waste your memory
B
49
S
12
G
10
Posts: 1,833
Reputation: 14,573

Post » Tue Jun 18, 2013 7:03 pm

@BluePhaze
Like I said, I wouldn't recommend using this for mobile devices, and personally I wouldn't use it at all, I design my levels manually, but he asked, so I provided a solution.

Anyway, I was generally talking about PCs in my last post. I'm not going to argue anything on mobiles since I know little to nothing about it.

As for the 1px sprite I see what you mean, but I found the thread about invisible objects and as far as I understand it, setting it to invisible should skip the drawing of the sprite, saving you the VRAM usage:

[quote=Ashley]Offscreen objects are not drawn, and objects set invisible are not drawn (although objects with opacity 0 are still drawn)[/quote]

As for sprites vs tiles, are you saying a 320x320 area of 32x32 sprites would use the same amount of VRAM as a 320x320 TiledBackground based off a 32x32 sprite? Nimtrix2013-06-18 19:06:26
B
27
S
8
G
8
Posts: 903
Reputation: 8,452

Post » Tue Jun 18, 2013 7:32 pm

@Nimtrix For VRAM yes, because VRam is based on how many pixels of the screen are being rendered, not on the size of the file/object in memory. So a 1 pixel .png stretched across the whole screen will use very little system memory but still the whole screen worth of video memory unfortunately. If you stretch a 1px image across the whole visible screen, you are stretching it across however many pixels the screen resolution is using and it has to hold the color value for each pixel on the screen in memory. Kind of sucks.

I am currently working on a game for both Windows 8 and Windows Phone 8 so am having to juggle constantly if I want to keep both versions as similar as possible.
B
49
S
12
G
10
Posts: 1,833
Reputation: 14,573

Post » Tue Jun 18, 2013 7:42 pm

@BluePhaze:
Kk, thx, just wanted to make sure I understood correctly. It makes sense though, I see how this can be a major issue with mobile devices. But I'd imagine setting it to invisible would take care of that problem though? No pixels rendered, no VRAM needed.
B
27
S
8
G
8
Posts: 903
Reputation: 8,452

Post » Tue Jun 18, 2013 7:48 pm

@Nimtrix Right, that should fix it according to the documentation. Another way would be to use variables and base it off of the viewport or window as they are rectangles you may be able to just use the size to figure out where to tile it, etc... though that may get complicated if you are publishing to multiple sizes. Basically calculate where the tiles should begin instead of sticking them to another invisible sprite.
B
49
S
12
G
10
Posts: 1,833
Reputation: 14,573

Post » Tue Jun 18, 2013 8:02 pm

@BluePhaze:
Yeah I thought about that earlier. It's a viable alternative, although not as visual in the editor so it might be difficult for the developer to imagine where the rectangles would be amongst all the other objects in the layout. And as you said you'd have to calculate scale manually. More like programming, so it sort of defeats the purpose of C2.
B
27
S
8
G
8
Posts: 903
Reputation: 8,452

Next

Return to How do I....?

Who is online

Users browsing this forum: 99Instances2Go, db3344, Hiddendanger and 2 guests