Tile with Variant

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.

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)

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

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

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.

So what I'm trying to say is; I don't think the extra TiledBackground object matters, but using sprites instead of tiles does.

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:

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.

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

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:

Offscreen objects are not drawn, and objects set invisible are not drawn (although objects with opacity 0 are still drawn)

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?

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.

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.

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.

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. <img src="smileys/smiley1.gif" border="0" align="middle" />

Nimtrix yeah, my background is as a developer so I am just used to going that route first. Though if you did it based on a percentage of the window like the halfway point, etc... then it would work across multiple resolutions as well. Not sure if the overhead of an extra calculation would offset the extra object or not though resource wise.

THanks for the replies.

I'm building art on the fly for random generated lavels, and I read that the tiled object was less expensive than the sprites, so that's why I asked.

I was wondering if COnstruct has a feature that lets you pre-render images before they are used in the game (so I don�t need to place one sprite on top of the other)

BluePhaze

just was reading this and i think your point about vram usage is not quite right (if i understood you right)

i quote ashley here (from optimize blog responses about vram)

"only the source image is kept in memory (what you see in the image editor"

so this means that a stretched out pixel uses less vram then lets say a 32*x32 black image or transparent image, so stretching it over the screen will not add to vram, but is not advised because your likely to have more overdraw (stacking images) wich i read is slow on mobile and also that transparency overdraw and transparency in general is slower for the gpu than opaque

also using the same image(sprite) multiple times doesn't increase vram, it is however slower using lots of objects

vtrix There is the amount of memory the object uses, and then there is the amount of memory used to store the color value for each pixel on each refresh of the screen. WHile a 1 px image takes up a small amount of memory on the system, if you stretch it across the screen your 1 pixel image is covering however many pixels the screen is rendering which means that the buffer must now store that color value for every pixel on the screen.

Since C2 games are rendered back to front, each layer in the back renders first and hence it's colors get stored in memory for each pixel and then as the layers above it are drawn in this happens for each layer. So the more overlapping layers you have the more color values must be stored in each frame. This is the memory I am speaking of. The memory used to store the color value for every pixel on the screen.

BluePhaze i think what you speaking of is called a framebuffer, but when we talk about vram in construct its the uncompressed size of an image, it was that i was pointing to, as it doesn't matter if you stretch an image for vram size, i dont know how much impact this framebuffer has on performance, i guess there's where overdraw comes in.