Dynamic Gravity [JoshuaMK]

[JoshuaMK]

Dynamic Gravity [JoshuaMK]

NOTE: Outdated by newer version.

Note: This code only works with GCN. It also only works with 1P's remote. This code utilizes memory region 0x80001790 of the Exception Vector Area. Make sure no other codes being used utilize this memory region.

This code changes gravity dynamically based on how much you hold up or down on the analog stick!

(NTSC-U)
C2576FC0 00000002
901D0218 3D808000
900C1790 00000000
C2590400 00000018
3D808000 816C1790
2C0B001E 41800040
3D808034 618CC203
896C0000 2C0B00E4
4181005C 2C0B00C9
41810044 2C0B00AE
4181002C 2C0B0020
41800074 2C0B003B
4180005C 2C0B0056
41800044 3D80XXXX
919F0000 C03F0000
48000060 3D80MMMM
919F0000 C03F0000
48000050 3D80hhhh
919F0000 C03F0000
48000040 3D80HHHH
919F0000 C03F0000
48000030 3D80LLLL
919F0000 C03F0000
48000020 3D80UUUU
919F0000 C03F0000
48000010 3D80YYYY
919F0000 C03F0000
60000000 00000000

(PAL)
C257D824 00000002
901D0218 3D808000
900C1790 00000000
C2596C24 00000018
3D808000 816C1790
2C0B001E 41800040
3D808035 618C0583
896C0000 2C0B00E4
4181005C 2C0B00C9
41810044 2C0B00AE
4181002C 2C0B0020
41800074 2C0B003B
4180005C 2C0B0056
41800044 3D80XXXX
919F0000 C03F0000
48000060 3D80MMMM
919F0000 C03F0000
48000050 3D80hhhh
919F0000 C03F0000
48000040 3D80HHHH
919F0000 C03F0000
48000030 3D80LLLL
919F0000 C03F0000
48000020 3D80UUUU
919F0000 C03F0000
48000010 3D80YYYY
919F0000 C03F0000
60000000 00000000

(NTSC-J)
C257D1A4 00000002
901D0218 3D808000
900C1790 00000000
C25965A4 00000018
3D808000 816C1790
2C0B001E 41800040
3D808034 618CFF03
896C0000 2C0B00E4
4181005C 2C0B00C9
41810044 2C0B00AE
4181002C 2C0B0020
41800074 2C0B003B
4180005C 2C0B0056
41800044 3D80XXXX
919F0000 C03F0000
48000060 3D80MMMM
919F0000 C03F0000
48000050 3D80hhhh
919F0000 C03F0000
48000040 3D80HHHH
919F0000 C03F0000
48000030 3D80LLLL
919F0000 C03F0000
48000020 3D80UUUU
919F0000 C03F0000
48000010 3D80YYYY
919F0000 C03F0000
60000000 00000000

(NTSC-K)
C256B87C 00000002
901D0218 3D808000
900C1790 00000000
C2584C7C 00000018
3D808000 816C1790
2C0B001E 41800040
3D808033 618CE583
896C0000 2C0B00E4
4181005C 2C0B00C9
41810044 2C0B00AE
4181002C 2C0B0020
41800074 2C0B003B
4180005C 2C0B0056
41800044 3D80XXXX
919F0000 C03F0000
48000060 3D80MMMM
919F0000 C03F0000
48000050 3D80hhhh
919F0000 C03F0000
48000040 3D80HHHH
919F0000 C03F0000
48000030 3D80LLLL
919F0000 C03F0000
48000020 3D80UUUU
919F0000 C03F0000
48000010 3D80YYYY
919F0000 C03F0000
60000000 00000000

---

Gravity is a float value, so use a hex to floating point calculator for help.

---

XXXX = Gravity when not in air or neutral stick in air
MMMM = Gravity when holding slightly up on analog stick in air
hhhh = Gravity when holding moderately up on analog stick in air
HHHH = Gravity when holding all the way up on analog stick in air
LLLL = Gravity when holding slightly down on analog stick in air
UUUU = Gravity when holding moderately down on analog stick in air
YYYY = Gravity when holding all the way down on analog stick in air

---

General Chart:

0000 = x0 Gravity
3f00 = x0.5 Gravity
3f20 = x0.625 Gravity
3f40 = x0.75 Gravity
3f60 = x0.875 Gravity
3f80 = x1 Gravity
4000 = x2 Gravity
4040 = x3 Gravity
4080 = x4 Gravity
40a0 = x5 Gravity
4120 = x10 Gravity

---

#########
#Source ASM#
#########

#######################
#Store Air Timer Value Into Memory#
#######################

stw r0, 0x0218 (r29)
lis r12, 0x8000
stw r0, 0x1790 (r12)

#########################
#Load Air Timer Value Into Register 11 #
#########################

lis r12, 0x8000
lwz r11, 0x1790 (r12)

############################################
#Compare r11 to Set Value and Branch to Normal Gravity if Less Than #
############################################

cmpwi r11, 30
blt normal_value

############################
#Load Analog Stick Y Axis Byte Into Memory#
############################

lis r12, 0x8034
ori r12, r12, 0xc203
lbz r11, 0 (r12)

#####################################
#Compare Y axis Byte to set values and Branch Accordingly#
#####################################

cmpwi r11, 0xe4
bgt heaviest_value
cmpwi r11, 0xc9
bgt heavier_value
cmpwi r11, 0xae
bgt heavy_value
cmpwi r11, 0x20
blt lightest_value
cmpwi r11, 0x3b
blt lighter_value
cmpwi r11, 0x56
blt light_value

################################
#Set New Value for Gravity and Branch to the End #
################################

normal_value:
lis r12, 0x3f80
stw r12, 0 (r31)
lfs f1, 0 (31)
b the_end
heavy_value:
lis r12, 0x3f95
stw r12, 0 (r31)
lfs f1, 0 (31)
b the_end
heavier_value:
lis r12, 0x3fb0
stw r12, 0 (r31)
lfs f1, 0 (31)
b the_end
heaviest_value:
lis r12, 0x3fc5
stw r12, 0 (r31)
lfs f1, 0 (r31)
b the_end
light_value:
lis r12, 0x3f65
stw r12, 0 (r31)
lfs f1, 0 (r31)
b the_end
lighter_value:
lis r12, 0x3f50
stw r12, 0 (r31)
lfs f1, 0 (r31)
b the_end
lightest_value:
lis r12, 0x3f35
stw r12, 0 (r31)
lfs f1, 0 (r31)
the_end:

---

Code Creator: JoshuaMK
Code Contributors: Hamster35000vr (Gravity RAM address used to find code that sets gravity value)

[Vega]

Nice work! I'm amazed at how good you are at ASM. I finished the ports, btw.

I went ahead and bolded your name for Code creator.  It's a nice touch I like to add to my own code threads. Feel free to move all the code credits before the gigantic wall of source (I do it sometimes if the source is very long lol).

For any branch instructions that are..

blt
ble
bgt
bge

You might want to get into the habit of using a logical comparison beforehand instead of signed (use cmplwi/cmplw instead of cmpwi/cmpw). It's not needed in this particular code, but you may run into an instance where the game treats the values logically, so if you are working with those values as signed, it could cause some issues.

The only time you wouldn't need logical comparisons for those branches if you know that negative values could be possible.

Also... you can see I edited the parts of the compiled code for PAL, J, and K for the analog stick byte load.

Those addresses are..
pal 80350583
ntsc-j 8034FF03
ntsc-k 8033E583

This would be a perfect time for you to learn Macros and set the source to compile the different analog byte locations depending on which region is designated for the compiler. - http://mkwii.com/showthread.php?tid=1083

Once again, great work!!!!

[JoshuaMK]

Btw I wanted to go ahead and ask about logical ANDs and how to do them for controller based if statements, because in your tutorial you have the logical AND listed as:

and r11, r11, 0x0880 #Logical AND

This causes issues because you can't have the 0x0880 in the AND instruction. This is only possible with the AND Immediate instruction, andi.

So how would this be done? Would it be:

andi. r11, r11 0x0880

Or would it be:

and r11, r11, r?

I need to know this so I can do controller if statements in my codes.

[Vega]

Sorry about that, it was a simple typo.

lis r12, 0x8034
lhz r11, 0x3E80 (r12)
andi r11, r11, 0x0880 #And Immediate, Logical AND using r11 & 0x0880
cmpwi r11, 0x0880
beq- the_label

Here's a simple code I made using ASM for button activator/deactivator - http://mkwii.com/showthread.php?tid=893 (source below is for NTSC-K specific version, haven't updated that particular source to use macros for region variances)

[JoshuaMK]

Sorry about that, it was a simple typo.

lis r12, 0x8034
lhz r11, 0x3E80 (r12)
andi r11, r11, 0x0880 #And Immediate, Logical AND using r11 & 0x0880
cmpwi r11, 0x0880
beq- the_label

Here's a simple code I made using ASM for button activator/deactivator - http://mkwii.com/showthread.php?tid=893 (source below is for NTSC-K specific version, haven't updated that particular source to use macros for region variances)

So I looked at your ASM in that code, and there was 2 things that confused me. First off, with this:

and r0, r11, r7 #Logically AND the contents of r11 & r0, store result into r12
cmpw r0, r7 #Compare value of r12 to r0.
beq- set_regionoption1 #If equal (activator is pressed), jump to set_regionoption1 label


^Your #notes don't even match up with the source ASM, specifically it saying your storing it into r12 when clearly it is being stored into r0, which your #notes say is being ANDed with r11.

Secondly, this isn't an andi. instruction, but a simple AND instruction. So is this the right way or do you actually use andi.? Also you typed (andi.) as (andi) which is actually incorrect.

[Vega]

I rush my notes on sources, since a lot of times I add them afterwards. Just a typo lol.

I set the button values in a register via Li, then did an AND, because of assumed issues with sign extension if trying to let users fill in negative button values (such as GCN Y button 0x0880 in the compiled code) for an AND IMMEDIATE, the sign extension would mess up the following comparison-branch.

But now looking back at it, when you logically AND 0xFFFF0880 with 0x00000880, the result is 0x00000880, so the sign extension doesn't matter. So the instructions to set the button values via Li, then doing a normal AND is redundant. AND Immediate with the user's button values without using Li is more efficient. So yes you are correct, thanks for catching that.

Btw you shouldn't use andi. (with the dot), unless you know your comparison afterwards is going to be cmpwi rX, 0. Basically because GCN exists (button value is 0x0080 when NO buttons are pressed), you will need to use andi (NO dot) and then cmpwi with the desired button value. If your code is wiichuck/wheel/classic only, you could use andi. (with the dot) and then do an opposite branch of what would have been if you did a normal And Immediate.

Fyi, the dot is a shortcut for cmpwi rX, 0.

Example.
andi. rX, rY, VALUE
bne/beq some_label

^That will work

Another example.
andi. rX, rY, VALUE
cmpwi rX, 0x0
bne/beq some_label

^redundant instruction

Another example.
andi. rX, rY, VALUE
cmpwi rX, SOME_VALUE_NOT_ZERO
bne/beq some_label

^added dot is pointless cuz you are not comparing to zero

[JoshuaMK]

I rush my notes on sources, since a lot of times I add them afterwards. Just a typo lol.

I set the button values in a register via Li, then did an AND, because of assumed issues with sign extension if trying to let users fill in negative button values (such as GCN Y button 0x0880 in the compiled code) for an AND IMMEDIATE, the sign extension would mess up the following comparison-branch.

But now looking back at it, when you logically AND 0xFFFF0880 with 0x00000880, the result is 0x00000880, so the sign extension doesn't matter. So the instructions to set the button values via Li, then doing a normal AND is redundant. AND Immediate with the user's button values without using Li is more efficient. So yes you are correct, thanks for catching that.

Btw you shouldn't use andi. (with the dot), unless you know your comparison afterwards is going to be cmpwi rX, 0. Basically because GCN exists (button value is 0x0080 when NO buttons are pressed), you will need to use andi (NO dot) and then cmpwi with the desired button value. If your code is wiichuck/wheel/classic only, you could use andi. (with the dot) and then do an opposite branch of what would have been if you did a normal And Immediate.

Fyi, the dot is a shortcut for cmpwi rX, 0.

Example.
andi. rX, rY, VALUE
bne/beq some_label

^That will work

Another example.
andi. rX, rY, VALUE
cmpwi rX, 0x0
bne/beq some_label

^redundant instruction

Another example.
andi. rX, rY, VALUE
cmpwi rX, SOME_VALUE_NOT_ZERO
bne/beq some_label

^added dot is pointless cuz you are not comparing to zero

When I try to compile ASM into Gecko Codes it always says andi is not a valid instruction, and after looking at IBMs Power PC instructions, andi with the dot is the only and immediate instruction. So if you have been using andi without a dot successfully, could you please tell me what I might be typing wrong?

[Vega]

Wow, I totally forgot And Immediate (withOUT the Record/dot) is not a PowerPC function (for whatever reason).

No wonder why I had to set the button values via Li, then use normal AND, followed by a cmpw. Ok well anyway, you can still use andi. (with the dot) if you don't care about your code not working for GCN. If you want your code to also work with the GCN, use the same method I used in the code I linked you.

[JoshuaMK]

Wow, I totally forgot And Immediate (withOUT the Record/dot) is not a PowerPC function (for whatever reason).

No wonder why I had to set the button values via Li, then use normal AND, followed by a cmpw. Ok well anyway, you can still use andi. (with the dot) if you don't care about your code not working for GCN. If you want your code to also work with the GCN, use the same method I used in the code I linked you.

Okay thanks! I'm currently rewriting the Dynamic Gravity code to make it compatible with all remotes, although one issue is I don't have a way to connect a Wii Remote to Dolphin! So if possible could you find the y axis address for the Wii Remote based controllers? Thanks if you can!

[Vega]

You can set your hotkeys to do all sorts of different motions on an emulated Wii remote with any desired extension attached/not-attached. It appears Y Axis (NTSC-U Wii Wheel) is the word value at 0x80341474. When the Wii Remote is not moving at all, its all zeros. When I activated my hotkey for Dolphin to shake the Wii Wheel Vertically up and down, the values start changing.

The XYZ sticky thread in codes forum uses this address..

Code:

Special X/Y/Z Values

NTSC-U
24341474 BF735000 = Wii Mote Vertical
26341474 BF735000 = Wii Mote Sideways

PAL
243457F4 BF735000 = Wii Mote Vertical
263457F4 BF735000 = Wii Mote Sideways

NTSC-J
24345174 BF735000 = Wii Mote Vertical
26345174 BF735000 = Wii Mote Sideways

NTSC-K
243337F4 BF735000 = Wii Mote Vertical
263337F4 BF735000 = Wii Mote Sideways

Hope this helps...