Heeelp - ludum dare emrgency (unsolved - retard gaff)

[code_glitch]

Yes, I am entering Ludum Dare 21 however a little hitch has occured in this code:

{$Mode ObjFpc}

type
    oApplication = Object
            CycleDelay: Int64;
            LastWait: Int64;
            
            procedure Wait();
        end;

var
    App: oApplication;

procedure oApplication.Wait();
var
    TargetWait: Int64;
    Time: Int64;

begin
    Time := Sdl_GetTicks();
    TargetWait := (Time - LastWait);
    if TargetWait <= 0 then
        TargetWait := 1;
    writeln('W ', TargetWait,' lw ',LastWait, ' t ',Time);
    Pause(TargetWait);
    LastWait := Time;
end;

BUT whenever I call App.Wait() CycleDelay is set to 256 and so is LastWait when it categorically writes the actual time as Time and this occurs with every variable I try to assign that is in an object

If it matters I am on fpc 2.4.0 x64 on a maverick 10.10 box and also occurs on fpc 2.4.0 on Natty x64. Someone please help, no one the IRC picked up

[code_glitch]

And for those of us that possess an overdevelopped gift of idiocy whom make gaffs as big as this the solution is simple:

uses
   Classes;

NO SH*T SHERLOCK

Sorry for the useless post, my big gaff of the LD is above...

[code_glitch]

OK, after basic testing, like running the program again - that did NOT solve the gaff and all INT64 variables have decided to remain on 256 like constants.... Any help would be much appreciated.

[Traveler]

I'm not sure I quite follow this. You say CycleDelay is set to 256 but I don't see it ever get used. Also there is LastWait but it is never initialized.
Anyway, not sure if it helps but I used your code in Delphi and got this "W 1128292 lw 0 t 1128292" as the outcome.

[code_glitch]

CycleDelay is set to 20 during program initialization (forgot to include above)... However, every time Wait is called it resets to 256 instead of 20 without being used anywhere else.

The outcome you posted is exactly on the money for a CycleDelay of 0. Just running the above for me yields W 1100 lw 256 t 1356

[code_glitch]

After having worked on it more, I now have something that works in dry runs occasionally but I always get a 'Killed' and exit code 137. I have no idea what it is but its just as anoying as the bug above that may now have been fixed...