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...

[User137]

The function itself and variables seem ok to me. But what caught my eye is that you use oApplication = Object. I have no idea whatsoever how the deprecated objects work or if they're still supported. You didn't include the essential for the problem (memory leak) which is use of that oApplication.

[code_glitch]

What was the depreciated object replaced by? I was not aware of it being depreciated...

[User137]

More commonly records and classes :)

[phibermon]

(They're not depreciated in Free Pascal, only in Delphi. Free Pascal aims to be compatible with many different Pascal Dialects so you won't be seeing anything disappear like in the proprietary Delphi)

Classes are the more common in the OOP world however Objects can be used in an almost identical manner. They are more like records in that you don't have to have a mandatory constructor or destructor and don't have to call a constructor in order to use the Object. In fact, think of them as Records that support inheritence (certain dialects allow records to have functions and procedures too)

This is because an Objects memory is allocated upon it's decleration in the same way variables are. A Class needs to be created on the heap seperatley. This means that objects are lost when they go out of scope but classes are persistant, requiring that you implicitly call a destructor of a class instance if you want to free up the memory.

Classes are better in this way because it allows a lot more flexiblity in your code, A class does not need any form of Global decleration in order to be used across your program.

Because Objects are not commonly used (and are more for supporting old code) perhaps there are bugs (You should submit your problem to the FreePascal bug tracker!)

Start using classes and if you're still having the same problem then you need to eliminate more factors.

[code_glitch]

Ah, thanks for clearing that up. I tracked the evil bug down to where my main code interfaced with memory management code (reverse flow in a way) duh... And as for the 137, my OS was not hapyp I was using up so much memory soo fast so it kept killing it (running it as sudo fixed it???).

Now well underway and hooping for a strong finish (and hopefully an early one at that) ;)

Note to self: Prometheus is niec to work in when it works, focus of next few weeks will most definetly be on reliability.

Thanks for all the help and sorry to be so ratty, stress, no sleep and time frame.