Hey Rhindon,

Blend mode exploration program

I created a demo of the C2 blend modes that makes it easier to experiment with them.

(Update 1: I made an update that includes a realtime subpixel model visualization.)

(Update 2: I made a new version (v4b) you can download here, or try on Scirra Arcade.)

(Update 3: Version (v4e) small fixes, and Scirra version now shows link to this post correctly.

Win64: fi_BlendCompositeModes_v4e_win64.zip

OSX: fi_BlendCompositeModes_v4e_osx64.zip

Scirra Arcade: Blend composite modes sandbox

The subpixel model is shown at the right, and updates in realtime, as you adjust the opacity settings.

Overview

(This post got a bit bigger than I was expecting.)

I'm going to try and answer this in three parts.

1: The quick answer (Basically TL;DR because there's a lot to R)

2: What does "Additive" do?

3: What do the other modes do?

But before going into the details, I'll try to give what might be a more intuitive answer, even if it's less explanatory.

--------------------------------------------- The quick(ish) answer ---------------------------------------------

Terms: The term "Destination" means the background, and "Source" means the foreground object.

The Additive blend mode

Additive: Directly adds the Source (foreground object) and Destination (background) color values. If the Source object is 50% gray (middle gray) and the Destination background is also 50% gray, then Additive blending the Source into the Destination will result in 100% "gray" which is white.

The transparent Destination problem

All of the other blend modes are transparency compositing modes. (explained in more detail later)

When Construct renders a scene, it goes through the objects in Z-order, from bottom to top, and pastes them one-by-one into the background.

Each time it's about to paste an object, THAT object is the Source, and everything else that has already been pasted is the Destination.

The bottom layer of most projects has a solid color like white. This is the first thing that will get pasted, and it will make the entire background (Destination) solid and totally opaque.

The other blend modes rely on the background (Destination) to have some transparency. This is a problem, because If the Destination had a solid background color blended into it then it will be solid everywhere, and will never be transparent.

We need a transparent blank slate (like a special layer) we can render on separately from the rest of the main game. So, after we blend some objects onto that special layer, we can then paste that entire layer into the game.

A normal layer won't quite work, because even if the layer has a transparent background, when Construct goes to paste a sprite from that layer into the background, the background will be the rest of the game objects that were already pasted, including the solid background color from the bottom layer.

It turns out we can create that special layer described earlier. Create a layer with a transparent background, and then in the layer's properties, set "Force own texture" to True. This will force the layer to render separately from the game, and it will start out totally transparent.

The other modes

Destination Over: Put the Source object behind the Destination. You'll see the Source object peek through wherever the Destination is transparent.

Source Atop: This is exactly like blending onto a clipping mask. This paints the Source onto the Destination like a skin. Where the Destination is transparent the Source will not appear.

Destination Out: Punch a transparent hole in the Destination, using the opacity of the Source. Where the Source is opaque the Destination will be made transparent.

Destination In: Punch a transparent hole in the Destination, using the transparency of the Source. Where the Source is transparent the Destination will be made transparent.

All the others: The other modes all do kind of weird stuff that's generally not very practical (at least as far as I've found), either because they're just the reverse of a more manageable mode described above,

or because they don't appear to work, as is the case with XOR.

(edit: 99Instances2Go pointed out that XOR doesn't work in webGL, but does work when webGL is disabled.)

My understanding (and I may be wrong) is that this list of modes comes from HTML5, so many of them are included in Construct for completeness rather than because there is a common usage for them.

--------------------------------------------- What does "Additive" do? ---------------------------------------------

Additive blend mode

A source image sits over a destination image. Each pixel in the source image is sitting over a pixel in the destination image.

For each overlapping pair of pixels:

Additive says add the Red value from the Source pixel and the Red value from the Destination pixel, and use that for the resulting pixel's Red value. Likewise, add Source and Destination Green values to get the resulting Green value, and same for the Blue values.

So, suppose you have a Sprite that's 1 pixel by 1 pixel wide (pretty small) and it's RGB color is (50, 0, 50) dark purple, and it's on a gray background colored (10, 10, 10). If you set the Sprite to Additive blend mode, the resulting color you get from blending it is (50 + 10, 0 + 10, 50 + 10) which is (60, 10, 60).

--------------------------------------------- What do the other modes do? ---------------------------------------------

"Alpha"

The term "alpha" in computer graphics, (in this case anyway) basically means "opacity".

(As in "opacity" vs "transparency".)

In the same way that an image has a red channel to tell each pixel how red it should be, an image's "alpha" channel tells each pixel how transparent or opaque it should be. For a given pixel, an alpha value of 0 means totally transparent, whereas alpha at maximum means totally opaque.

"RGB blend modes" - vs - "alpha compositing modes"

The term "blend mode" is a bit broad in a way that can be confusing.

There are "blend modes" as in fun with RGB math. (normalish-color-blending)

And there are "blend modes" as in "alpha compositing modes", which merge images in weird and not-so-weird ways based on their transparencies. (weirdish-transparency-blending)

I will use the term "alpha compositing mode" for that weirdish-transparency-blending kind for the rest of this post to avoid confusion.

So to clarify, RGB math blend modes (normalish-color-blending) is what you find in programs like Photoshop and Gimp.

e.g. Additive, Multiply, Screen, Lighten, Difference, etc.

They all do different RGB math, but they all treat transparency exactly the same nice and intuitive way.

By contrast, alpha compositing modes (weirdish-transparency-blending), is more like working with clipping masks and hole-punches, and occasionally ... angry ghosts.

They also have weirder names.

e.g. Destination Out, Source Atop, Destination Over, ... XOR!

Now you may have noticed that "Additive" is in the "RGB blend modes" group, and "Destination Out" is in the "alpha compositing modes" group,

and yet, both are listed in the same dropdown menu in Construct 2. It's not incorrect to call all of them "blend modes", but it's an example of what I meant earlier when I said the term "blend mode" can be confusingly broad, especially when you're starting out.

Some Background (so to speak)

So another term for those "alpha compositing modes" is "PorterDuff" modes.

Named for Thomas Porter and Tom Duff, the Toms.

They came up with a simple system for describing the alpha compositing of images.

Specifically they noted all possible simple alpha compositing modes, and named them.

These are the 12 modes. (I'll abreviate Source as "s" and Destination as "d")

s over

s copy

s atop

s in

d over

d copy

d atop

d in

xor

s out

d out

clear

So, there are 12, but Construct only includes 10 of them, omitting "d copy " and "clear", because those two are not especially useful. (We'll see why later.)

In Construct "s over" (Source Over) is listed as "Normal", because this is the basic and intuitive "one thing is on top of another thing" compositing mode.

What do "alpha compositing modes" do?

So what did Porter and Duff figure out. Why are there exactly 12 modes?

To understand we need to think about individual pixels instead of the entire image.

Let's try to walk through the most basic "alpha compositing mode", which is "s over" or "Normal" as Construct calls it.

We'll start with a Blue Source and Orange Destination image.

Now let's assume our Blue Source and Orange Destination are just 1 pixel each.

The Source pixel is sitting directly over the Destination pixel.

Next, imagine that both pixels are half transparent.

The Orange Destination pixel has an opacity of 50%.

The Blue Source pixel has an opacity of 50%.

What should the Resulting pixel look like?

Let's start with an empty Result pixel.

To add the half transparent Destination pixel, we'll slice the Result pixel in half, with a horizontal divider, and fill in the top half Orange, leaving the bottom half empty.

The result pixel is now 50% Orange. (The top half)

Next, To add the Blue Source pixel, which is also half transparent, we'll slice the Result pixel in half, with a vertical divider, and fill in the left half Blue.

When we fill in the Blue for the Source pixel, we cover up some of the Orange from the Destination pixel, and we also cover up some of the left over transparency.

In the diagram below, the very bottom left square shows this "sub-pixel" breakdown of the Result pixel.

The orange slice on the top, and the blue slice on the side, partially covering the orange slice.

Notice that the result pixel has been split into 4 chunks.

* Source only

* Destination only

* Both (Source and Destination)

* Neither

In the example we walked through, we colored the "Destination only" chunk Orange, and the "Source only" chunk Blue, and the "Both" chunk we colored Blue as well, because in the "s over" (Source Over) mode, the "Source" gets to paint "Over" whatever lands in the Both chunk of the result pixel.

Now, notice that if we turned the opacity of the Source pixel up to 75%, this would push it's slice over to the right so that Blue would fill 75% of the pixel, and there would be even less of the Orange showing through. If we turned the Source pixel up to 100%, the Blue would push all the way to the right edge and totally cover the paint from the Orange Destination pixel.

That's the last important concept in the slicing-up-the-result-pixel analogy. When you change the opacity (the alpha) of a Source or Destination pixel, you change where the slices end up, and thus how much of the pixel each chunck covers.

If that's the "Normal" mode What about the others?

So, we just walked through 1 possible process for allocating Source and Destination colors to the 4 chunks of that Result pixel.

What if we did something weird though, like put the Orange destination color in the "Both" Chunk?

Well we'd get the "d over" (Destination Over) mode, where the "Destination" gets to paint "Over" whatever lands in the Both chunk of the result pixel.

Why 12?

So how many combinations can we come up with from this system?

Well, if we don't allow Source and Destination to be allocated to chunks they should never be in, then we get the following:

* Neither: This chunk will always contain nothing. That's it's 1 and only option.

* Source only: This chunk can contain the Source color or nothing. 2 options.

* Destination only: This chunk can contain the Destination color or nothing. 2 options.

* Both: This chunk can contain the Source color, or the Destination color, or nothing. 3 options.

So that's 1 * 2 * 2 * 3 combinations, which is 12.

So why does Construct omit some of them?

Well one of the combinations is allocating nothing to all 4 chunks. That one's called "clear" ... yeah.

Not so useful, since it just erases everything in every pixel all the time. (I told you we'd see why later.) :]

Table of alpha compositing mode

So now that we've seen that each alpha compositing mode is just some combination of filling in pixel chunks with either Source, Destination, or Nothing, could we visualize that as a table?

Yes!

        .------Chunks------.
MODE:      S:   D:   Bth: Nth:
----------+----+----+----+----
s over     s    d    s    -      (usually just called "Over" or  "Normal")
d over     s    d    d    -
  xor      s    d    -    -
----------+----+----+----+----
s          s    -    s    -
d atop     s    -    d    -
s out      s    -    -    -
----------+----+----+----+----
s atop     -    d    s    -
d          -    d    d    -
d out      -    d    -    -
----------+----+----+----+----
s in       -    -    s    -
d in       -    -    d    -
clear      -    -    -    -
----------+----+----+----+----[/code:2ao8g29a]

Sorry for the long post.
Hope this helps.

No problem, glad it worked out.

Hey claurent9,

I spent some time trying to figure out what was going on, and to summarize my findings, you can drag the music files from the "Music" folder, into the "Sounds" folder, and that should solve the Firefox issue.

What I tried

I tried running your project in Chrome, Opera, IE, Iron, NWjs, and Firefox, and only Firefox seemed to fail to restart the music correctly.

I added a hotkey to restart the music without restarting the layout, and that also failed to restart the music in Firefox, so the problem seems to be independent of the layout restart.

I ran the project in debug mode, and inspected the "Audio" object.

When the music plays for the first time, the "Currently playing" debug field reports the audio as playing, and shows the play progress in seconds for the audio file.

If the music is restarted, the "Currently playing" debug field reports the file as playing and shows the realtime progress just as before, but no audio plays.

So the Audio object thinks it is playing the audio file, but Firefox isn't creating any sound.

To use debug mode

1. Choose the "Home" tab on the ribbon, and click the "Debug layout" button.

When your project starts up there will be a debug panel in the bottom of the window.)

2. On the debug panel, on the bar, at the very right, click the diagonal arrow button "?" , to break the debug panel into it's own window.

The debug panel acts like an x-ray view into the insides of all the objects in your game.

Finally, I noticed that the music files were in the "Music" folder, instead of the "Sounds" folder.

I moved the files to the "Sounds" folder (you can just drag and drop from one to the other), in case the issue was streaming related, and afterwards the music restarted in Firefox, without a problem.

Possible cause

If I recall, the difference between the "Sounds" folder and the "Music" folder is only how Construct plays them. For files in "Music", Construct tries to stream them, whereas files in "Sounds" will be fully downloaded and played directly.

It seems like Firefox may handle streaming audio in a way that breaks when you restart it, at least in this case.

No problem.

Hey Greaver,

Window & taskbar icons

On the "Projects" panel, in the "Files" > "Icons" folder, edit the icon images by double clicking them.

They should open in Construct's image editor just like a sprite.

The folder looks like this:

But on your project, there will be gear icons, instead of tiny owls.

:

)

These are the icons used in the title bar of the game window, and the desktop taskbar task button.

The "loading-logo.png" image is used when your game is just starting up and still loading. This is the icon that appears above that little blue loading bar on the black screen.

Loader style

Somewhat related...

You can change the loader style (progress bar with or without icon, etc) in the Project's properties.

With the project selected, in the "Properties" panel, under "Configuration Settings", set the "Loader style" setting to "Progress bar and logo" to use the "loading-logo.png" image mentioned earlier. This may already be the default.

Hope that helps.

Thanks ALLMarkMade! If you make a theme you'd like to share, feel free to post it here, or in the Share your C2 themes thread.

Hey —, glad to hear it.

I replied to your post in the other thread, and made some preview images of your theme, which looks pretty cool by the way.

--- —

Hey very cool Bro7hers.

You might already know, but you can save example images like the ones I include in my posts with the "Save Preview" button at the top of the application. It will save a preview of the normal colors or the selected colors depending on which is visible when clicked.

I made some preview images of your Justice_Night theme as an example,

--- Cassianno

Thanks Cassianno!

If you get a chance to make a theme you'd like to share, I'd love to see it.

Just a heads up, there are still a few things I'd like to get around to adding in to the program, but the main one is that the "condition boarder" and "action boarder" are currently the only elements not shown in the selection preview mode, but I'll add that into the next update when I have time to get to it. In the mean time, it generally suffices to make them a lighter or darker shade of their respective background colors.

Good news everyone!

[Solved]

When applying forces, specifying image point "0" will apply to the center-of-mass, and image point "-1" will apply to the origin point set in the image editor.

I'm not sure if there's a good way to get in touch with Ashley, but it would be handy to have this added to the "Physics behavior" manual page for the "Physics actions: Forces" section, since it's a pretty nice feature.

:)

Thanks for the replies makotto and R0J0hound.

I appreciate the suggestion makotto, and it turns out that due to the special image point addressing system for joints and forces, it should work without even having to worry about imparting problem torque.

Likewise, thanks for the article link R0J0hound, as it will help with answering another question I was going to bring up relating to the conversion between gravity units and force units, which appear to be different. For my project, the acceleration caused by "gravity = 10" seems to be equivalent to the acceleration of "force = 0.2 * objectMass". That seems to agree with the "0.02" scaling factor you gave in the linked post.

Is there a way to disable or enable gravity for individual objects?

[Solved]

Set global gravity to 0.

Use downward force on individual objects to replicate gravity.

The amount of force should be ( original gravity value * 0.02 ) * the object's mass.

(The "0.02" just converts C2-pixel-units to Box2D-units.)

When applying the force, specify image point "0", to use the center-of-mass.

(When applying forces, specifying image point "0" will apply to the center-of-mass, and image point "-1" will apply to the origin point set in the image editor.)

e.g. If your original global gravity was "10", then to recreate it with force on an object, you apply a force of 0.2 * the object's mass.

---- (original text continued) ----

Currently two iffy approximations come to mind, but they both have weird issues that separate them from being actual gravity.

Downward force - as gravity?

Globally disable gravity,

Then, for objects that should experience gravity, apply a downward force proportional to object mass.

This is kind of close to gravity, except that in the physics behavior I can only find actions that apply a force vector to a single point on the object. If this point is not the center of mass (or does not lie on a line through the center of mass), then the object will experience torque.

I figured there would be a way to retrieve the center of mass coords from the physics behavior, and there is, but I can't find an action in the physics behavior to apply a force on an object that uses XY cords as parameters. The only point parameter is an image point selection.

For simple symmetrical objects where the center of mass is always dead center, you can just put an image point there and use that, but it's not a generally applicable solution. By contrast the built-in global gravity will work correctly regardless of the specific shape of the collision polygons of the affected objects. I would like to use something that general if it exists.

Direct velocity manipulation?

The other option would be to directly add to the object's velocity, which has it's own issues. Framerate independence being the main one that comes to mind. Even with the incorporation of "dt" with an integration step I'd be concerned about mixing both force and velocity level alterations to the object's state, as well as mixing by-hand framerate compensation and integration (as in mathematical integral) with whatever the Box2D asm.js physics engine is doing internally to handle framerate independence and integration. I think this might also bypass friction and linear damping.

Any thoughts or suggestions are welcome. :)

(Minor update)

Image point "0" & "-1" for joints

In the Physics behavior manual page, in the "Physics actions: Joints" section, there is a mention that, for "Create distance joint" and "Create revolute joint" actions, image point "0" specifies the center of gravity instead of the origin image point, and "-1" specifies the origin image point. I don't know if this is also the case for applying forces, as nothing to that effect is mentioned for force actions. I'll test it out and report back.

Happy to help, TheZinc and — :)

> Firstly, I love you! Secondly, I'm going to have to put these into practice to get a complete understanding of the application and limitations..

I've found that sometimes it can be handy to open a second copy of Construct 2, just to try something out in a simple blank-slate environment, before adding it to a complex project. Not sure if it's applicable in this case, but I figured I'd mention it.

> In terms of monitor framerates, isn't it something that can be capped? Can I not set it to 60 fps and any PC or device playing the game will limit fps?

I believe Construct 2 leaves the scheduling of the frames (basically the framerate) up to whatever HTML5 engine is running the game, whether that's Firefox, or Chrome, or NW.js (NodeWebkit).

This means that you can't really rely on a given framerate, because each platform may behave differently. Even if you could cap it, it would only limit the maximum framerate, but wouldn't necessarily change the variability of the framerate.

That said, there's another important side to this, which is that you might not want to limit the maximum framerate in the first place.

If you can make your game truly framerate independent, it will run correctly at any monitor refresh rate, rather than being 60 Hz only, and it will look very smooth and fluid on high refresh rate monitors.

My recommendation would be to always aim for framerate independence if possible, unless the project absolutely requires a fixed framerate.

Construct 2 already allows you to export for multiple platforms, so also setting up a game to run on multiple monitor types just gets you that much closer to having a game that can run on anything. :)

I should have assumed this in advance, but Ashley put together a nice tutorial article on using "dt" for framerate independence:

Delta-time and framerate independence

This is another nice article I found that covers framerate independent acceleration, and shows a few different integration formulas. (Euler, Verlet, and RK4)

Integration Basics

(Remember, "integration" is just a method of eliminating that stair-step error I mentioned in the first post. It does it by calculating what you would see if you could increment in finer steps, infinitely finer steps actually.)

> I imagine these are some of the problems you had to solve on Down Ward

Yes indeed. :)

Down Ward is framerate independent, using "dt" in relevant time dependent expressions, and the Physics behavior in "Framerate independent" mode.

The first game I built framerate independence into from the ground up was my prior game-jam game ArcherOpteryx. After seeing how smooth it looked at a 144 hz refresh rate, and after seeing that my prior game-jam games didn't run correctly on any refresh rate other than 60 Hz, I decided that I would incorporate framerate independence into every future project. After that I retroactively updated Neon Phoenix to be framerate independent. I eventually hope to similarly update my first two game-jam games Owl Camp and Lucid which are currently not framerate independent.

My recommendation would be to always aim for framerate independence if possible, unless the project absolutely requires a fixed framerate.

It's actually not as hard as it might seem at first, because almost everything can be made framerate independent just by multiplying "dt" to rate values in expressions.

The "calculus" type stuff only ever shows up for very few special cases, when you're dealing with stuff that's non-linear over time, like acceleration for physics. Likewise, even if you go the completely from-scratch rout, the only "calculus" based math you'll encounter is actually just some basic multiplication and addition done in the right places. The reason it works is related to calculus, the term used to describe the process ("integration") comes from calculus, but the actual math that makes it work is just basic multiplication and addition.

As for the jetpack problem, my first game-jam game Owl Camp actually does involve a jetpack, and (if I recall) it is thrust limited in the fashion I described in my prior post. :)

> Looking forward to it

Thanks TheZinc. You can actually try out the open alpha of Down Ward right now if you're interested.

Down Ward (alpha)

Happy to hear you're looking forward to it. I'm working on the next update now actually. :)

Hey TheZinc,

If I understand, you're interested in simulating low gravity, and a jetpack with a capped maximum speed.

I'm not sure what stuff you already know, so I'll just go over the things that might help out.

Summary:

Frame rate independent acceleration can be tricky, but is doable with "delta time", some math, and also even more math.

C2's Physics behavior can do it all automatically.

Try ignoring Jetpack thrust when player is over desired speed cap.

Low Gravity

In a low gravity environment, like the moon, physics will behave exactly the same way as on Earth, except that the global downward acceleration on all objects will be a lower value.

On earth the downward acceleration (gravity) is

32 ft/s^2 "feet per second ... per second"

Meaning every "second", a falling object picks up an extra 32 "feet per second" of speed.

On the moon the downward acceleration is about

5 ft/s^2 "feet per second ... per second"

Meaning every "second", a falling object only picks up an extra 5 "feet per second" of speed.

In Construct 2 terms this is like saying every second add 5 (feet per second) to an object's Y velocity.

Acceleration per tick

So, we could make a C2 event that said:

"Every second add 5 to an object's Y velocity."

Unfortunately that accelerates by an amount of 5 in a big burst every 1 second.

What we really want, is to accelerate by an amount of 5, but smoothly spread out over 60 ticks per second:

Every tick (60th of a second) add "5 * (1/60)" to an object's Y velocity.

Now after 1 second of ticks we will have added 60 of those "5 * (1/60)" slices, which is a total increase of "5" for Y velocity, over 1 second. Success!

This almost works, but remember that not everyone's monitor is capped at 60 frames per second. Some will be 120 fps, or 144 fps, or on a slower machine, you might get 30 fps.

So if you cant count on 60th of a second ticks, and multiplying by 1/60; but you also can't count on 120th of a second ticks, and multiplying by 1/120; then what do you do?

It would be handy if C2 could tell you exactly how short a tick was right at the moment the calculation was being done. Fortunately it can, and that value is called "dt" for "delta time", meaning the fraction of a second since the last tick.

When the frame rate is 60 fps, dt will be 1/60th.

When the frame rate is 120 fps, dt will be 1/120th.

It's exactly what we need.

So instead of saying:

Every tick (60th of a second) add "5 * (1/60)" to an object's Y velocity.

We now say:

Every tick (delta sized sliver of a second) add "5 * (dt)" to an object's Y velocity.

In practical terms, using a lower gravity value will mean the player jumps higher than in normal gravity, and the arc of motion will appear to be in slow motion.

Curse of Calculus

So all the above fiddling with "dt" gets us the right velocity regardless of tick rate, but there's still a problem.

It doesn't get us the right position, because position is based on velocity over time.

If your game runs at 1 fps, a dropped stone will have the correct velocity after 1 second, but it won't have gone anywhere yet, because before that first second it's velocity was zero, so it covered no distance at all, for that whole second.

Drop the same stone, using a faster frame rate (like 60 fps), and after 1 second the velocity will be exactly the same as in the prior example, but the stone will have traveled downward on every tick after the first one.

In the real world, if you graphed the increase of velocity over time, you'd get a nice increasing diagonal line.

In the game world you are stuck with ticks, so the velocity is changing in stair steps, and the notches (stairs) are the error. Making the time slices (stairs) smaller makes this error smaller, but this just means the size of the error will vary with the speed of the frame rate.

Now this error might not be a huge issue, but if you want to eliminate it, you can use Euler integration or Verlet integration, which both attempt to account for the missing stair step area, regardless of step size. Verlet is kind of like an interpolated version of Euler.

Another way to eliminate it is just to use a pre-built physics engine that handles all this stuff, like C2's built in Physics Behavior, or a comparable 3rd party Physics solution like Chipmunk Physics (which another C2 dev built a plugin for). Note, I think you have to set C2's physics to be frame rate independent with an event, if you want it to do all that "dt" stuff I described above, but it basically just has an "on switch" for that mode.

Jetpack velocity cap

One way to cap the power of the jetpack is to make it apply thrust only when the player's upward speed is below a threshold.

e.g.

If player is pressing Thrust key,

AND

If the player's upward velocity is below 100 pixels a second,

THEN

Add +1 to upward velocity.

Just remember that in Construct 2 upward velocity is actually negative "Y".

So the above code written in Construct would look like this:

If player is pressing Thrust key,

AND

If the player's Y velocity > -100.

THEN

Add -1 to upward velocity.

Hope that helps out.

Hey cornfl4ke,

edit: I just noticed that I hadn't seen that there was a page 2 for this post with some existing answers. Well here's another then...

If I understand correctly, it sounds like you want to arrange for the following:

1. A player can always pick up an item by tapping it.

2. A single tap that picks up an item won't activate a room.

3. If an item is sitting somewhere on a room , the player should be able to tap anywhere else on that room to activate the room without picking up the item.

Just to clarify #3, given a room with an item sitting on the northern half, a player should be able to tap the southern half of the room to activate the room without "touching" the item.

So, when the user taps,

you first check if the tap was on an item, and if it was, you then run the item pickup actions.

Or ELSE, (if the tap was NOT on an item),

then check if the tap was on a room, and if it was, you then run the room activation actions.

The events would look like this.

• - On touch:
  • - Is touching object (item):
    • (Place the actions for touching an item here.)
  • - ELSE - Is touching object (room):
    • (Place the actions for touching a room here.)

Note that the "ELSE" and the "Is touching object (room)", are two conditions together in the same event.

To create an "ELSE" condition, select an event and press X to create an ELSE below it.

Or, right click an event (a whole event not just a condition) and choose Add > Add Else.

Hope that helps out.