Author Topic: Parallax Interpolation (Read 14099 times)

Arias · « **on:** June 22, 2018, 02:49:39 AM »

Be sure to read the subsequent posts because this first one reached the word limit.

Posting the breakdown here because I need some future references too, not really hard, but if I pass some time without doing something related to it I tend to forget the procedure & lose time deducing it again.

There are two ways of doing this, Width and Xscale, I'll just cover Width for now. VIB's tutorial covers Xscale (http://mugenguild.com/forum/topics/parallax-tutorial-vib-116138.msg1119796.html#msg1119796), it's essentially the same thing but I feel it falls kind of short on explanation.

Introduction:

(click to show/hide)

Tutorial starts here.

Calculating Zoffset & Deltas: Deciding a starting & ending delta for the parallax floor, one can calculate the Zoffset of the characters and the delta of any element positioned on the floor.
Example used:

--->this was made using width & a floor without perspective (not tiled).

Process:

(click to show/hide)

At the end everything narrows down to simple linear interpolation/extrapolation. This is the whole reasoning of these 2 examples:

Now, I know using a graph may look exaggerated, and overcomplicated for a mugen tutorial, but if you sit down and analyze it a bit, you might find that illustrating this way is actually better for understanding than all that babbling I did in the spoiler.

Of course I don't make a graph each time I want to calculate this, what is in the spoiler it's actually simplified, just explained a lot, but a visual help works better.

Mapping with horizontal rows: Let's say I already calculated my Zoffset and want to add one more parallaxed row on top of my bottom parallax, I'd need to calculate the X delta & & top width of the parallax behind my first parallax.
Example used:

Process:

(click to show/hide)

With the same method for this example, I'm using 4 parallaxed horizontal rows, and calculating them so that each one aligns with the previous one.
|
V

(click to show/hide)

Animated Parallax:

Using Width, once you have calculated your parallax values, you just need to code it like you would code a normal animation, but instead of Spriteno, you use Actionno.

(click to show/hide)

However, this only works with Width & it only was implemented in 1.1, it won't work in 1.0.
By using Xscale you need to make use of BG controls (whether you use 1.0 or 1.1).

Reminder: Xscale is used for floors with a given perspective, Width is used mainly for tiled floors, or floors without perspective.

For Xscale (or anything below 1.1), once you have calculated your parallax values you assign an ID to each frame that makes up the parallax.
Parallax values are the same except for the Spriteno & the ID.

(click to show/hide)

My animation is formed by 8 sprites, each frame lasts 8 ticks, so the whole animation lasts 64 ticks = looptime 64.
Basically you enable & disable each frame in 8 ticks intervals.

The first frame activates at time 0 & disables at time 8.
The second frame starts disabled in time 0, enables at time 8 & becomes disabled at time 16.
The third frame starts disabled at time 0, enables at time 16 & becomes disabled at time 24.
this goes on until loop is completed.

(click to show/hide)

Here's another way to code it.

(click to show/hide)

Scaledelta:
Refers to the amount to change the scale of the element for each unit of camera movement, you calculate it dividing the delta range by the sprite width multiplied by the sprite delta.

(click to show/hide)

Depth Movement:
This is kind of an extra, as I don't see many attempting it.

Method is the same as the animated parallax, you enable and disable layers at time intervals by using BG controllers, except that this time you need to calculate each scale, delta & position value for each frame.

(click to show/hide)

I.E.T. Arcade · « **Reply #1 on:** June 22, 2018, 10:04:10 AM »

These explanations will definitely be useful for me. Thank you for sharing!

Arias · « **Reply #2 on:** June 23, 2018, 08:33:53 PM »

No problem.

Zoomdelta: By giving it to the different elements (according to their own delta), it helps to increase the sense of depth the moment you zoomout/zoomin, generally you can't apply it to a parallax floor because it would make your characters slide, but there are a couple of ways around this.

;No Zoomdelta

;Zoomdelta

See the difference?

There are 2 ways to do this, which one to use will depend mostly of the size of your sprites and the number of them, and if you use xscale or width.

1.- Splitting your sprite using 'window'
This is you floor:

By using window you can split your sprite in tiles of 1-2 pixels of height, this depends a lot of the details of your floor, could be higher, the less you use, the better.

Code Example:

(click to show/hide)

Just try to not abuse of this, too many function calls will make your stage lag if you computer is not high end enough, I try to stay between 1600-1700 layers.

There's more to this, I'll get back to it later.

I-Skorp-I · « **Reply #3 on:** June 24, 2018, 12:50:51 AM »

Man as awesome as all of this is, I must say my brain went blank after reading all of it.

O Ilusionista · « **Reply #4 on:** June 24, 2018, 07:50:23 AM »

Question: why /820 and not /830?

Arias · « **Reply #5 on:** June 25, 2018, 03:30:45 PM »

Quote from: .:O Ilusionista:. on June 24, 2018, 07:50:23 AM

Question: why /820 and not /830?

830 is the X position in the sff (830,0).

820 is from the yscalestart in the code, you decide the first 2 yscalestart to resize the sprite Y-wise, based on them you calculate the rest. In this case 820 from the first & 1133 from the second.

[BG B1 ROW CENTER]
type = parallax
spriteno = 555, 1
start = 0, 595
delta = .7577,1
width = 651.66,860
yscalestart = 1133

[BG FEET ROW CENTER]
type = parallax
spriteno = 555, 0
start = 0, 631
delta = 1,1.1
width = 860, 1148
yscalestart = 820

O Ilusionista · « **Reply #6 on:** June 27, 2018, 07:43:02 PM »

Ah, I see.
This technique could be used to recreate the amazing Toy Story first stage

NX-MEN · « **Reply #7 on:** June 28, 2018, 01:24:36 PM »

I like your stuff!!

Arias · « **Reply #8 on:** June 30, 2018, 12:16:19 PM »

Quote

This technique could be used to recreate the amazing Toy Story first stage

Yeah, Once one gets the whole reasoning behind this one can make nice stuff with it, even automatized several things for my stages to reduce work.

I'm helping someone explaining parallax for the Mugen Class Section of Mugenguild & did this, I'll leave it here for anyone who's familiar with linear interpolation/extrapolation. This is the whole reasoning of the first 2 examples, who knows, it may be easier to understand like this.

I guess I'll continue with the animated parallax thing.

verz36 · « **Reply #9 on:** July 01, 2018, 09:15:21 AM »

wow this is amazing, good work and thanks for sharing this info...

malevka2 · « **Reply #10 on:** July 01, 2018, 09:23:27 AM »

Quote from: 𝓐𝓵𝓲𝓬𝓮 on June 30, 2018, 12:16:19 PM

Yeah, Once one gets the whole reasoning behind this one can make nice stuff with it, even automatized several things for my stages to reduce work.

I'm helping someone explaining parallax for the Mugen Class Section of Mugenguild & did this, I'll leave it here for anyone who's familiar with linear interpolation/extrapolation. This is the whole reasoning of the first 2 examples, who knows, it may be easier to understand like this.

I guess I'll continue with the animated parallax thing.

I'm looking at this incomprehensible

Arias · « **Reply #11 on:** July 05, 2018, 02:03:38 AM »

Animated Parallax:

Using Width, once you have calculated your parallax values, you just need to code it like you would code a normal animation, but instead of Spriteno, you use Actionno.

[bg 0];floor
type=parallax
actionno = 3
start=0,400
delta=.5,1
mask=1
;tile = 1,0
;tilespacing = 0,0
width=792,4780
scalestart = 1,1

[Begin Action 3]
5,0,0,0,8,,A
5,1,0,0,8,,A
5,2,0,0,8,,A
5,3,0,0,8,,A
5,4,0,0,8,,A
5,5,0,0,8,,A
5,6,0,0,8,,A
5,7,0,0,8,,A
5,8,0,0,8,,A
5,9,0,0,8,,A

However, this only works with Width & it only was implemented in 1.1, it won't work in 1.0.
By using Xscale you need to make use of BG controls (whether you use 1.0 or 1.1).

Reminder: Xscale is used for floors with a given perspective, Width is used mainly for tiled floors, or floors without perspective.

For Xscale (or anything below 1.1), once you have calculated your parallax values you assign an ID to each frame that makes up the parallax.
Parallax values are the same except for the Spriteno & the ID.

(click to show/hide)

My animation is formed by 8 sprites, each frame lasts 8 ticks, so the whole animation lasts 64 ticks = looptime 64.
Basically you enable & disable each frame in 8 ticks intervals.

The first frame activates at time 0 & disables at time 8.
The second frame starts disabled in time 0, enables at time 8 & becomes disabled at time 16.
The third frame starts disabled at time 0, enables at time 16 & becomes disabled at time 24.
this goes on until loop is completed.

(click to show/hide)

Here's another way to code it.

(click to show/hide)

O Ilusionista · « **Reply #12 on:** July 05, 2018, 11:00:04 AM »

Thanks for those in-depth explanations.

Arias · « **Reply #13 on:** July 09, 2018, 01:13:21 PM »

Scaledelta:
Refers to the amount to change the scale of the element for each unit of camera movement, you calculate it dividing the delta range by the sprite width multiplied by the sprite delta.

0.5 -3.0176 = 2.5176

224--->2.5176
100---> X? = 1.1239

(100*2.5176)/224=1.1239
1.1239/(926*0.5)= 0.002427

[BG 0];wall right
type=normal
spriteno = 12,1
start=130,400
mask = 1
delta= .5,1
scaledelta = -0.002427,0 ;------------Negative when scrolling to the right.

[BG 0];wall left
type=normal
spriteno = 12,1
start=-130,400
mask = 1
delta= .5,1
scaledelta = 0.002427,0 ;------------Positive when scrolling to the left.

Result:

Note that this method only works in 1.1, the effect is possible for 1.0 but you need to use a workaround, I may cover it in the future. With the addition of scaledelta in 1.1 that method would be obsolete, but I like to use it for stages that have a high-to-the-ground perspective to add vertical parallax (since vertical wall parallax hasn't been implemented in any mugen).
|
v

There's more to this that may be worth covering, if you use scaledelta in elements that are close to each other you will find a problem, you can't have 2 layers at the same level/have same priority, so one will always overlap the other depending of your scrolling and will look bad, it can be fixed, probably will post how to do it later on.

O Ilusionista · « **Reply #14 on:** July 09, 2018, 02:30:22 PM »

Hey, really thanks for the deep explained information.

Arias · « **Reply #15 on:** July 12, 2018, 12:28:24 PM »

Like I mentioned before, there's an issue when using scaledelta, if you favour perspective and depth like me you probably will find this problem a lot.

If you're familiar with stages you may know that the priority of the layers depend of their position in the .def file, the lower the position in the .def file the higher the priority is, so inevitably, one wall has to have more priority than another, when you scroll to one side it may look correctly, but once you scroll to the other side it will overlap.

Let's say you want to create a city, street or whatever, and want it to have depth.

Now imagine this quick croquis I drew as a coded stage, if you scroll to the left there won't be any problem because 1 & 3 will have more priority than 4, & 1 is large enough to cover it, but once you scroll to the right, 3 will overlap 4.... 2 may cover it a bit because it has higher priority than 3, but as it is smaller, as you keep going to the right, 3 eventually will stick out and it will look bad, more so if your stage has large bounds.

You can solve this problem by bounding the sprite 3 (usually the one with more priority using scaledelta) with the window parameter so that it doesn't go beyond 2.

Bounding is represented by the blue area, top left corner (78,-37), bottom right corner (563,410).
Green area represents the resolution, 640x480 in this case, (0,0) are the coordinates of the top left corner, (640,480) are the coordinates of the bottom right corner.

If we take the croquis as example then the parameters of window would be:

[BG 0]
type=normal
spriteno =
start=
mask =
delta= .2,1
scaledelta = .001532,0
window = 78,-37, 563, 410
windowdelta = 0.8,1

The windowdelta must be the higher delta of the sprite that uses scaledelta, like this, 3 won't go beyond 2 when it scales to the right.

mulambo · « **Reply #16 on:** July 12, 2018, 03:44:08 PM »

Quote from: I-Skorp-I on June 24, 2018, 12:50:51 AM

Man as awesome as all of this is, I must say my brain went blank after reading all of it.

Same here.

I just wonder if MUGEN 2.0 will have full 3d support

This tutorial really needs to be simplified for the masses and common use. This way it's waaaay too complex, altough it could be a revolutionary "workaround" for the limits of MUGEN. Probably providing some templates + a quick tutorial would be the best option, at this point all I see is something incredible and incomprehensible (or just incredibly incomprehensible).

O Ilusionista · « **Reply #17 on:** July 12, 2018, 10:07:00 PM »

Quote

You can solve this problem by bounding the sprite 3 (usually the one with more priority using scaledelta) with the window parameter so that it doesn't go beyond 2.

oh, Nice trick

DEMONKAI · « **Reply #18 on:** July 12, 2018, 10:40:32 PM »

thanks on the generous tutorial

Arias · « **Reply #19 on:** July 14, 2018, 04:12:15 PM »

Quote

Probably providing some templates + a quick tutorial would be the best option

Looks complex, but just at first, templates would only work if "geometry" was the same for every stage, at that point probably would be better to just do it by trial & error, it works for simple stuff... trial & error can get frustrating if people want to try more elaborated things though.

Was planning to post a simple BG with a 3D cube that includes annotations, but once I'm done with this.

Arias · « **Reply #20 on:** July 25, 2018, 06:46:20 PM »

Depth Movement:
This is kind of an extra, as I don't see many attempting it.

Method is the same as the animated parallax, you enable and disable layers at time intervals by using BG controllers, except that this time you need to calculate each scale, delta & position value for each frame.

Here you can see the Rook goes back and forth matching the position of the floor.

For this example:
Initial position is 37,531 and final position is 125,656
Initial delta is 0.329875, and final delta is 1.167441
Initial scalestart is 0.1 and final scalestart is 0.3

Now, the addition value to each position will depend of the N° of frames you want to add.
In this case I decided for 125 frames & 1 tick for each frame, since my Rook goes back and forth my looptime is 250.

(37,531 - 125,656)/125 = 0.704, 1
(0.329875 - 1.167441)/125 = 0.006700536
(0.1-0.3)/125 = 0.0016

This means that for each frame you need to add
0.704,1 to the position
0.006700536 to the delta
0.0016 to the scale

It's easy to calculate, the seemingly annoying part is how to code it, since the sequence is made of several dozens of lines with different values + their respective bgctrls (for each one) it may look tedious. I just do it through a macro, that way doesn't take more than a couple of minutes, might cover that method ....though that's not really part of mugen anymore.

mulambo · « **Reply #21 on:** July 25, 2018, 09:05:01 PM »

Quote from: 𝓐𝓵𝓲𝓬𝓮 on July 14, 2018, 04:12:15 PM

Was planning to post a simple BG with a 3D cube that includes annotations, but once I'm done with this.

Sounds cool, hopefully something the "average" lazy creator (like me,

) can be creative with (not everyone is a genius in math and geometry ^^' ).

O Ilusionista · « **Reply #22 on:** July 26, 2018, 10:01:48 AM »

Quote

Here you can see the Rook goes back and forth matching the position of the floor.

I REALLY liked this effect

This is kind of thing Elecbyte, if they will ever return someday, should change in stages - to be able to use the same code from characters, like we do have in OpenBOR.
That rook, for example, would be a helper, an independent entity.

This is something the community asked for them since the day one of Mugen, as far as I remember. But they choose to do other things which weren't that much required, like Zoom.

Arias · « **Reply #23 on:** July 28, 2018, 12:33:38 PM »

I guess stage hazards aren't a common thing in 2D fighters, other than a few breakable items which can be coded into characters.

At this point if Unreal Fighter developer keeps constant probably it's going to be finished before elecbyte ever returns, and is looking more promising than mugen.

O Ilusionista · « **Reply #24 on:** July 28, 2018, 01:56:38 PM »

That is very nice. I saw IKEMEN with some new stuff for stages too.
Too bad Elecbyte never had returned neither had opened the source code of the engine. We could have a way better engine now.

A good exemple was BOR/OPENBOR engine. After they made the code open, the engine had improved A LOT.
Recently, I've joined officially the Dev Team of the engine and I can say to you, from a developer view, that OpenBOR is supperior to Mugen in many aspects.

For example, all those things on the video are already possible in OpenBOR.

News:

Author Topic: Parallax Interpolation (Read 14099 times)

IMT Facebook

Help us by Donating!

IMT Discord

Join us at our Discord! Click the image below!

IMT Shoutbox

Recent Posts

IMT Calendar