Fehler: Out of Memory

[C64-Flo]

Eines Vorweg:

Ich habe praktisch keinen Plan von Delphi (was man an meinen fragen hier oft sieht ), code aber für meine Leben gerne -kA wie das nochmal war, dass ich mit Delphi anfing....

Irgendwie kriegt man schon alles hin, wenn man will..(auch wenn mans übers Knie brechen muss und notorisch BASIC-stile anwendet, obwohls vermutlich schon 1000 neuzeitlichere Wege gibt , wie man das eine oder andere Problem hinbekommt )

Zur Zeit mache ich ein Hack´n´Slay-Tamagotchi-Popp-Spiel(tm)...grob an AD&D angelehnt.
Im Grunde nichts bahnbrechendes, aber in Punkto Suchtfaktor immer noch top!

Unlogische Fehler im Ablauf bis hin zu Ausstiegen an Stellen, die vorher noch funktionierten -

sind das Hinweise auf eine Speicherüberlastung?

Jaja, ich gebs zu, ich hab eine Handvoll globaler Arrays drinne und auch sonst nicht wirklich darauf geachtet, sparsam mit dem Speicher umzugehen...


Bitte bitte kann mir jemand sagen wie ich vielleicht dem Programm mehr Speicher zuweisen kann dass es alle Arrays etc verkraftet?
Bzw wie ich sonst allgemein Speicher sparen könnte?

Wäre es vielleicht besser anstatt 5 2dimensionalen Arrays 1 dreidimensionales zu verwenden?
Oder records?
Darf man nicht über 30 Forms in einem Programm verwenden?
Muss ich jetzt eine Datenbank andocken?

aaaaaaaahhhhhhhhhhhhh

Erinnerungen an
"OUT OF MEMORY"-Meldungen werden wach





[edit=sakura] Großschreibung ist WIE SCHREIEN Mfg, sakura[/edit]

[shmia]

Zitat von C64-Flo:

Irgendwie kriegt man schon alles hin, wenn man will..(auch wenn mans übers Knie brechen muss und notorisch BASIC-stile anwendet, obwohls vermutlich schon 1000 neuzeitlichere Wege gibt , wie man das eine oder andere Problem hinbekommt )

Genau das ist dein Problem; du bist nicht wirklich bereit vom Quick & Dirty Programmieren Abschied zu nehmen.
Unter Windows ist Speichernmangel sehr selten und falls doch, dann wird eben auf Festplatte ausgelagert.
Also meine Glaskugel sagt, dass du Spaghetti Code programmiert hast und nicht der fehlende Speicher schuld ist.

[RedDust]

Also es gibt eine Methode die ich oft anwende sind übergreifende Units, 1. behält man die übersicht und 2. findet man schneller Fehler. Hier mal, wie ich das Prob. lösen würde.

1. Unit

Delphi-Quellcode:

unit variablen;

interface

uses controls;

type TKontakt = record
        Name         : string[255];
        Vorname      : string[255];
        Geburtstag   : TDate;
     end;

     TZeiger  = ^TInhalt;

     TInhalt = record
       Inhalt : TKontakt;
       Next   : TZeiger;
       Prev   : TZeiger;
     end;

var z_akt, z_akt2, z_kopf, z_ende : TZeiger;
    v_dat                         : FILE OF TKontakt;
    VCard                         : TKontakt;

implementation

end.

2. Unit

Delphi-Quellcode:

unit prozeduren;

interface

uses variablen;

procedure p_laden;
procedure p_uebernehmen(kontakt : TKontakt);
procedure p_speichern;

implementation

uses haupt;

procedure p_laden;
begin
  AssignFile(v_dat, ExtractFilePath(Application.ExeName) + 'daten.lst');
  Reset(v_dat);
      WHILE NOT EOF(v_dat) DO
        BEGIN
          IF z_akt = NIL THEN
            BEGIN
              New(z_akt);
              Read(v_dat,z_akt^.Inhalt);
              z_kopf := z_akt;
              z_ende := z_akt;
              z_akt^.Prev := NIL;
              z_akt^.Next := NIL;
            END
          ELSE
            BEGIN
              new(z_akt2);
              z_akt^.Next := z_akt2;
              z_akt^.Next^.Prev := z_akt;
              z_akt := z_akt2;
              Read(v_dat,z_akt^.Inhalt);
              z_ende := z_akt;
              z_akt^.Next := NIL;
            END;
        END;
  z_akt := z_kopf;
end;

procedure p_uebernehmen;
begin
  IF ueberschreiben THEN
    BEGIN
      z_akt^.Inhalt := kontakt;
    END
  ELSE
  IF z_akt = NIL THEN
    BEGIN
      New(z_akt);
      z_akt^.Inhalt := kontakt;
      z_kopf := z_akt;
      z_ende := z_akt;
      z_akt^.Prev := NIL;
      z_akt^.Next := NIL;
    END
  ELSE
    BEGIN
      new(z_akt2);
      z_akt^.Next := z_akt2;
      z_akt^.Next^.Prev := z_akt;
      z_akt := z_akt2;
      z_akt^.Inhalt := kontakt;
      z_ende := z_akt;
      z_akt^.Next := NIL;
    END;
end;

procedure p_speichern;
begin
  IF z_akt <> NIL THEN
    BEGIN
      z_akt := z_kopf;
      AssignFile(v_dat, ExtractFilePath(Application.ExeName) + 'dateiname.endung');
      Rewrite(v_dat);
      WHILE z_akt^.Next <> NIL DO
        BEGIN
          Write(v_dat,z_akt^.Inhalt);
          z_akt := z_akt^.Next;
        END;
      Write(v_dat,z_akt^.Inhalt);
      CloseFile(v_dat);
    END;
end;


end.

Is aber nur 'n Vorschlag. Sollten noch Fragen auftreten, immer stellen.

[SirThornberry]

von welchem Typ ist das Array? Kurz und Knapp. Es kann an dem Array liegen. Ein Array wird im speicher an einem stück gespeichert. Das heißt wenn du in deinem Speicher nicht mehr so großen zusammenhängenden speicher hast kommt es eben zu solchen Fehlern. Lösung wäre eine verkettete Liste oder in dem Array nicht direkt die Records zu speichern sondern nur Pointer auf Records und den speicher für die Records dann selbst anfordern und wieder freigeben. Ich würde in dem Zusammenhang auch von den Array weg kommen und TList verwendet (wobei das intern auch nen Array of Pointer ist, aber eben nur Pointer und nicht riesen records).

[Chewie]

Wenn die Arrays statisch & lokal sind, gibts da sowieso ein Problem, da diese auf dem Stack abgelegt werden, der sehr begrenzt ist. Globale & dynamische werden allerdings auf dem Heap abgelegt, der recht groß ist, eigentlich bei weitem groß genug für ein Jump & Run-Spiel...

[Jens Schumann]

Hallo RedDust,
ich will ja nicht schlaumeiern (mach ich aber bestimmt schon ), aber Dein Code
hat rein gar nichts mit OOP zu tun. Es handelt sich um uralte strukturierte Programmierung.
Ich empfehle in Objekten anstatt mit Records zu denken. Dann kommt man,gerade wenn es
ums Speichern geht, schnell zu dem Gespann TCollection/TCollectionItem. Wenn dann es
irgendwann in Richtung .net geht kann man schnell auf das Serializable Attribut umstellen.


Records sind in ObjektPascal nur wg. der Abwärtskompatiniltät (und ein bißchen WinAPI) enthalten.

[Oxmyx]

Zu 99,99999% liegt das nicht daran, dass zu wenig Speicher verfügbar ist (das tritt unter Windows so gut wie niemals auf), sondern daran, dass du in deinem verwurstelten Spaghetticode einfach die Fehler nicht siehst.

[C64-Flo]

Zitat:

Also es gibt eine Methode die ich oft anwende sind übergreifende Units, 1. behält man die übersicht und 2. findet man schneller Fehler. Hier mal, wie ich das Prob. lösen würde.

@RedDust

Danke für den Einblick in Dein ´kleines schwarzes Medizinbuch´ , aber leider übersteigt der code etwas meine Kentnisse, ich werde das aber bei Zeiten mal in "Try and Error" Manier ausprobieren!

Zitat:

von welchem Typ ist das Array? Kurz und Knapp. Es kann an dem Array liegen. Ein Array wird im speicher an einem stück gespeichert. Das heißt wenn du in deinem Speicher nicht mehr so großen zusammenhängenden speicher hast kommt es eben zu solchen Fehlern.

@ SirThornberry

es handelt sich um 5 globale Arrays ungefähr in Dimensionen ´array[20,6] of integer´ und nochmal ca. 5 array[6] of string
sowie ca. 30 weiteren globalen variablen (Asche auf mein Haupt?)
Ich frage mich, ob eine zusammenfassung zu einem einzigen Integer- und Stringarray etwas bringt? (mathematisch kommts ja aufs selbe raus)
....die sache mit den TLists etc habe ich mir mal eben näher angesehen, und ich denke ich werde das mal testen.

Zitat:

Zu 99,99999% liegt das nicht daran, dass zu wenig Speicher verfügbar ist (das tritt unter Windows so gut wie niemals auf), sondern daran, dass du in deinem verwurstelten Spaghetticode einfach die Fehler nicht siehst.

Zitat:

Unter Windows ist Speichernmangel sehr selten und falls doch, dann wird eben auf Festplatte ausgelagert.
Also meine Glaskugel sagt, dass du Spaghetti Code programmiert hast und nicht der fehlende Speicher schuld ist.

@ Oxmyx+shmia

Na das macht mir doch irgendwie Hoffnung !
Meinen eigenen Spaghetticode habe ich noch immer entwurstelt bekommen - nur die Vermutung dass es nicht daran lag hatte mir den Wind aus den Segeln genommen (Kindheitsschock von C64?)


Also sprich:
Ich könnte theoretisch (wills jetzt nicht testen) 100 globale Arrays einbauen, und das Programm würde das packen? (wenn sie nicht übertrieben lang sind )

Danke nochmal an alle schnellen Antworter!

[Oxmyx]

Zitat von C64-Flo:

Also sprich:
Ich könnte theoretisch (wills jetzt nicht testen) 100 globale Arrays einbauen, und das Programm würde das packen? (wenn sie nicht übertrieben lang sind )

Danke nochmal an alle schnellen Antworter!

Du könntest auch 100 Arrays mit jeweils 1 Million Integers einbauen, wenn du Lust hast. Du bringst einen Computer nicht so schnell dazu, dass er keinen Speicherplatz mehr hat. Gegebenenfalls werden eben Daten ausgelagert auf die Festplatte, aber möglich ist es.

[C64-Flo]

Wow!

Das sind wahrlich gute Neuigkeiten!

Jetzt muss ich nur noch herausfinden, wo die Fehler liegen!


.....wie kann es sein, das eine flag ihren Zustand von einer zeile zur nächsten ändert, OHNE dass sie darin auch nur ansatzweise angesprochen wird?

Irgendwo habe ich gehört, dass mehrere Forms parallel laufen können (oder immer?)....
könnte das die Ursache sein?

Ich meine...bei 30 Forms (die eigentlich als unabhängige ´Bildschirme´ im Spiel funktionieren sollen ...einer als ´Inventory´ einer als ´Kampfbildschirm´ etc) würde somit das Suchen nach zufälligen Effekten von Form12 auf Form24 usw ziemlich ausufern...




Diese mutierte Flag war nämlich das erste ´unerklärliche Phänomen´, welches aber noch verkraftbar war.... Rüstungswerte die um 128 Punkte abweichen (anstatt -2 eben -130) sind da schon eher vernichtend für das gameplay...


Ach wäre das schön, wenn ich tatsächlich die Arrays beliebig erweitern könnte.... schier endlose Monster und Ausrüstungsvarietäten.... <schmacht>