fprwards and backwards logic in IF statements (in assembly)

[ParadigmShifter]

Well that's like asking why Sony told Naughty Dog to stop writing their programs in a LISP variant Crash Bandicoot (PS1) was written entirely in GOAL (nope, it was called GOOL then, GOAL was later on, for Jak and Daxter).

Once you have a C compiler you can get an open source compiler for pretty much any language you require.

https://en.wikipedia.org/wiki/Game_Orie ... embly_Lisp

In all honesty, the biggest reason we're not using GOAL for next-gen development is because we're now part of Sony. I can only imagine Sony's shock when they purchased Naughty Dog a few years back, hoping to be able to leverage some of our technology across other Sony studios, and then realized that there was no way anyone else would be able to use any of our codebase. Sony wants us to be able to share code with other studios, and this works both ways - both other studios using our code and vice versa. Add this to the difficulty curve of learning a new language for new hires, lack of support from external development tools (we had our own compiler, linker, and debugger, and pretty much had to use Emacs as our IDE), etc, means that there are clearly a lot of other factors involved. Note, however, that these issues aren't really technical problems, they're social ones.

— Scott Shumaker

[ketmar]

that's easily solveable: don't work with corporations! ;-) they decided to sell their freedom — ok, it was their choice. i'd quit the moment somebody tell me that i have to abandon my dev tools because something-something-corporate-bullsh*t. actually, i did that more than once in my life. ;-)

[sn3j]

Oh I see you're using a label and a call, to make it more 'forwards logic' like. That's good.

To compare forwards vs backwards logic, in your terms, I'll extend on my last snippet.

Forwards:

Code: Select all

  calculate_enemy_state() ; yields C if dead, M if shield protected, Z if no hp left, else: 1..xx hp 
  jr c L_Explosion
  jr z L_KillEnemy
  jp m L_Protected
  jr L_DamageEnemy
L_Explosion:
  call Explosion
  jr L_CarryOn
L_KillEnemy:
  call KillEnemy
  jr L_CarryOn
L_Protected:
  bit 6,a ; check protection type in bit 6 to calculate effective damage (0 - weak, 1 - strong)
  jr z L_WeakShield
  half_damage()
L_WeakShield:
  half_damage() ; weak shield reduces dmg to 50% strong shield to 25%
L_DamageEnemy:
  call DamageEnemy
L_CarryOn:
  ...

Backwards:

Code: Select all

  calculate_enemy_state() ; yields C if dead, M if shield protected, Z if no hp left, else: 1..xx hp 
  jr nc L_EnemyExists
  call Explosion
  jr L_CarryOn
L_EnemyExists:
  jr nz L_EnemyHasHPLeft
  call KillEnemy
  jr L_CarryOn
L_EnemyHasHPLeft:
  jp p L_DamageEnemy
  bit 6,a ; check protection type in bit 6 to calculate effective damage (0 - weak, 1 - strong)
  jr z L_WeakShield
  half_damage()
L_WeakShield:
  half_damage() ; weak shield reduces dmg to 50% strong shield to 25%
L_DamageEnemy:
  call DamageEnemy
L_CarryOn:
  ...

If I got it right what you meant with forward/backward, of course.
As you can see there's not much difference. In the end, same amount of jumping around.

[ParadigmShifter]

It is possible to optimise stuff a bit (advanced topic) because of the timing difference between JR <condition> depending on whether the branch is taken or not so it can make a difference.

JR <condition>, label

takes 12T if the jump is performed and 7T otherwise. So if you have a loop that only performs the jump once in every 8 cases you can (and maybe should, if timing in that part of the code is important) optimise for that (by reversing conditions and rearranging code if necessary).

JP <condition>, label always takes the same amount of time (10T) regardless of whether the condition is met or not. (So JP is faster than a JR with no condition although it is 1 byte longer). It's slower if the jump from JR is not taken though.

EDIT: Beer o'clock maths removed

[ketmar]

i think that counting t-states is slightly too much for simple rpg-like game. ;-)