Stage camera changes

[potsmugen]

Now that Eiton is more or less done making the camera more accurate to Mugen, it may be a good time to discuss what about the old Ikemen camera may be worth preserving. Or where to go next with the camera in general.

Zoom out when exiting top boundary

Previously, if using tensionhigh and tensionlow and both characters reached the top of the stage, the camera would zoom out to show the last missing piece of the stage and thus follow the chars as long as possible. I think this aspect of Ikemen's zoom was better than Mugen's, so it could return as some parameter.

3D stages camera placement

Currently the way 3D stages seem to work is that they are based in 16:9 aspect ratio and when using them in 4:3 the camera placement is controlled by overdrawhigh and overdrawlow.
I've never made a 3D stage but I've made like a hundred of 2D ones, and the way 2D stages work is very different. They are based in 4:3 aspect ratio and the way they should look in 16:9 is controlled by cuthigh and cutlow.
I think this should be made consistent. It will get very messy down the line if/when the overdrawhigh and overdrawlow parameters are ever actually implemented to do what they do in Mugen (issues #1300 and #1481).

I had a couple more but they've either been fixed already or I gained a new perspective on them so I think I'll skip them.

[Eiton]

3D stage camera is no different from 2D stage. The aspect ratio is defined by localcoord. People simply copied the def of the demo stage I uploaded which is in 16:9 localcoord and they didn't bother to change it.

[potsmugen]

That explains a lot and is great to know. I think you made some changes since the last time I looked at it closer, too. So that's one less problem.
Also I hadn't even noticed that overdraw does also affect camera in Mugen 1.1. Amazing how accurate you made the camera.

[Eiton]

Any idea how should the first feature be named?

[potsmugen]

I tried a few ideas and BoundExitZoomOut was probably the best I came up with. Also thanks. I'd almost make it default to on since I think that's downright better, but that would kind of go against having accuracy first.

[Eiton]

I used the name lowestcap. It is related to how it works in the code.

[Kasasagi77]

I will just lobby for the thing that was explictly merketed as a feature on the wiki: Skipped zoom-out processing of boundhigh, but was just removed in favor of Mugen compatiblity. See #1642.

Citing @potsmugen:

This parameter in particular sounds like it could use something like "boundhighzoomdelta".

[Eiton]

Try the new camera parameter dynamicboundhigh

[Kasasagi77]

OK - thank you very much. My feedback on dynamicboundhigh below.

I have only practically tested it for stages that have a zoom delta of 1.0, but have different vertical deltas <=1.0 (because that is what I personally use in my stage edits), so my conlusions about zoom deltas are so far more theretical than tested.

---

1. This new flag works perfectly when the background that determines the appropriate boundhigh has a vertical (y) delta of exactly 1.0 and zoom delta of exactly 1.0.

2. When the horizontal (y) delta of the background that determines the appropriate boundhigh is less that 1.0 then setting this flag only mitigates the problem to some extent, ending up somewhere between what Mugen 1.1 does and an ideal high bound that would show the whole background with a maximum zoomin.

   • Ikemen 0.99 also did not work much better for this case. I have not tested even earlier versions of Ikemen at this point, because the configuration is incompatible.

   • I attach two stages for this test case: delta-065.zip, delta-010.zip - this last stage where the vertical (y) delta has quite an extreme value of only 0.1 shows this problem the best.

3. Unfortunatelly, the backgrounds that determine the boundhigh for a stage will usually have the vertical (y) delta or zoom delta values less then 1.0 (both of these deltas at once can also be less than 1.0).

   • Also unfortunatelly, it may not be obvious which of the stage's backgrounds actually determines the boundhigh. It will usually be a background with the lowest vertical (y) or zoom deltas, but it may not always be the case.

4. Taking the above into account, I think that it would be ideal if this parameter was a float, e.g. dynamicboundhighdelta.

   • As for the value interpretation of this float, it could e.g. be equal to the vertical (y) delta of a background that determines the boundhigh, although this is only one of the possible interpretations of this parameter.

     • In this case, if the background that determines the boundhigh uses zoom delta or a combination of vertical (y) and zoom delta, then I assume that this parameter would be set manually to an appropriate value.

   • As a totally different alternative, this parameter could have 2 values instead of one, and these values would be interpreted as vertical (y) and zoom delta of the background that determines the boundhigh and the rest would be automatically calculated.

[Eiton]

Is this what you would like to have?
Eiton@e09f883

[potsmugen]

dynamicboundhigh and dynamicboundhighdelta could probably be a single parameter.

[Kasasagi77]

@Eiton - my feedback below.

I tested boundhigh-determining backgounds with: vertical (y) delta, zoomdelta and a combination of the two.

---

Conclusions:

1. For backgrounds using only vertical (y) delta this works pretty much in a pixel-perfect manner. You only need to set dynamicboundhighdelta to the exact value of the vertical (y) delta of the background, e.g. if the backgdound has:

    delta = 0.5, 0.7
   

   Then you need to set:

    dynamicboundhigh = 1
    dynamicboundhighdelta = 0.7
   

   This is exacly what I proposed above and it is absolutely sufficient for me personally. Thanks a lot!
   
   

2. For backgrounds using only zoom delta this works sufficienty well in my opinion. It is not pixel-perfect - it still loses several pixels (maybe about 5 local pixels, depending on the parameters), but it is still much better than what Mugen does.

   Some pixels are lost in the above case, because the position of the camera is for some reason slightly non-monotonic in relation to the background edge, when the background uses zoomdelta, i.e. at exactly zoomin and at exactly zoomout the position of the camera can exacly match the background edge, but for a middle zoom value, between zoomout and zoomin the camera exceeds the background edge slightly. This means that you either need to sacrifice several pixels or show a missing background.

   the values of dynamicboundhighdelta that need to be set when using only zoomdelta are more than 1.0, however I do not see what determines the appropriate value in this case. For example, for the cases I tested:

   • zoomdelta = 0.7 => dynamicboundhighdelta = 1.95,
   • zoomdelta = 0.4 => dynamicboundhighdelta = 4.7.
     
     

3. For backgrounds using both zoom delta and vertical (y) delta this too works sufficienty well and very similarily to the above case when using only zoom delta, with several lost pixels. Example values for the case I tested:

   • zoomdelta = 0.7, delta=?,0.7 => dynamicboundhighdelta = 1.375.

[potsmugen]

I used the name lowestcap. It is related to how it works in the code.

I thought it would be dynamicboundhigh when I saw the name, heh. Either way when you activate all these new parameters the camera is definitely better than Mugen. Thanks.

If you're up for it, one thing that still seems to be missing is zoom speed. Even with zoomindelay and such the zoom can feel quite sudden. Maybe even split it between zoominspeed and zoomoutspeed (or whatever makes more sense than "speed").

[potsmugen]

Oh yeah. That makes sense, at least for zoomout. Maybe zoomin could have a vel setting of its own but it's not a big deal.

Speaking of tensionvel, it looks like setting it to an unreasonable value like 100 can easily send the camera to a position where it won't recover from. Not an issue in itself, but maybe a related issue could appear.

EDIT: Game example of zoom speed difference.

bandicam.2024-05-06.18-20-35-747.mp4

[Kasasagi77]

I have made a working prototype for this: #1818, adding zoominspeed and zoomoutspeed camera parameters - however I am currently not sure if this is worth merging, because:

1. the zoominspeed works similarily to the tensionvel parameter (although not exactly the same),
2. the zoomoutspeed is not free of side-effects if set to low - it makes the characters interact with the camera view boundary in some undesirable ways if they move faster than the camera can zoom out, while dashing e.g. (the characters can be blocked and even dragged/pushed by the camera view edge if the zoom-out is too slow).

@potsmugen - if you are interested, you can check it out.

[Kasasagi77]

Hmm... after some more testing on my end, I recommend testing it with autocenter = 1, as it makes the camera less wobbly on zoom-out when both characters are escaping from each other. And this affects the percieved "suddenness" of zoom-out.

With autocenter = 1 and zoomoutspeed = 0.6 or zoomoutspeed = 0.75 the zoom out is visibly less sudden, but with some minimal side-effects.

[Kasasagi77]

I have added a new commit to the PR and fixed the characters being pushed/dragged by the screen boundary. I think that this zoom speed limiting actually works as it should now, without significant side-effects.

However the ytension mode (as opposed to verticalfollow mode) would still benefit from a yscrollingspeed parameter, because right now the vertical scrolling in this mode is always at full speed, equivalent to verticalfollow = 1. I am currently thinking about adding this too.

[Kasasagi77]

OK - I have added some fixes baser on @Eiton's feedback and I think this is worth merging now.

To recap what this does:

• I have added three parameters: zoominspeed, zoomoutspeed and yscrollspeed, all with values in the range of [0,1] with the value of 1 leaving the behaviour of camera algorithm unchanged,

• I tried to keep the things as simple as possible currently, so these parameters just linearily/proportianally scale either the zoom per frame speed or y per frame speed,

  • I was also thinking about enforcing a speed limit, as opposed of the current speed scaling, but have decided to keep the current simple version for the time, let me know if you have any opinion on this,

• These parameters are applied as a post-processing step to anything produced by the current camera algorithm, so they could theoretically be applied to any potential future Ikemen-exclusive (non-Mugen) camera algorithm; this also means that these parameters currently also only allow to slow down the zoom and y scrolling, as opposed to speeding it up, as a speed-up would not be artifact-free - I think that speeding up zoom or scrolling should remain in the area of resposibility of the implementation of the original algorithm.

[Kiwi1444]

Tested camera in the latest nightly build. I like it. It's more like in Mugen 1.1, less bugs. But I discovered new strange behavior of camera on stage 5 centimeters per second. Video appended. You must jump high enough to see strange beahaviour of camera.

Ikemen_GO_dev_H9mrRjEQrg.mp4

[Eiton]

I assume it only happens on this particular stage.
Does the stage work properly on mugen 1.1? If it works on mugen 1.1, please provide a link to the stage for checking.

[Kiwi1444]

Yes, it happens only on this stage. And yes, camera works properly in Mugen 1.1. Link to the stage.

[Eiton]

This should be fixed in the nightly

[Kiwi1444]

I found new bug in nightly build, that was not present in Ikemen Go 0.99. You need to go to level edge on stage BLOOD POOL REQUIEM 1.1. .

Ikemen Go 0.99:

However, I’m not sure if this relates to a camera problem or not.

[Eiton]

Please provide a link which does not require registering an account to download.

[Kiwi1444]

BLOOD_POOL_REQUIEM_1_1.zip

[Eiton]

This should be fixed in the nightly

[Kasasagi77]

I have added a new parameter: verticalfollowdelta. #1807

[potsmugen]

Maybe add the keyword zoom? When I see verticalfollowdelta I think verticalfollow will change as the camera goes up.

[Kasasagi77]

Hmm... this is analogous to the boundhighdelta parameter which does not have the word zoom in it and it also scales with zoom and not the camera y position.

Should verticalfollowdelta have the word zoom, but boundhighdelta should not have the word zoom? Although both in fact scale with zoom? Or should I also change the name of boundhighdelta to include zoom?

[potsmugen]

That might be clearer and more consistent, yeah. A little verbose but it's for the best.

[Kasasagi77]

Added renames to the PR.

[Kiwi1444]

On some stages camera placed higher than in Mugen and you can't see low part of the fighters.
Prison by Behzad:


Racoon city 1.1 by Flavio Camarao:


Problematic stages appended:
stages.zip

[Kasasagi77]

Do your screenshots not simply show the difference between 4:3 and widescreen? The mugen ones are in 4:3 and the Ikemen ones are in widescreen?

[Kiwi1444]

Mugen screenshots in 4:3 (StageFit = 1). Ikemen ones in widescreen.

[Eiton]

StageFit is not implemented. This is a known missing feature.

[Kiwi1444]

StageFit is not implemented. This is a known missing feature.

That's how Prison stage looks like in Mugen, when stagefit = 0:

(The camera is still placed lower than in Ikemen Go)