Seeing Through Tree Cover

For questions about using Classic.

Post » Fri Oct 15, 2010 10:35 am

[quote="-Silver-":2tm1ozjn]Wow, thanks for taking the time to put that together! For some reason I'm struggling to get this to work when I edit the tree's layer mask though... I want the tree base to be solid so that the player cannot walk through the trunk, but is still able to walk behind it. So I've made the tree a solid object and erased everything from the layer mask except for the base. The collision detection works, but the player doesn't disappear when he walks behind it and the circle doesn't show up.[/quote:2tm1ozjn]

Well, that's not really surprising since the events in my example use an overlap condition in order to work. And when you edit the collision mark, it doesn't overlap anymore properly.

[quote="-Silver-":2tm1ozjn]
If I remove the 'solid' attribute from the tree then the player disappears behind the parts of the tree with the layer mask, appears correctly in front on the tree, but still shows up on a higher layer when he should be behind it whenever he's not in contact with part of the layer mask. And, of course, he can walk straight through the trunk...

I guess I'm doing something very wrong here? :P Should layer masks for trees not be deleted at all to achieve this affect? And if so, how can I make the trunk a solid object? Using an invisible block at the base could help I imagine, but would lose the exact pixel collision.

Hope that's not too confusing :S
[/quote:2tm1ozjn]

A little confusing right there, hehe. I'd say you should put another sprite in a container with the tree. That object would be invisible and be solid. You shape it accordingly and set it to the tree's position with an event. That should take care of that.

But another problem I would see with this method is Z odering. Like smaller stuff, that would be behind the tree (like a flower for example), but maybe in front of the player at his feet and visible too, when the player is covered by the tree. I guess that may have sounded a little confusing now as well. Anyway, at this point I'm not quite sure how I would achieve this myself, while still using the basic method I showed. Maybe I'll give it another try these days.
B
21
S
6
G
10
Posts: 1,024
Reputation: 7,445

Post » Fri Oct 15, 2010 11:57 am

Here's my take on this.

I used PixelRebirth's CAP as a base, so I took his sprites! :twisted:

http://dl.dropbox.com/u/7324985/treesee2.cap

Basically it tests for distances, then set the opacity of a tree to less-than-100 if the distance between those and the player are below X. Then, using the value of this distance, we can add a soft easing on the distance when the player moves.

The tradeoffs for this example over what you were discussing are:
+) Using the Y as reference for what's behind or in front of the player (Z ordering), you get more control of which tree to apply the effect.
o) The whole tree disappears (or nearly disappears - you just tweak the lower value). I don't know if its positive or not, but personally I like this style.
-) CPU intense: You may have to come up with better events if you use hundreds of trees on a level, the way I did it tests every tree in the level in every tick - not a nice idea.
B
107
S
40
G
10
Posts: 456
Reputation: 13,202

Post » Fri Oct 15, 2010 3:55 pm

[quote="gammabeam":1n0heuix]I used PixelRebirth's CAP as a base, so I took his sprites! :twisted: [/quote:1n0heuix]

How dare you steal my block tree and stickman sprites? That was hard work dude! :wink:

[quote="gammabeam":1n0heuix]Basically it tests for distances, then set the opacity of a tree to less-than-100 if the distance between those and the player are below X. Then, using the value of this distance, we can add a soft easing on the distance when the player moves.

The tradeoffs for this example over what you were discussing are:
+) Using the Y as reference for what's behind or in front of the player (Z ordering), you get more control of which tree to apply the effect.
o) The whole tree disappears (or nearly disappears - you just tweak the lower value). I don't know if its positive or not, but personally I like this style.
-) CPU intense: You may have to come up with better events if you use hundreds of trees on a level, the way I did it tests every tree in the level in every tick - not a nice idea.[/quote:1n0heuix]

Generally I like your approach. Without checking the Z ordering (like you mentioned) it appears a bit odd when even trees that arent in front of the player get faded. So that should definitely be added.

Oh, why did you use an always event there? You can just loose it and it works the same, btw.
B
21
S
6
G
10
Posts: 1,024
Reputation: 7,445

Post » Fri Oct 15, 2010 3:59 pm

Pixel and Gamma, I love you both.

I've got the collision with the trees working, sending the player to the front or back as needed with Pixel's advice, and the tree opacity blending looks gorgeous using Gamma's method.

Can you explain the numbers used in the events a bit for me Gamma? Unfortunately, I'm an artist and literature student, so numbers bamboozle me to no end. I've been experimenting with altering them to increase the range at which the erasing effect begins (since my tree models are pretty huge), but haven't had any luck yet :S I think it would help if I had an idea what the numbers did.

Many thanks for the assistance.
B
15
S
7
G
7
Posts: 250
Reputation: 5,298

Post » Fri Oct 15, 2010 4:01 pm

[quote="PixelRebirth":qg9rshjy]
Generally I like your approach. Without checking the Z ordering (like you mentioned) it appears a bit odd when even trees that arent in front of the player get faded. So that should definitely be added.

Oh, why did you use an always event there? You can just loose it and it works the same, btw.[/quote:qg9rshjy]

I imagine getting rid of the 'always' event would help performance too? I'll see if I can work out how to check for z ordering with this method.
B
15
S
7
G
7
Posts: 250
Reputation: 5,298

Post » Fri Oct 15, 2010 4:16 pm

[quote="-Silver-":u4pd6tyu]I imagine getting rid of the 'always' event would help performance too? [/quote:u4pd6tyu]

It's not really a performance hit, just unnecessary. The loop will run every tick with or without that always event.
B
21
S
6
G
10
Posts: 1,024
Reputation: 7,445

Post » Fri Oct 15, 2010 8:12 pm

Hey guys!

Pixel, you're right about the "always" event. I've been using FORs inside functions for a while so I kinda forgot about it :P

Silver:
Glad you are mixing solutions to come up with what you want! :D

As for the math, let me try to explain to you:

distance() is a nice system expression the devs created to help us find the distance between objects without having to make a math mess on your event sheet.

clamp() is another expression which gives limits to your output number - in this case, between 0 and 100.

So the event is:

If the distance between Player and Tree is below 200 pixels, run this:
- Set the tree's opacity - with a limit between 0 and 100 - to the value of the distance.

I've multiplied it with 0.7 to make the value more intense - if the tree's distance is 150 pixels, the tree will get 100 opacity clamped from 150), so you wouldn't see a thing.

Do you get it? I don't know if I'm being very clear as I am also not a developer :P

CHEERS!
B
107
S
40
G
10
Posts: 456
Reputation: 13,202

Post » Fri Oct 15, 2010 8:33 pm

[quote="gammabeam":tkrgw3oi]
Do you get it? I don't know if I'm being very clear as I am also not a developer :P
[/quote:tkrgw3oi]
Fantastic explanation, thanks!

I've tweaked the multiplication factor to 0.2 for the larger trees, and I've set the lowest opacity value to 20 so that the player will still have an idea of where the tree is without having his view obscured. You and Pixel have been great tutors! :D
B
15
S
7
G
7
Posts: 250
Reputation: 5,298

Previous

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 4 guests