Hey puck pao, <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

If I understand correctly, whenever you roll your mouse pointer over a menu item, like "Start" or "Options", you want a "blip" feedback sound to play once, without looping or continuously triggering every tick (the machine gun effect).

You can probably achieve this by adding the System > "Trigger once while true" condition to the mouse over event.

So you would get the following:

Event:

• Mouse is over object menuItem.
• Trigger once while true.

Actions:

• Play sound "Blip"

This will trigger once when the mouse first moves onto a menu item, but it won't trigger again, until you move off the item and then back on again.

You can read more about the "Trigger once while true" condition in the Construct manual at the link below.

https://www.scirra.com/tutorials/292/gu ... t-features

Hope that helps out. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Is there a way to copy a family from one project to another?

Copying project files or XML data?

This is more a question that I suspect Ashley or one of the other power users might be able to shed light on. Is there a way to copy a family from one project to another by fiddling with the internal project files or project XML data? (i.e. Assuming I save the project as a folder instead of a single file.)

Families are a really cool addition to ACE-style programming, and I would love to find a method for using them in a more portable way.

Why I'm interested

I'm looking to make modular prefab systems, like a menu system.

By prefab, I mean a self contained set of events and objects that can be copied from one project to another easily. That way, when I need menus, I can just copy the menu prefab events and objects into the new project.

I've been using this prefab workflow for a while already, and it works great for any prefabs that don't need to use families, but as soon as I need to have a family be part of a prefab, I encounter a problem. Everything seems portable between projects except families.

I know that you can technically exactly reconstruct all the families you wish to copy in the target project, but that starts getting fairly complicated and lengthy as the use of families becomes more complex. Families are a fantastic tool, so I would love to be able to move them between projects easily.

There are some other reasons I'm interested, but that is the big one.

Thanks in advance for any thoughts or suggestions.

Hey RadDevVan101,

So if the two objects never go invisible, then it seems like somehow the two values ("Web" value & "Project" value) are never considered to be the same, even when it looks like they should be.

From here on I'll refer to the two objects as the "Sprite", to make things simpler.

I'm assuming that somewhere in your event's there's an event that looks something like:

If Web == Project: Then Set Sprite Invisible.

Firstly, as a test, I would try changing that event's condition to always be true (i.e. Delete just the condition, or test for 1 == 1 or something) to make sure that the event is even capable of turning the Sprite invisible at all.

When you run the test described above, the Sprite should turn invisible as soon as that event runs, regardless of the Web and Project values.

If that works, and the Sprite becomes invisable, then you know that the event does get executed, but the Web == Project test is always false for some reason. If so, be sure to undo the changes to return the event to it's original form. On the other hand, If the Sprite does not turn invisible, it may mean the event is never actually running for some reason.

If the event is running, then the question is, "Why does Construct insist that the values never match?"

There are a few reasons the values might not match.

• There is a space before or after one of the version numbers, e.g. "1.0.0_"
• One of the values is being treated like a numeric data type (integer or float) at some point in your events, or in an expression. That would cause "1.0.0" to become "1", which will not match "1.0.0" if you compare strings.
• You might be storing one of the values in a Construct2 variable, that is set to "number" instead of "text".

Finally, you can try printing out the values to an other text object when the event runs so you can see exactly what the values are at the instant they are being compared. To do this, add another text object to your layout, (e.g. named "debugText"). Then in the Web == Project event, add an action print the Web and Project values to the debugText object.

Hope that helps.

Hey ericksr,

When adding an "On button index pressed" condition, one of the values you can specify is the "Gamepad" number. This number is "0" by default, which essentially means the first player. "1" would be the second player, "2" would be the third player, and "3" is the forth.

So, to create an event that detects only the second player pressing the jump button, you would use the "On button index pressed" condition and enter "1" for the "Gamepad" number.

I'm not sure if this will help, but I can share a little of my own experience with optimizing, via the use of "every-x-seconds conditions".

If there is a lot of collision checking going on in a single event, and you can get away with doing it less often than every tick, that's the main place I've actually seen directly visible performance gains.

Though I suspect that pretty much any non-tick-essential event, if it's already eating up a large share of your game's CPU budget, is a good candidate for demotion from per-tick to every-x-seconds.

Example

As a practical example, in ArcherOpterix, the phantoms check to see if they are touching a wall, so they can reverse direction. That check uses an "overlapping at offset" condition. The phantoms move slowly, so I didn't really need it running absolutely every tick. I switched it from every tick to every 0.2 seconds, so the phantoms behaved identically to the naked eye, but the game ran about 2 to 3 times faster.

Now that said, I'm not sure why I wasn't then just getting a minor slowdown every 0.2 seconds. But I didn't. The game ran smoothly. I thought it was a bit weird, since my game should still be running all of the collision checks on a single tick every so often, and in-between there would be a bunch of far less demanding ticks.

So if the work load isn't being spread over multiple frames automatically, and I don't think it is, at least not at the C2-event level, then maybe there's some hapless downstream system that gets backed up if you just pile tons of work onto it, until you start to see that burden manifest as a performance hit.

In hindsight, I could have given each phantom a random group number from 1 to 10, and then just handled one group per tick, round-robin style, to spread out the work load a little. Though the every 0.2 seconds optimization worked so I've left it with that.

Hey again Sam, <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Ashley actually wrote up a really cool explanation and analysis of C2's render cell system, which you can find here:

https://www.scirra.com/blog/ashley/14/h ... cells-work

If you're more interested in "how to use it" than "how it works", You may want to jump to the following sections:

• When to use it?
• When to avoid it?
• Extra tips

That said, if you have the time, it's worth reading the whole thing, to get an idea of how and why the benefits of render cells are so dependent on the situation.

From what I gather, render cells are per-layer, so for any layer that will have tons of essentially static objects out of frame, it might be a good candidate. So the main game layer, with enemies and particles and such, not so much; but a static decorative backdrop layer, with tons of individual objects, might be a good candidate.

In your case, with mixed layers, any moving object will need it's render cells updated, but that may not amount to that much if there are 1000 static objects and only 10 moving ones.

Ultimately you may want to just try it out both ways and see if there's any noticeable change in performance. You may be able to use the debug preview mode to get an idea, as it has a built-in performance profiler, though definitely click the "undock" button on the debug panel to separate it from your game window, or you'll likely get a performance hit just from the debug window itself.

Hey Mortimer,

Off hand, I doubt it would harm performance.

If I recall, the "every" condition is tested each tick rather than being triggered by an internal timer.

I don't know for sure, but I would think the way the "every x seconds" condition is handled internally, is that the condition has a single hidden variable that gets incremented by the delta time (time since last tick) each tick. Then, each tick, the condition is tested to see if the total amount of time in that variable exceeds the "every" amount specified.

So multiple "every" conditions would just have the extra variable, increment per tick, and check per tick as overhead, which hopefully shouldn't be that much.

If anyone is more familiar with the inner workings of the "every x seconds" condition, feel free to correct my speculation.

Thanks for all the info Ashley.

Yeah, waiting on WebGL 2 sounds like a good call. It's cool that they're including non-power-of-two textures, as they are admittedly a less common sort of thing.

I was actually just talking with R0J0hound about the multiple margin configurations and vram issue.

My initial thought:

[quote:4n0mj7zo]It might be best to store the split up images in the object type, but make a unique split-image-set for each unique margin configuration in the layout. That way if you have 100 9Patch instances, but only 2 different margin configurations among them, (e.g. 4,4,4,4 and 8,8,8,8) you'll only have to store a single "4,4,4,4" image set and a single "8,8,8,8" image set, and the 100 instances will just point to one of the two.

While it's certainly true that using 100 different margin configurations would require 100 different patch sets in vram, in most practical cases where I've been interested in different margin configs, it's only been 1 or 2 extra. Though, those are basically always cases where a 9-Patch object is narrower than the sum of its margins on the relevant axis.

e.g. If a 9-Patch has 8px top and 8px bottom margins, then you can't shrink the object's height below 16px without introducing margin patch overlap. For instance, if you set the object's height to 8px, then you would need to modify the margins to be 4px top and 4px bottom, to keep the meeting point of the margins centered.

Below is an image showing a block with 8px margins on all sides.

On the top in the reddish box all example sizes use 8px margins even as the object's width and height drop below 16px accross. On the bottom bluish box, the first 3 columns of example sizes use 8px, and the last 3 columns (narrower than 16px) use increasingly smaller custom margin settings to keep the meeting line centered.

This is partly why I was thinking that in practical cases there would often only be 1 or 2 extra sizes, because realistically even 3 special size gradations (as seen in the image) is more than usual. In the game I'm currently working on, I only have 1 variant of my "8,8,8,8" block, and that's a 4,4,4,4 block.

(click to enlarge)

Another possible approach, (though I'm not sure how the graphics are placed on quads so I'm not sure if this is realistic), might be to have the quads automatically trim themselves as the object's size gets too narrow. and just let the UV's hang off the edge of the trimmed quad to mask them out.

Because the case shown in the image is the only case I really know of where special margin configs are regularly useful, the automatic quad cropping would produce the exact same result without requiring anything extra to be stored in vram.

Anyway, thanks again for the info.

Problem Description

I may have come across 2 graphical issues related to the 9Patch object. I hope it's okay to incorporate them both into a single bug report. They aren't quite related, but they can manifest simultaneously, and do in the example capx.

1. Pixel distortion:

Pixel rows and columns are rendered with varying thicknesses (plaid-like) rather than as a uniform pixel grid.

(see image below)

2: UV coverage issues:

If multiple instances of a 9Patch object have different margin settings, only instances with settings matching those of the instances at the backmost z-index will render correctly.

(see image below)

Attach a Capx

Here's an example capx.

Description of Capx

The capx has two layouts, one shows the effect in "Image 1", and the other layout shows the effect seen in "Image 2".

In the first layout there are also two extra 9Patch objects that should look okay even during runtime as they have their margins set so that the sliced "patches" of the source texture all have power-of-two dimensions.

Note: If the patch dimensions are powers-of-2, then the distortion will not occur in webGL, but any other dimensions cause the distortion. Possibly related to gl.REPEAT requiring power-of-2 textures. The power-of-two dimensions does not fix the other UV coverage issues though.

Steps to Reproduce Bug

• 1. In the project settings, make sure webGL is enabled, and set sampling to "point ".
• 2. Add a "start of layout" event to scale up the layout by 8x or so at runtime (as you might do for pixel/retro-looking games).
• 3. Add a32x32 9Patch object with any detailed per-pixel pattern.
• 4. In the 9Patch properties, set all margins to 4px.
• 5. Set Fill and Edges to "Tile".
• 6. Set Seems to "Exact".
• 7. Resize the 9Patch so that corner, edge, and fill zones are all visible.
• 8. Run the game. (Make sure the 9Patch is centered as you'll be zooming in 8x.)

Result: In the runtime window, you should see distortion artifacts in the 9Patch pixels, similar to those shown in "Image 1". Conversely, if you look at the same 9Patch in the editor, zoomed to 800% (use Ctrl + Shift + MouseWheel), it should look correct, with no distortion.

• 9. Now, create another instance of the same 9Patch object but set all its margins to 8px. (You should now have an 8px-margin instance of the 9Patch object, in addition to the original 4px- margin instance.)
• 10. Run the game.

Result: In the runtime window, you should see distortion, just as before, but you should also see that the new 8px-margin instance is tiling its edges and fill in what looks like a smeared and chopped up jumble.

Observed Result

1. Pixel distortion:

Pixel rows and columns are stretched and squashed, such that the pixels that make up the texture take on a plaid-like distribution, with some rows and columns being wider than others, rather than a uniform pixel grid.

R0J0hound tested and confirmed this, also noting that it only occurs when using the webGL renderer, but not the canvas2D renderer. (Though the "UV coverage issue" occurs regardless of renderer.)

Image 1 - Pixel distortion

Shown, several instances of a few test patterns, and a stone block from a game of mine, in which I first began investigating the occasional 9Patch runtime render issues. Both are zoomed to 8x scale. The Editor is at 800% zoom, and the "In game" runtime has the layout scaled by a factor of 8 via events.

(click to enlarge)

2: UV coverage issues:

If multiple instances of a 9Patch object have different margin settings, each unique margin configuration will not get its own uniquely sliced image patch set. Instead all instances will use the image patch set created for the instance with the backmost z-index, and only instances with margin configurations matching that backmost instance will be rendered correctly.

R0J0hound checked the code in the plugin when I inquired about tracking down the UV math to see if that was the issue. He suggested that this issue is due to the sliced image patch set being stored in the object "type".

I think this may mean that only one sliced patch set is ever created, and all subsequent instances use that set regardless of margin settings.

Image 2 - UV coverage issues

Note: It's the Z-order at game start that matters. Once the game is running, rearranging the Z-order won't affect how this issue manifests. So in my example capx, if you want to see the effect of a different instance acting as the backmost boss-instance (not sure what to call it), you'll need to change the Z-order in the editor and relaunch the game.

(click to enlarge)

Expected Result

1. Pixel distortion:

Expected pixels to be square, uniformly sized and rendered as a geometrically uniform grid. Much as you would expect to see if zooming in on pixel art in a graphics editor.

2: UV coverage issues:

Expected the per-instance customizability of the margin settings to result in corresponding UV coverage and tiling on a per-instance basis.

Affected Browsers

• Chrome: YES
• FireFox: YES
• Internet Explorer: YES

Operating System and Service Pack

Win7 x64 - Pro

SP1

Construct 2 Version ID

Release 218 (64-bit) checked

Built at 14:06: 17 on Nov 25 2015

Release Notes

Thanks for helping to test it out —

Good catch too, I hadn't thought to test the canvas2d renderer.

I just tried the canvas2d renderer, and I can confirm what you said:

The pixel distortion seems to occur on webGL, but not with canvas2d.

Likewise, both renderers still exhibit the Z-order problem.

I also just added a note to the first post mentioned that the Z-order problem is dependent only on the Z-order at game start. I kind of mentioned this in the capx, but I realized it should be in the main post.

• Importantly, it is the Z-order at game start that matters here. Once the game is running, the Z-order can be rearranged, but the cross-instance render contamination will still come from whichever instance had the back-most Z-order when the game started. So in my example capx, if you want to see the effect of a different instance acting as the back-most contaminant-instance, you'll need to change the Z-order in the editor and relaunch the game.

I've noticed some pretty weird render artifacts when using 9Patch objects.

(See the images below)

Questions

Is it possible that this is a bug? (I don't want to jump to conclusions as I've only investigated this on one computer.)

If anyone knows a workaround for the following issues, please let me know.

Image 1: Pixel shape distortion

Shown, several instances of a few test patterns, and a stone block from a game of mine, in which I first began investigating the occasional 9Patch runtime render issues. Both are zoomed to 8x scale. The Editor is at 800% zoom, and the "In game" runtime has the layout scaled by a factor of 8 via events.

(click to enlarge)

Some background

I make pixel-style games that incorporate some custom post-processing effects to keep everything properly pixilated, and for a long time I thought that my processing chain was occasionally causing these weird 9Patch render artifacts.

A day ago, I finally decided to investigate and fix the issue, once and for all, but after fiddling with the math in various stages of my processing chain to no avail, I began disabling stages of the chain, until I had disabled everything, but the artifacts remained.

I then tried reproducing the 9Patch render artifacts in a new blank project. It took a while to figure out, but it turns out it's pretty simple to set up.

Example capx

Here's an example capx.

The capx has two layouts, one shows the effect in "Image 1", and the other layout shows the effect seen in "Image 2".

In the first layout there are also two extra 9Patch objects that should look okay even during runtime as they have their margins set so that the sub-zones of the source texture all have power-of-two dimensions. The power-of-two dimensions does not fix the Z-order issue, explained below.

Image 2: Z-order issue

As far as I can tell, the Z-order artifacts are a totally separate phenomenon from the distorted pixels described above and shown in "Image 1".

Given a set of 9Patch instances, with different margin properties, the properties of the lowest Z-order instance (back-most and first to be rendered) will contaminate the rendering processes of all subsequent instances.

Specifically, any subsequent instance will use its own margin properties to partition its internal space into corner, edge, and fill zones, however it will then use the margin properties of the back-most instance when determining how to sample the source texture to fill those zones. This causes the smearing (UV clamping), and partially missing (UVs run off the edge) edge and fill artifacts seen in the image below.

[edit] Importantly, it is the Z-order at game start that matters here. Once the game is running, the Z-order can be rearranged, but the cross-instance render contamination will still come from whichever instance had the back-most Z-order when the game started. So in my example capx, if you want to see the effect of a different instance acting as the back-most contaminant-instance, you'll need to change the Z-order in the editor and relaunch the game.

(click to enlarge)

Reproducing the issues

• 1. Set the project to use "point sampling".
• 2. Add a "start of layout" event to scale up the layout by 8x or so at runtime (as you might do for pixel/retro-looking games).
• 3. Add a32x32 9Patch object with any detailed per-pixel pattern.
• 4. In the 9Patch properties, set all margins to 4px.
• 5. Set Fill and Edges to "Tile".
• 6. Set Seems to "Exact".
• 7. Resize the 9Patch so that corner, edge, and fill zones are all visible.
• 8. Run the game. (Make sure the 9Patch is centered as you'll be zooming in 8x.)

Result: In the runtime window, you should see distortion artifacts in the 9Patch pixels, similar to those shown in "Image 1". Conversely, if you look at the same 9Patch in the editor, zoomed to 800% (use Ctrl + Shift + MouseWheel), it should look correct, with no distortion.

• 9. Now, create another instance of the same 9Patch object but set all its margins to 8px. (You should now have an 8px-margin instance of the 9Patch object, in addition to the original 4px- margin instance.)
• 10. Run the game.

Result: In the runtime window, you should see distortion, just as before, but you should also see that the new 8px-margin instance is tiling its edges and fill in what looks like a smeared and chopped up jumble.

It took me a while to figure out what exactly was happening. I made a texture to help visualize the UV mapping. It appeared that the 8px-margin instance was correctly partitioning its interior into 9 sub-zones using the 8 pixel margin metrics set earlier. However, it was filling in those sub-zones by sampling the source texture as if it were using the 4 pixel margins set for the back-most instance.

This works the same way for whichever instance is back-most in Z-order. All other instances erroneously use the margin metric set in the properties of the back-most instance when sampling the source texture. (You can see this in "Image 2")

Again, this may be something locally weird on my computer, so if anyone else has encountered this, tries the example capx, or reproduces any of these issues, I'd be interested to hear what you found.

Thanks for enduring my wall of text. :)

What you're looking for is exactly what R0J0hound mentioned. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Setting the origin point

If you double click on the collision sprite object, the image editor should open.

In the image editor, on the left-hand toolbar, choose the 2nd tool from the bottom (looks like a crosshair). This is the "Set origin and image points" tool.

With this tool selected you can set the origin point of your object wherever you want. You can also use the number-pad on your keyboard to quickly snap the origin point to the center edges or corners of the sprite image, though Num-Lock must be enabled for this.

If the default images of your sword and character face rightward, then for your collision sprite, you'll probably want to put the origin point on the far left edge. You can press numpad-4 to do this, if Num-Lock is enabled.

Accept the changes and then try it out in the editor by holding down Ctrl + Shift and Dragging one of the corner resize handles on your collision object. It should now scale around the new origin point you just set.

(You'll want to undo that resize afterwards of course. Be careful not to also undo the change to the origin point.)

Flipping the sprite

As for flipping or mirroring the object, in that object's actions, in the Appearance group, you can use the "Set Mirrored" action to flip the object horizontally, and the "Set Flipped" action to flip the object vertically.

C2 Manual Page on Image Points

https://www.scirra.com/manual/63/image-points