(FF7) "Count Up" Timer: Is this unused code?

[antd]

Ok, so I'm looking into the timers a little too much. Well, that's what happens when you are working on an FF7 TAS.

Again, looking at the Countdown Timer in the first reactor, it appears there is a flag that can cause the Countdown to reverse. If this flag is set, the Countdown will become a regular timer, counting up:

Code: (Assembly) [Select]

; CDFraction = Countdown Timer Fraction; TimerDirection = Countdown Timer Direction Flag?; CDSeconds = Countdown Timer Seconds.text:0040AC0F mov     edx, dw_CDFraction       .text:0040AC15 add     edx, 444h.text:0040AC1B mov     dw_CDFraction, edx        ; increase Fraction by 1092.text:0040AC21 mov     eax, dw_CDFraction.text:0040AC26 shr     eax, 10h.text:0040AC29 test    eax, eax                 ; check if Fraction is > 65535 (need to increment seconds).text:0040AC2B jz      short loc_40AC75         ; exit if < 65536 (no need to increment seconds).text:0040AC2D xor     ecx, ecx.text:0040AC2F mov     cl, b_TimerDirection     ; Check timer direction (up or down).text:0040AC35 and     ecx, 2.text:0040AC38 test    ecx, ecx                 ; TimerDirection AND 2.text:0040AC3A jnz     short loc_40AC56.text:0040AC3C cmp     dw_CDSeconds, 0.text:0040AC43 jz      short loc.text:0040AC45 mov     edx, dw_CDSeconds.text:0040AC4B sub     edx, 1.text:0040AC4E mov     dw_CDSecond              ; Count down seconds value....text:0040AC56 loc_40AC56:.text:0040AC56 mov     eax, dw_CDSeconds.text:0040AC5B add     eax, 1.text:0040AC5E mov     dw_CDSecond              ; Count up seconds value

Code: (pseudocode) [Select]

        dw_CDFraction += 1092;                     if ( dw_CDFraction >> 16 )        {                                             if ( b_TimerDirection & 2 )                         {            ++dw_CDSeconds;                           }          else          {            if ( dw_CDSeconds )                          --dw_CDSeconds;          }          dw_CDFraction & 0xFFFF;           

The problem is, the timer direction flag thing is never set to >1. At least I couldn't find any code that writes to it...
I found 2 instructions that write to it and all they do is change it to 1.

A value of 1 should have no effect here though?
1 AND 2 = 0
0 AND 2 = 0
2 AND 2 = 1
Code: [Select]

if ( b_TimerDirection & 2 )                         {            ++dw_CDSeconds;                           }

Seems to always be false.

So it would need to be set to 2 (at least) to make the timer increment instead of decrement.

Off the top of my head, I can only think of the snowboard game using a separate incrementing timer. But then I don't see the flag being set to anything >1 in the code.

The Flag address is only read/written in 3 places. It is read only once (here). It is written to in 2 other places; written to 1 and 0.

Does anyone have any insight on this? Or is this just useless code that they left in?

 

[nfitc1]

That CDFraction is actually in the memory range of the Field Memory bank. A field script can change it directly by accessing offset 5D of bank 1/2 so the affecting code needn't be in the exe. I can't think of any instance where this is used, however.

 

[Cyberman]

That CDFraction is actually in the memory range of the Field Memory bank. A field script can change it directly by accessing offset 5D of bank 1/2 so the affecting code needn't be in the exe. I can't think of any instance where this is used, however.

It would make sense though for semtry or better put program correctness. Remember they didn't make the script FIRST then make the engine they made the engine then made the script.
Thus having a timer go either way does make sense. It was probably ment as "this is a timer you can use" not "this is the count down timer for the reactor scene".

Cyb

 

[DLPB_]

The countdown code is used all the time too... you can set it in memory and it will always count down on the field.  Of course, only really matters when script is asking for what the value is at the moment, like reactor and train etc.

 

[Bosola]

Why would a developer make their code less flexible without good reason? How would the engineer in question be so sure the counter would always move down?

 

[DLPB_]

Well if they called it a "countdown timer" then he would be fairly sure that's what they intended... but if there IS a flag, then it doesn't matter...  it will change direction as soon as it is set.  Just so happens that default is down.

The point I was making above was just that the counter code is always in use, all through the game, even though the actual places it is used are limited.

 

[Bosola]

Well if they called it a "countdown timer" then he would be fairly sure that's what they intended...

Even if a designer or business analyst tells you there's a constraint you can happily incur, you avoid it unless it's a problem. I can't even count the number of projects I've worked on where a 'cast iron guarantee' that this or that won't change has turned out anything but (though that's a grumble for another time...).

As for why it counts down constantly, hard to say. Perhaps it's just sloppy design.

 

[Cyberman]

Even if a designer or business analyst tells you there's a constraint you can happily incur, you avoid it unless it's a problem. I can't even count the number of projects I've worked on where a 'cast iron guarantee' that this or that won't change has turned out anything but (though that's a grumble for another time...).

Welcome to the world of ... consistent inconsistencies.

As for why it counts down constantly, hard to say. Perhaps it's just sloppy design.

Another option is that it was easier to do that way.
I have numerous timers in most of my projects. I've runtime timers, they are all triggered by various flags from the hardware.
That being said it is oft simpler to just have the timer running if it's not doing anything.
I believe if the timer is referenced by the script it's "in use" otherwise it's just thier. The script engine may be able to set it's direction and initialize it's values but the script doesn't make it count (kernal does).  So it may simply be counting because they decided it wasn't good for the script to be able to start and stop the timer.

Cyb

 

[Bosola]

I can see an architectural rationale - perhaps the developer felt it would be best to have a single implementation in the kernel separate to any module.