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

32 lines
456 B
NASM
Raw Normal View History

[Maintenance] [th02/th04/th05] Declare more stage and player symbols in C land Part of P0089, funded by [Anonymous] and Blue Bolt.
2020-04-29 20:09:31 +00:00
public PLAYPERF_RAISE
[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
playperf_raise proc far
arg_bx far, @delta:byte
[Reverse-engineering] [th04/th05] Player performance ("rank") management Going with uth05win's "player performance" here, since we already use "rank" for Easy/Normal/Hard/Lunatic. Funded by -Tom-.
2018-12-10 20:00:19 +00:00
[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 al, @delta
[Reverse-engineering] [th04/th05] Player performance ("rank") management Going with uth05win's "player performance" here, since we already use "rank" for Easy/Normal/Hard/Lunatic. Funded by -Tom-.
2018-12-10 20:00:19 +00:00
add al, _playperf
cmp al, _playperf_max
jbe short @@ret
mov al, _playperf_max
@@ret:
mov _playperf, al
[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
playperf_raise endp
[Reverse-engineering] [th04/th05] Player performance ("rank") management Going with uth05win's "player performance" here, since we already use "rank" for Easy/Normal/Hard/Lunatic. Funded by -Tom-.
2018-12-10 20:00:19 +00:00
even
[Maintenance] [th02/th04/th05] Declare more stage and player symbols in C land Part of P0089, funded by [Anonymous] and Blue Bolt.
2020-04-29 20:09:31 +00:00
public PLAYPERF_LOWER
[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
playperf_lower proc far
arg_bx far, @delta:byte
[Reverse-engineering] [th04/th05] Player performance ("rank") management Going with uth05win's "player performance" here, since we already use "rank" for Easy/Normal/Hard/Lunatic. Funded by -Tom-.
2018-12-10 20:00:19 +00:00
mov al, _playperf
[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
sub al, @delta
[Reverse-engineering] [th04/th05] Player performance ("rank") management Going with uth05win's "player performance" here, since we already use "rank" for Easy/Normal/Hard/Lunatic. Funded by -Tom-.
2018-12-10 20:00:19 +00:00
cmp al, _playperf_min
jge short @@ret
mov al, _playperf_min
@@ret:
mov _playperf, al
[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
playperf_lower endp