I thought about it too, and had another basic approach. In a quick&dirty test I simply copied the game layout and used two layout objects on a third layout. But I did not really test, if full functionality is given. Communication (or "syncing") between the two layouts have to be done through globals, of course, and that could be a hell of work. Another downside could be the higher demands of RAM/VRAM...

There are a lot of things in your cap, that may interfere. There are two Mouse/Keyboard objects, the mixing of autoplay/channel play, triggering sprite clicks without testing against visibility, etc. To get rid of them and so to see, if the basic functionality is working, I've set up a cap that only mimics your design (main menu, level layout, extra sheet controlling the mute menu) and placed the mute menu to a seperate layer using inheritance.

This one works perfectly on my pc, so try this one by just replacing the path string to your path and see if it works. Then you could try to implement it.

MuteChannel.cap

You're using seperate XAudio2-objects per Layout. I guess just using the one from the first layout and setting it global will solve the problem.

Thanks for the link, I left this out somehow when looking through the wiki. Exactly the informations I was looking for.

I still hope, someone may help on the other problem (an algorithm for pseudo random numbers maybe?). I'm not that deep into programming, that's why I ask

It may sound silly, but could someone give a definition of the following variables?

-ForegroundTexture

-BackgroundTexture

-SourceTexture

-PreviousTexture

It seems straight forward and self-explanatory, but sometimes I get unwanted results or can use whatever I want and get the same result (and not the one I intended). Please, don't laugh at me

The HLSL intrinsic functions list one called noise. If you look at the reference on msdn, it says that the function ist fully supported with shader model 2 and above. But when I try to use it I get an "cannot map expression..." error, if using a variable as input (noise takes a vector of any size as input). With values as input no error is raised, but the output value is always the same no matter what input values I use.

no error, but always the same output value:

a) noise(0.6f)

b) noise(float2(0.25, 0.5))

c) float nseed = 1000.6f

noise(nseed)

error message:

a) float nseed = Tex.x

noise(nseed)

b) float2 nseed = Tex.xy

noise(nseed)

c) float2 nseed = float2(Tex.x, Tex.y)

noise(nseed)

d) noise(tex.xy)

e) noise(float2(Tex.x, Tex.y))

The only thing I could find on the web was a thread on the msdn-forum, posted 2 years ago, where someone said:

"noise() is only supported for tx_x_0 profiles, i.e. software shader implemented by D3DX TextureFill functions."

I have no clue what this means, but the tx_x_0 profile restriction is only shown for shader model 1

Any ideas?

And if it comes to the point, that the perlin noise function is not usable, how can I setup my own random noise function?

germany 1? let's raise the number

tULAMIDE - Germany

Tried exactly that (smaller resolution fullscreen with one event to close application on escape key) with 99.42 and had no problems. I think, posting a cap wouldn't help. Complete hardware/driver description could possibly help more if posting it again to the bug tracker.

EDIT: also tried the posted cap without problems.

Thanks Ashley and all the others. That's another great plus: With this community, even learning is fun with Construct

You could use the "Angle is clockwise of..." condition in the system object. Contrary to the name, you can actually check if an angle is counterclockwise of another one as well.

Ah, thank you, now I see! So, this is to be used always? Even for a simple test of a certain value? I'm asking this, because I use angles very often to trigger actions, so I better change all "Angle Greater than n"-conditions to the "Angle is Clockwise of n"-ones...

Don't use greater than/less than tests on angles - it never works properly. They always have problems with the crossover between 0/360 degrees. That's what the angle-specific expressions, like anglediff, are for.

Ashley, I'm afraid I need an explanation here. I think I'm not understanding this right. How can I validate a range of possible angles if greater/lesser than shouldn't be used? Or do you mean that only my direct approach with abs(angle - 180) is the wrong way?

abs(Sprite.Angle - 180) greater or equal 175 ->not advised, as it does not use angle expressions?

anglediff(sprite.angle,0) Less or equal to 5 ->not advised, as it does use a "lesser than" test?

If so, what is the correct way to see if an angle is in between a range of possible angles?

The example won't work, because both conditions need to evaluate to true for the action to be triggered. And the angle can't be at the same time greater than 355 and lower than 5 (e.g. 3 is lower than 5 but also lower than 355)

Instead do a system compare:

abs(Sprite.Angle - 180) greater or equal 175

Rich, you're still working on it?

Would like to know, too <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

Last thing about it was:

I'll do it this summer. <img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" />

http://www.scirra.com/phpBB3/viewtopic.php?f=2&t=4023&p=32085

*knock on wood* *cross fingers* *say a prayer*

<img src="{SMILIES_PATH}/icon_mrgreen.gif" alt=":mrgreen:" title="Mr. Green" />