Author Topic: Parallax Interpolation (Read 14105 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.

Arias · « **Reply #25 on:** June 04, 2019, 12:41:43 PM »

Zoomdelta part 1

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 go overboard with this, too many function calls will make your stage lag if you computer is not high end enough, I try to not go beyond 1600-1700 layers.

I'll explain more in depth later.

DEMONKAI · « **Reply #26 on:** June 05, 2019, 07:48:36 PM »

thanks on the tip

MatreroG · « **Reply #27 on:** June 09, 2019, 09:19:52 AM »

I must to practice this. Thanks Alice

O Ilusionista · « **Reply #28 on:** June 10, 2019, 05:53:54 PM »

Me too. I never got parallax right.

Arias · « **Reply #29 on:** June 16, 2019, 04:25:21 PM »

Zoomdelta Part 2

Splitting the floor with window can be used with Xscale, but is preferable for parallax that use width, especially if you are going to use a parallax animation.

[bg 0]
type=parallax
spriteno=1,1
start=0,390
mask=1
delta=0.5,0.5
xscale=1,2.789534884
zoomdelta=0.5
windowdelta=0.5,0.5
window=-1000,390,1000,392

[bg 1]
type=parallax
spriteno=1,1
start=0,390
mask=1
delta=0.5,0.507713512
xscale=1,2.789534884
zoomdelta=0.507713512
windowdelta=0.507713512,0.507713512
window=-1000,391,1000,393

In the example you can see how the windows are 2 pixels of height but overlap in 1 pixel, the reason for this is the Y delta when the characters jump, this won't always work though and there will be times when you will need to mess around with scalestart, all this if you want to add delta in Y of course.

Scalestart + Zoomdelta is especially useful when deciding the setting in a stage, try to not lose the important parts of the BG, in this one for example, the focus the stage is the statue and light covering it, so make sure that it is visible even zoomed in.

When using a Y delta you might want to use elements whose bottom part is flat, though at times is not possible unless you redraw the whole stage in a different perspective to make sense, sometimes the elements will have parts that go into the horizon, more on this later.

sensei_yoda · « **Reply #30 on:** November 17, 2019, 05:39:16 PM »

Scaledelta:

(click to show/hide)

Good material you have here. I thought that the scaledelta parameter worked as a percentage, independently to the width of the sprite.
Although his tutorial considers the width of the sprite essential to determine the code and there arose my doubt. Maybe I misunderstood
This is an example of your SFIV-Training stage

(click to show/hide)

Arias · « **Reply #31 on:** November 17, 2019, 09:37:14 PM »

Didn't calculate the walls in the training, I don't even remember if I did with the floor in that version (released it about a year ago, but actually made it like 3-4 years ago), the important one was the one with zoomdelta, so I only calculated that one, but yeah, the first one is correct, it's either:
a)
(delta range)/(wall sprite width)*(delta of the wall)
or
b)
1/the distance of the sprite (start x)*scalestart (if you are using X scalestart in the sprite)
Second is easier to understand, but depends of the approach really.

sensei_yoda · « **Reply #32 on:** November 18, 2019, 04:52:23 PM »

Quote from: 𝓐𝓵𝓲𝓬𝓮 on November 17, 2019, 09:37:14 PM

Didn't calculate the walls in the training, I don't even remember if I did with the floor in that version (released it about a year ago, but actually made it like 3-4 years ago), the important one was the one with zoomdelta, so I only calculated that one, but yeah, the first one is correct, it's either:
a)
(delta range)/(wall sprite width)*(delta of the wall)
or
b)
1/the distance of the sprite (start x)*scalestart (if you are using X scalestart in the sprite)
Second is easier to understand, but depends of the approach really.

Thanks for answering. I see, I will continue analyzing the situation. Regards.

Arias · « **Reply #33 on:** February 07, 2020, 07:55:44 PM »

Quote

it's either:
a)
(delta range)/(wall sprite width)*(delta of the wall)
or
b)
1/the distance of the sprite (start x)*scalestart (if you are using X scalestart in the sprite)
Second is easier to understand, but depends of the approach really.

Btw, I think it's necessary to point a couple of differences between these 2 methods
first one is better used when parallax isn't that strong, for a lack of better words, for example:
if you notice in my training stage, the grids don't move evenly, I didn't want too much parallax because floor distorts a lot (I'm using Xscale here), so the wall doesn't become flat when it reaches the center of the stage.

[BG Wall_Left]
type = normal
spriteno = 3, 3
start = -354, 350
delta = 0.505, 1
mask = 1
trans = none
scaledelta = 0.00117397 ----->0.676453/(1141*0.505)= 0.00117397

the second method is better when one uses width, for instance
you have to calculate only the delta of the wall so it becomes flat when it reaches the center of the stage, notice how the grids on the floor move evenly & each center line becomes straight upwards once in the middle, width parameter will ALWAYS do this...

[BG Wall_Left]
type   = normal
spriteno= 3, 3
start   = -836, 414
delta   = 0.307, 1
mask= 1
trans   = none
scalestart= 2.4, 2.4
scaledelta   = 0.00287081 ----->=1/836(2.4)

O Ilusionista · « **Reply #34 on:** August 21, 2020, 09:06:43 PM »

Quote from: 𝓐𝓵𝓲𝓬𝓮 on July 28, 2018, 12:33:38 PM

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.

Sadly, that engine will require a month payment to be used

Arias · « **Reply #35 on:** August 23, 2020, 06:35:27 PM »

Do you refer to the template Achilleon is making or the engine itself?
IIRC Unreal was made free to use unless someone monetized a game, in such cases one would have to pay royalties of 5% from the revenue you get from your game.

O Ilusionista · « **Reply #36 on:** August 26, 2020, 05:17:47 PM »

The engine itself
https://twitter.com/brazilmugenteam/status/1290709030051229696?s=19

Arias · « **Reply #37 on:** August 27, 2020, 12:08:47 AM »

Then you're referring to the fighter template, not the Unreal engine.
yeah, I expected that, $5 is fine to me, I'll just wait until it is tested & reviewed before becoming patron (and finish developing my own original characters).

GTFoxN6Y · « **Reply #38 on:** November 13, 2021, 09:27:53 PM »

I started making the Xross Fighters: Ultimate Versus demo for Christmas and I think I could make my first 3D Stage for myself.

I got the frames from the video, but can you teach me how to convert the video frames into a 3D stage for my screen pack demo, please?

Stage demonstration:

https://drive.google.com/file/d/191fECclNHDAlRBlCinXpHVx9YsUC4ox5/view?usp=sharing
Stage name: Neon Tokyo

I wanted the stage to look like this:

PS: If possible, teach me how to make a Zoomdelta code For the Stage.

News:

Author Topic: Parallax Interpolation (Read 14105 times)

IMT Facebook

Help us by Donating!

IMT Discord

Join us at our Discord! Click the image below!

IMT Shoutbox

Recent Posts

IMT Calendar