Rooba
/
ReC98
mirror of https://github.com/nmlgc/ReC98.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ReC98/th04/main/player/shot_velocity.asm

20 lines
358 B
NASM
Raw Normal View History

[Reverse-engineering] [th04/th05] Setting the player shot velocity The TH05 difference: A ridiculous out-of-bounds structure field access. Could have done safely by just passing a shot_t*, but ZUN's too cool for that? Also, about time we started putting the function prototypes directly into the C headers, and the C headers *only*, upon reverse-engineering… Part of P0036, funded by zorg.
2019-10-06 12:25:54 +00:00
public SHOT_VELOCITY_SET
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
shot_velocity_set proc near
arg_bx near, @angle:byte, @velocity:word
[Reverse-engineering] [th04/th05] Setting the player shot velocity The TH05 difference: A ridiculous out-of-bounds structure field access. Could have done safely by just passing a shot_t*, but ZUN's too cool for that? Also, about time we started putting the function prototypes directly into the C headers, and the C headers *only*, upon reverse-engineering… Part of P0036, funded by zorg.
2019-10-06 12:25:54 +00:00
push si
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
mov si, @velocity
[Reverse-engineering] [th04/th05] Setting the player shot velocity The TH05 difference: A ridiculous out-of-bounds structure field access. Could have done safely by just passing a shot_t*, but ZUN's too cool for that? Also, about time we started putting the function prototypes directly into the C headers, and the C headers *only*, upon reverse-engineering… Part of P0036, funded by zorg.
2019-10-06 12:25:54 +00:00
if GAME eq 5
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
movzx bx, @angle
[Reverse-engineering] [th04/th05] Setting the player shot velocity The TH05 difference: A ridiculous out-of-bounds structure field access. Could have done safely by just passing a shot_t*, but ZUN's too cool for that? Also, about time we started putting the function prototypes directly into the C headers, and the C headers *only*, upon reverse-engineering… Part of P0036, funded by zorg.
2019-10-06 12:25:54 +00:00
mov byte ptr [si+shot_t.SHOT_angle - shot_t.pos.velocity], bl
else
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
mov bl, @angle
[Reverse-engineering] [th04/th05] Setting the player shot velocity The TH05 difference: A ridiculous out-of-bounds structure field access. Could have done safely by just passing a shot_t*, but ZUN's too cool for that? Also, about time we started putting the function prototypes directly into the C headers, and the C headers *only*, upon reverse-engineering… Part of P0036, funded by zorg.
2019-10-06 12:25:54 +00:00
xor bh, bh
endif
shl bx, 2
mov eax, _VELOCITY_192_AT_ANGLE[bx]
mov [si], eax
pop si
[Maintenance] Reimplement TASM's ARG directive for `MOV BX, SP` functions `cPtrSize` is simply the wrong constant for calculating parameter offsets on the stack, because it corresponds to the memory model's default distance, not the function's distance. Luckily, ARG has a RETURNS clause, and if you declare all parameters in there, ARG won't emit that pesky and unnecessary `ENTER 0, 0` instruction. Big discovery right there! Sadly, ARG is unusable for ZUN's silly functions that keep the base pointer in BX. TASM declares the resulting equates as `[BP+offset]`, and it's apparently impossible to only get `offset` out of such an equate later. So, rather than staying with numbers, let's reimplement ARG for these functions instead. This way, we can even abstract away the stack clear size for the `RET` instructions. It's a bit rough around the edges though, forcing you to explicitly specify the function distance, and to pass the parameters in reverse order compared to the C declaration (thankfully, all of these use the PASCAL calling convention). It also doesn't work with more complex types yet. But certainly better than numbers. Part of P0134, funded by [Anonymous].
2021-02-10 11:51:14 +00:00
ret_bx
shot_velocity_set endp