YesNoOk
avatar

Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %) (Read 23579 times)

Started by Sh1nRa358, August 29, 2024, 11:30:40 pm
Share this topic:
Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)
#1  August 29, 2024, 11:30:40 pm
  • *
    • USA
Please adapt this to your coding regimen.

Both char and stages should be in 427x240 to go the standardized 16:9 route. The problem is, we all coded chars ui meters and stuff in 320x240 due to winmugen being 4:3. So when we change the char to 427x240, super bgs and bottom meters get cut off in ikemen or 1.1. But i figured a way that the meters stay in the same place no matter what localcoord u give the char. The process is just as annoying as converting from winmugen to 1.1 but its worth it. I just feel sorry for ppl who've already made alot of chars XD.

For example, we all do this with explods and helpers:

Code:
x = IfElse((teamside = 1), 20, 300)

This confines our char uis to a small box if we use a localcoord that's bigger than 240p.
What we should start doing is converting that to this:

Code:
x = IfElse((teamside = 1), ceil((-ScreenPos X)+(((GameWidth)*(0.0625)))), ceil((-ScreenPos X)+((GameWidth)-((GameWidth)*(0.0625))))) 

<-------HomeTeam      Opponent's team------------>

How i got that is, i take that 20 and use the gamewidth to divide it into. so 20 divided by 320 (or the x of your char's localcoord and if you are coding the y, then it would be the y of your char's localcoord) basically.
Which gives you the 0.0625

We're gonna get rid of the 300 because this formula places the object on p2 side at the same distance of 20 pixel percent.
The 300 was counting the pixels from left to the right which is the bad habited problem.
With this formula, we can achieve the self adaptation for our char's uis. We cant use screenpos by itself because it's still counting pixels and not setting placement by percentage. I tried an equation so that you wouldnt have to use windows calculator for all the pos numbers and just use the number that was already there but unfortunately that worked a lil differently from how I wanted it to work so I believe this is the best way.

My brain formulated this why perfecting my ggxx mini character overlook code. And yes, there is a code on mugenguild for it by wooshaq and armorcage but they arent being honest. Basically me and Syn developed it. I got the idea from one of his interactive stages. I ran it by other outlets to see if we can get help in solving a problem. Wooshaq was a translator for armorcage and armorcage remedied the issue of keeping  a helper in place screenwise not stagewise for WINMUGEN.

This is the code they are claiming but it's actually mine:
https://mugenguild.com/forum/topics/guilty-gear-x2-reload-miniturized-code-armor-cage-167399.0.html

There's also another thread here with the same code. I've also given the appropriate credits in my char readme that I released long ago.

But either way, I used my current findings to perfect it (there's more to the code, that's incomplete what they have there). But discovered that my formula above can remedy the whole localcoord issue without using const(720) triggers. And it also prevents the explod, char, or helper from being affected by the stagezoom.

This is what pos y would look like for you to copy & paste:

Code:
ceil((-ScreenPos Y)+((((GameHeight)*(0.4125))))))

And this is what Y will look like if you have a config txt that allows the user to move the explod up or down if the var that controls that is fvar(3):

Code:
ceil((-ScreenPos Y)+((((GameHeight)*((0.4125)+(root,fvar(3))))))) 


This is the code you can use to prevent the char, helper, or explod from adapting with any stage zoom effects:

Code:
[state 100000000, zoom_size_prevention]
type = angledraw
trigger1 = 1
scale = 4*const(size.xscale)/CameraZoom,4*const(size.yscale)/CameraZoom
persistent = 1

4 is for highrez chars; 2 might be appropriate for low rez chars.


Here is a visual representation:




Now hopefully I can think of something to achieve self adapting velocities on any localcoord.
-What you know,
                    Can blind you from the truth.
Last Edit: August 31, 2024, 04:53:59 pm by Sh1nRa358
Re: Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)
#2  August 30, 2024, 09:21:13 am
  • **
  • Sr. Símio Enfermo
    • Brazil
    • www.mediafire.com/folder/utha9mw5dg7tn/My_Chars
That's very interesting man.
But I have a question: What postype are you using that needs that (-ScreenPos X) expression?

I have some suggestions too:
 * You can use the expression 20/320.0 (note the .0 in the end - in mugen if a number is divided by a float, the result is also a float) instead of 0.0625;
 * You can simplify this expression:
Code:
IfElse((teamside = 1), ceil((-ScreenPos X)+((GameWidth * 0.0625))), ceil((-ScreenPos X)+((GameWidth)-(GameWidth * 0.0625)))) 
To:
Code:
Ceil(GameWidth * Abs(20/320.0 - (TeamSide = 2)) - ScreenPos X)

I have tested this method of yours in my chars and it worked really well.
I'll credit you in my chars' next update.




Re: Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)
#3  August 30, 2024, 11:34:52 am
  • *
    • USA
You can use it anywhere that you use pos x, pos y, offset x, offset y. When calling helpers, postype doesnt matter because you're going to have this in the helper to move it to your desired position. for explods, you're gonna use space = screen since that is the new standard.


that's exactly what i did when I mentioned this: " I tried an equation so that you wouldnt have to use windows calculator for all the pos numbers and just use the number that was already there but unfortunately that worked a lil differently from how I wanted it to work so I believe this is the best way."

It worked a little differently and kinda seemed like it was shifting a little during stagezoom (minus the .0 and the abs part) compared to using the multipy/decimal numbers. But the multiplication seemed to lock it in place just right. So does adding that .0 fix that shifting? The thing about adding the direct 320.0 is that you will remove part of the self adapting part. What if a character was innately coded in another localcoord and it not be 320.0 or what if we figure out the self adapting velsets and we can freely change the localcoords to a higher rez at will? Then we wouldnt be able to because we have 320.0 listed. I tried to make it so you wouldnt have anymore numbers to inject making the process longer.

Edit: This seems to suffice without having to use calculator:

Code:
Ceil(GameWidth * Abs(20/GameWidth  - (TeamSide = 2)) - ScreenPos X)

Shweet!


What would your shortened solution for Y be so you wouldnt have to use calculator on Y? And for your x solution, what if you wanted to elevate a particular teamside to a diff level aka, make your presentation shake on gethit for example, and not have both sides do it at the same time if one didnt get hit (since teamsides arent separated by the ifelse anymore and assuming one is doing common1 coding for every roster member)?
-What you know,
                    Can blind you from the truth.
Last Edit: August 30, 2024, 12:54:55 pm by Sh1nRa358
Re: Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)
#4  August 30, 2024, 11:14:20 pm
  • **
  • Sr. Símio Enfermo
    • Brazil
    • www.mediafire.com/folder/utha9mw5dg7tn/My_Chars
You can use it anywhere that you use pos x, pos y, offset x, offset y. When calling helpers, postype doesnt matter because you're going to have this in the helper to move it to your desired position. for explods, you're gonna use space = screen since that is the new standard.
Got it.

It worked a little differently and kinda seemed like it was shifting a little during stagezoom (minus the .0 and the abs part) compared to using the multipy/decimal numbers. But the multiplication seemed to lock it in place just right. So does adding that .0 fix that shifting?
Adding a .0 makes the division returns a float value.

The thing about adding the direct 320.0 is that you will remove part of the self adapting part. What if a character was innately coded in another localcoord and it not be 320.0 or what if we figure out the self adapting velsets and we can freely change the localcoords to a higher rez at will? Then we wouldnt be able to because we have 320.0 listed. I tried to make it so you wouldnt have anymore numbers to inject making the process longer.
I see.

Edit: This seems to suffice without having to use calculator:

Code:
Ceil(GameWidth * Abs(20/GameWidth  - (TeamSide = 2)) - ScreenPos X)

Shweet!
Niiice.

What would your shortened solution for Y be so you wouldnt have to use calculator on Y?
I didn't understand what is the meaning/division/ratio of 0.4125 in your Y solution.
Code:
ceil((-ScreenPos Y)+(((GameHeight*0.4125)))))
The moment I figured that, I can make my solution.

And for your x solution, what if you wanted to elevate a particular teamside to a diff level aka, make your presentation shake on gethit for example, and not have both sides do it at the same time if one didnt get hit (since teamsides arent separated by the ifelse anymore and assuming one is doing common1 coding for every roster member)?
I guess something like this could work:
Code:
Ceil(GameWidth * Abs(20/GameWidth  - (TeamSide = 2)) - ScreenPos X + (Root, GetHitVar(HitShakeTime) > 0)*(1-(GameTime%2)*2))
Re: Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)
#5  August 31, 2024, 02:12:18 am
  • *
    • USA
Oh, my Y for that example use to be 100 before turning it into a decimal. but I divided the Y (240)  to get a number close to that. But after it i just adusted a few digits because i wanted to move it a lil. But if I hadnt adjusted afterward, , the number would have been 0.416. But if I wasnt available to give you that answer, one could multiply the gameheight y x 0.4125 and that's how one would have found what the number use to be before being converted to a decimal. and in this case the char's y localcoord was 240.

Oh ok, that was just an example but now i see where i can insert the variable if i wanted to do that (I wasnt use to seeing the teamside trigger used like that. Pretty cool).
-What you know,
                    Can blind you from the truth.
Last Edit: August 31, 2024, 02:27:28 am by Sh1nRa358
Re: Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)
#6  August 31, 2024, 02:37:49 am
  • **
  • Sr. Símio Enfermo
    • Brazil
    • www.mediafire.com/folder/utha9mw5dg7tn/My_Chars
Oh, I see.
So this:
Code:
ceil((-ScreenPos Y)+(((GameHeight*0.4125)))))
is just setting the Y position to 99 in y localcoord = 240.

I can't test it right now, but I think  your example can be write like that:
Code:
Ceil(GameHeight*(99/240.0) - ScreenPos Y)
Re: Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)
#7  August 31, 2024, 03:35:20 pm
  • *
    • USA
I tried it. I noticed that if I now try to replace the 320.0 or the 240.0 with it's corresponding GameHeight/Width axis, the code breaks and the Y starts shifting again on zoom. If I leave it as is, it works close enough to the original code with a tiny tiny shift in the X axis (but then again that may be the active angledraw working against the zoom, it's hard to tell but no biggie). If I try to add more parenthesis like the original code, the shortened code breaks entirely because I supposed it's making certain things calculate first in which tends to break the code. And I guess GameWidth and GameHeight constantly change based on zoom factor. Hmmm, if only there was a way to reference the initial static localcoord without going back to calculator.... (like a const(localcoord.x))

So in order to use the shortened code, we have to find a way to make the 320.0 and the 240.0 automatic to make it fully self adapting. I mean most (probably all) characters localcoords are 320x240 so it shouldnt matter. But I'm trying to future proof just in case ppl will go higher in the future. If ppl decide to start using higher localcoords in the future I guess they can use notepad++ to auto change the 320.0 and 240.0s, but I'm a perfectionist so that's gonna eat away at me lol.

Edit: But then again, if a dev wants to use a fvar or helper fvar to store the starting values of gamewidth and gameheight at the beginning of the round, that would probably work when those vars are inserted into the equation.
-What you know,
                    Can blind you from the truth.
Last Edit: September 02, 2024, 02:22:25 am by Sh1nRa358
Re: Self Adapting PosSets & Stop Zoom w/StageZoom (Universal LocalCoord Positions %)
New #8  September 02, 2024, 11:34:31 pm
  • *
    • USA
As I was starting to apply this, I found a flaw. the pure helper based elements it worked for.

But things like explods inside helpers, there is a little complication. For some reason if you call a helper and an explod is called inside that helper; your helper position can affect the explod. if youve called the helper at a position to hide it at 9999.9999, the explod wont show up at all i view which doesnt make sense to me. but if you put 0,0 as the position of the helper, the explod will show BUT how it displays will depend on the axis centering/positioning in the sff of that sprite. if the sprite isnt centered on the axis more work will need to go into the explod parameters and depending on how sprite is on the axis, you will have to calculate teamside1 but you will have to eyeball teamside2.

Pure Helpers arent affected by this issue because they are based on a replica of the player and how they are centered on the axix which is always CENTERED.

But if you havent coded your meter yet, and each side has a diff sprite teamside1 sprite should start on 0,0 (right side of axis) and p2 side sprites should be positioned on the left side of the axis. Then you wouldnt have to eyeball. But if both sides share the same sprite, you are going to have to put in work on p2 side positioning if the sprite is on the right side of the axis. If sprite is centered then both sides will have the same number and it will be easier. But you wont be able to do that for the actual energy inside bar of course because the scaling will need the sprite to be at 0,0 on the left or right side of the axis in order to scale properly (full to empty). Most ppl will have their meters set up in different ways so most ppl will probably have to do the work on p2 side. But luckily a char really doesnt have that many meters. So, for a visual:

Code:
[State -1, Stun_Meter]
type = helper
trigger1 = RoundState = 2 && !numhelper(24000) && !ishelper
name = "Stun"
ID = 24000
pos = 9999,9999 <-----------comment this out or change it to 0,0 or an onscreen value so that explod will show
postype = Left
facing = ifelse(teamside=1,1,-1)
stateno = 24000
keyctrl = 0
ownpal = 1
persistent = 1
ignorehitpause = 1
supermovetime = 0
pausemovetime = 0
size.xscale = 0.05
size.yscale = 0.05

In the helper:

Code:
[State 24000, Stun_Casing]
type = Explod
trigger1 = RoundState = 2 && !numexplod(24000)
ID = 24000
anim = ifelse(teamside=1,24000,24001)
sprpriority = -34
space = screen
postype = Left
pos = IfElse((teamside = 1), ceil((-ScreenPos X)+(((GameWidth)*(0.090625)))), ceil((-ScreenPos X)+floor((GameWidth)-((GameWidth)*(0.090625))*2.9))),58+floor(root,fvar(2))    <----------------------going to have to eyeball that 2.9
Facing = 1
scale = 0.5,0.5
bindtime = -1
ownpal = 1
ontop = 0
removetime = ifelse((RoundState!=2),1,999999999)
supermovetime = 0
pausemovetime = 0
ignorehitpause = 1

But of course, open to more experienced ideas.

EDIT: I probably should be using ScreenWidth and ScreenHeight instead of GAME for the shortened ver code (in place of 320.0 and 240.0 which would remedy that self adapting issue.
-What you know,
                    Can blind you from the truth.
Last Edit: September 03, 2024, 08:11:07 am by Sh1nRa358