[Effect] mode7

Zebbi

It's just how you look at it. To me those variables define the top view position and the actual position is irrelevant since the behavior will set that.

Zebbi

It's just how you look at it. To me those variables define the top view position and the actual position is irrelevant since the behavior will set that.

So, it's not possible to design a map using the position of the objects in the layout, all of the objects have to be manually set using the co-ordinates in the variables?

It is possible, I didn't say it wasn't.

Put two objects in a container, Sprite and SpriteMode7. Position the Sprite objects in the layout editor to define the object positions. Then in the event sheet use the behavior or whatnot to set the SpriteMode7 object's position from the Sprite's position. You then move around the Sprite objects and the SpriteMode7 object will update accordingly.

It is possible, I didn't say it wasn't.

Put two objects in a container, Sprite and SpriteMode7. Position the Sprite objects in the layout editor to define the object positions. Then in the event sheet use the behavior or whatnot to set the SpriteMode7 object's position from the Sprite's position. You then move around the Sprite objects and the SpriteMode7 object will update accordingly.

So, would all objects (in this case it would be walls and doors) need to have two objects (Sprite and SpriteMode7) made in the layout or could the spritemode7 objects be automatically created at runtime? The example just seems to have the sprites and instance variables for x and y. Couldn't it be possible to have the positions on the layout define the x/y variables either at the start for fixed sprites and every tick for moving sprites (like enemies, etc)?

Zebbi

If the objects are in a container, the other would be created automatically. And yes you could just use variables instead of a second object if you wanted.

Basically you can set it up any way you want. The ideas I have should work, or the ideas you're presenting would also work. In the end you only need one object type that is positioned on the mode7 plane. Anything else is purely for convenience or just to make other things easier to do.

Having two objects in a container for instance makes collision detection actually possible. Consider if you had only objects on the mode7 plane, how would you do collision detection? You could try using the overlapping conditions, but really you'd get bad results. By having another object in a top view perspective, you can do collision detection with them in an easy way, plus all the movement behaviors can be used there.

Zebbi

If the objects are in a container, the other would be created automatically. And yes you could just use variables instead of a second object if you wanted.

Basically you can set it up any way you want. The ideas I have should work, or the ideas you're presenting would also work. In the end you only need one object type that is positioned on the mode7 plane. Anything else is purely for convenience or just to make other things easier to do.

Having two objects in a container for instance makes collision detection actually possible. Consider if you had only objects on the mode7 plane, how would you do collision detection? You could try using the overlapping conditions, but really you'd get bad results. By having another object in a top view perspective, you can do collision detection with them in an easy way, plus all the movement behaviors can be used there.

Would it be too cheeky to ask for you to mock-up a quick capx to show how this could work, I could embellish it to see how far I can take it but I'm having a bit of trouble getting my head around collisions with container objects.

Zebbi

I suppose that would be helpful. I have an example earlier in this topic that did that somewhat. I don't have an exact example using this effect though. Currently I don't use effects at all, and I haven't used rex's behavior. In a nutshell it's because webgl is slower on my machine if used and I need to modify C2's runtime to actually be able to use it, so I don't.

I have had a go at non effect version, a week or so ago, which may or may not be useful. It uses the paster object instead, but it does follow the pattern where the game map is defined on the "map" layer. That is where everything is moved around and everything from there is mapped to a 3d perspective.

The events have three parts to it. The "position objects" section, which would be similar to what rex's behavior does, except it also calculates the relative angle of other objects so the correct frame is used. The "ground render" section is what the mode7 effect does (however there's a math error in there I haven't tracked down yet). Finally the "control" section controls the movement in a custom way that I liked.

https://dl.dropboxusercontent.com/u/542 ... ce3d2.capx

Rabbit trail aside, that was after a week of tinkering and I'm at the point where I need to rework the math to correct the ground texturing alignment. Even with the effect and the behavior there would be work to match things up imo. Even though this is thought of as pseudo 3d, in reality it requires full on 3d math with perspective transformations.

A very useful reference is here:

http://www.coranac.com/tonc/text/mode7.htm

Zebbi

I suppose that would be helpful. I have an example earlier in this topic that did that somewhat. I don't have an exact example using this effect though. Currently I don't use effects at all, and I haven't used rex's behavior. In a nutshell it's because webgl is slower on my machine if used and I need to modify C2's runtime to actually be able to use it, so I don't.

I have had a go at non effect version, a week or so ago, which may or may not be useful. It uses the paster object instead, but it does follow the pattern where the game map is defined on the "map" layer. That is where everything is moved around and everything from there is mapped to a 3d perspective.

The events have three parts to it. The "position objects" section, which would be similar to what rex's behavior does, except it also calculates the relative angle of other objects so the correct frame is used. The "ground render" section is what the mode7 effect does (however there's a math error in there I haven't tracked down yet). Finally the "control" section controls the movement in a custom way that I liked.

https://dl.dropboxusercontent.com/u/542 ... ce3d2.capx

Rabbit trail aside, that was after a week of tinkering and I'm at the point where I need to rework the math to correct the ground texturing alignment. Even with the effect and the behavior there would be work to match things up imo. Even though this is thought of as pseudo 3d, in reality it requires full on 3d math with perspective transformations.

A very useful reference is here:

http://www.coranac.com/tonc/text/mode7.htm

Thanks for the example, I noticed there's some events in yours that aren't as obfuscated as they are in rex's, is it possible for me to mix and match to be able to make for the cleanest possible example of these plugins?

Zebbi

I don't think so, the projection math is slightly different.

So for the past couple days I've been working with a friend to try and implement the "sprite positioning logic" from the capx earlier in this thread so that it still works when the mode7 transformation is being applied to a layer instead of a sprite; doing this opens up a lot of possibilities for visual effects without the performance overhead of hundreds of sprites with individual mode7 effects, but figuring out how the projection math/logic changes as a result of this has been difficult. Our layout is always the size of our window (i.e. no scrolling) and the angle is always zero, so this helped us to simplify stuff, but even now that we've refactored the sprite positioning logic down to a couple of lines it's still hard to figure out what we need to change make sprites map properly. I haven't been able to figure out things like where the axis of rotation is when we're using a layer instead of a sprite. I've made the most logical substitutions I can think of for the code you provided, like replacing Sprite.Width with LayoutWidth, but I don't have 100% confidence that all these conversions are valid. Any insight you can offer on how the original sprite positioning math works and how it would change in this context would be much appreciated. I can provide a capx of our work so far, but we've moved so far away from the original code while trying to fix it that it might not be much help.

seven

The original code in that capx is from taking the code in the effect itself and reversing it. The only snag was in the effect the positions are relative to either the screen or object, in the range of 0 to 1. So 0,0 would be the top left and 1,1 would be the bottom right. So as I recall multiplying by the sprite size was to switch between that and pixels.

Beyond that I don't have anything helpful to say. If I was to do it I'd probably need to derive the math again so I understand what's what. But I've no time to do that.

With this awesome mode7 effect by R0J0hound I was able to re-size the notes and the fret board/track and another effect called Opacity Gradient I created a transparent horizon (end of the board) and also notes fade in/out as well, so with all this you can add a background and it looks like the real game..

controls:

~ = restart game

ESC = pause/rewind

1 = green

2 = red

3 = yellow

4 = blue

5 = orange

ARROW KEYS UP/DOWN = strum (hit notes)

Play the unfinished prototype here: https://googledrive.com/host/0B5UPPw4SdTlHMUlORE5qQ1YyTWs

Has anyone implemented mode 7 successfully? I've tried the effect in combination with rex's plugins but the image distorts a lot and i don't seem to get the parameters right. Help!

Awesome! thanks!

I'm trying to figure out how to spawn objects in front of the camera. They all seem to appear in the exact same place if i use the co-ordinates of the camera. Any ideas?