[Other] Rounding Error in Assembly - Odd Number of Colored Types in TCG

MonopolyRubix · Sep 16, 2022

Hello!

I'm trying to add the Dark type to the TCG game using the TCG Disassembly.

Everything seems to be working with one exception: Dark type energy requirements are being treated as colorless energy requirements.

The problem is in src/engine/duel/core.asm, under _CheckIfEnoughEnergiesToAttack:.

Spoiler:

It's ld c, (NUM_COLORED_TYPES) / 2 under .got_atk.

Normally there are 6 colored types, but in src/constants/card_data_constants.asm I changed it to 7. I think that 7 / 2 is being rounded down from 3.5 to 3, which is causing Dark to function as a colorless type. I tried replacing NUM_COLORED_TYPES with 8 so that the calc would result in 4, and that made both Dark and Colorless function as colored types. I want Dark to function as a colored type and Colorless to function as a colorless type.

So I'm pretty sure that I need (NUM_COLORED_TYPES) / 2 to equal 3.5, but because of rounding it can only equal either 3 or 4.

I am fairly unfamiliar with assembly as a language. Is there a way to prevent or bypass this rounding issue?

My edited files can be found here. There is a save file that can be used for testing. Thanks.

Anon822 · Sep 17, 2022

MonopolyRubix said:
Hello!

I'm trying to add the Dark type to the TCG game using the TCG Disassembly.

Everything seems to be working with one exception: Dark type energy requirements are being treated as colorless energy requirements.

The problem is in src/engine/duel/core.asm, under _CheckIfEnoughEnergiesToAttack:.

Spoiler:

_CheckIfEnoughEnergiesToAttack:
push de
ld a, d
call LoadCardDataToBuffer1_FromDeckIndex
pop bc
push bc
ld de, wLoadedCard1Atk1EnergyCost
ld a, c
or a
jr z, .got_atk
ld de, wLoadedCard1Atk2EnergyCost

.got_atk
ld hl, CARD_DATA_ATTACK1_NAME - CARD_DATA_ATTACK1_ENERGY_COST
add hl, de
ld a, [hli]
or [hl]
jr z, .not_usable_or_not_enough_energies
ld hl, CARD_DATA_ATTACK1_CATEGORY - CARD_DATA_ATTACK1_ENERGY_COST
add hl, de
ld a, [hl]
cp POKEMON_POWER
jr z, .not_usable_or_not_enough_energies
xor a
ld [wAttachedEnergiesAccum], a
ld hl, wAttachedEnergies
ld c, (NUM_COLORED_TYPES) / 2

.next_energy_type_pair
ld a, [de]
swap a
call CheckIfEnoughEnergiesOfType
jr c, .not_usable_or_not_enough_energies
ld a, [de]
call CheckIfEnoughEnergiesOfType
jr c, .not_usable_or_not_enough_energies
inc de
dec c
jr nz, .next_energy_type_pair
ld a, [de] ; colorless energy
swap a
and $f
ld b, a
ld a, [wAttachedEnergiesAccum]
ld c, a
ld a, [wTotalAttachedEnergies]
sub c
cp b
jr c, .not_usable_or_not_enough_energies
or a
.done
pop de
ret

.not_usable_or_not_enough_energies
scf
jr .done

It's ld c, (NUM_COLORED_TYPES) / 2 under .got_atk.

Normally there are 6 colored types, but in src/constants/card_data_constants.asm I changed it to 7. I think that 7 / 2 is being rounded down from 3.5 to 3, which is causing Dark to function as a colorless type. I tried replacing NUM_COLORED_TYPES with 8 so that the calc would result in 4, and that made both Dark and Colorless function as colored types. I want Dark to function as a colored type and Colorless to function as a colorless type.

So I'm pretty sure that I need (NUM_COLORED_TYPES) / 2 to equal 3.5, but because of rounding it can only equal either 3 or 4.

I am fairly unfamiliar with assembly as a language. Is there a way to prevent or bypass this rounding issue?

My edited files can be found here. There is a save file that can be used for testing. Thanks.

The Gameboy's CPU doesn't support floating point numbers or division. The division you're seeing is syntactic sugar provided by the assembler. In the compiled ROM the value has to be either 3 or 4. You can find out more about the assembler's capabilities in its documentation.

At a glance it seems like the code is looping through the "colored" types two at a time and calling "CheckIfEnoughEnergiesOfType" for each type. If that's the case, you could probably let the loop run 3 times and add a new check for your new type after the loop.

MonopolyRubix · Sep 17, 2022

Anon822 said:
The Gameboy's CPU doesn't support floating point numbers or division. The division you're seeing is syntactic sugar provided by the assembler. In the compiled ROM the value has to be either 3 or 4. You can find out more about the assembler's capabilities in its documentation.

At a glance it seems like the code is looping through the "colored" types two at a time and calling "CheckIfEnoughEnergiesOfType" for each type. If that's the case, you could probably let the loop run 3 times and add a new check for your new type after the loop.

I see. Thank you very much for the information! :)

MonopolyRubix · Sep 17, 2022

Anon822 said:
The Gameboy's CPU doesn't support floating point numbers or division. The division you're seeing is syntactic sugar provided by the assembler. In the compiled ROM the value has to be either 3 or 4. You can find out more about the assembler's capabilities in its documentation.

At a glance it seems like the code is looping through the "colored" types two at a time and calling "CheckIfEnoughEnergiesOfType" for each type. If that's the case, you could probably let the loop run 3 times and add a new check for your new type after the loop.

It works! I added the stuff in bold.

Spoiler:

Thanks again for the help!