Hello out there,

wiedermal brauche ich Hilfe :X Ich hab für mein letztes Spiel einen Texture Loader geschrieben, der damals problemlos lief. Nun, wo ich zum X. mal neu anfange, weil mir mein alter Code schlecht erscheint, und ich den Texture Loader wiederverwerte, tritt ein Fehler in folgender Prozedur auf:



Ich hab viel ausgeklammert und bin zu dem Entschluss gekommen, dass es am IndexOf(); liegen muss... alles was ich am Loader verändert habe, ist, dass ich (HashList<>nil) und die Varriable I hinzugefügt habe, um auszuschließen dass die Hashlist überhaubtnicht existiert (I, um einfach mal nur i:=5; aufzurufen und zu sehen, obs dann immernoch Fehler gibt und der Wurm so irgendwo anders im Code steckt). Sowohl die obere als auch die untere Zeile funktionieren auch eigenständig nicht, und der gemeinsame Teiler ist für mich IndexOf()..

Der Fehler lautet folgendermaßen:



Jemand ne idee? Ich habe momentan so oft strange Fehler, dass ich manchmal denke es liegt an meinem neuen Rechner, mit Vista x64.. kann das sein? Übersehe ich mal wieder etwas? Habe ich sichergestellt, dass die Hashlist existiert? Ich weiß mal wieder nicht weiter, und ich will nur ein paar blöde Texturen! Q_Q

_________________
thanks to the internet we have rule 34, wich states that if something exists, theres a pornographic version of it,

Ich habe keine Ahnung wie die HashList in Delphi funktioniert. Allerdings ist eine Operation indexOf auf einer Hash-Liste nicht wirklich eine gute Idee. Die Elemente sind ZUFÄLLIG in der Liste angeordnet, den der Index wird durch den Hashwert des Elements bestimmt. Jedes mal wenn du ein neues Element hinzufügst, kann sich die Reihenfolge der Elemente erneut zufällig ändern. Außerdem ist eine HashList normalerweise größer als die tatsächliche Anzahl der Elemente, was vermutlich der Grund für deinen Speicherfehler ist.

=> Es wird also ziemlich schwierig sein die Elemente in HashList und dem Array TexArray konsistent zu halten. Ich empfehle die Nutzung einer HashMap, dass würde dir dann mit HashMap.get(pname) direkt die Textur zurückgeben.

_________________
Yeah!

Ich denke nicht, dass dein Problem an Vista 64 Bit liegt. 64 Bit ist bei Delphi sowieso egal, da nur 32 Bit Anwendungen erzeugt werden können. Und wenn die unter 64 Bit Betriebssytem nicht vernünftig laufen würden, dann wäre das Fatal für Microsoft. Ich vermute also, dass das Problem irgendwo in deinem Code liegt. Allerdings an dem bisschen Informationen die du uns gibst kann ich so nicht sehen wo der Fehler liegt. Nicht jeder Fehler liegt dort wo er auftritt.

Erst mal. Hash (in welcher Form auch immer) und doppelte Abfrage von Werten ist bähh. Wenn du die Werte 2 Mal benötigt, dann grundsätzlich immer eine lokale Variable anlegen und das Ergebniss dort rein schreiben und dann diese Variable benutzen.

Dann ist der Einzeiler in meinen Augen auch potenziell Gnubbelcode. Wenn irgendeine Bedingung nicht erfüllt ist wird keine Textur gesetzt. Allerdings hast du a) keine Ahung, dass sie nicht gesetzt wurde und b) auch keine Ahnung aus welchem Grund sie nicht gesetzt wurde. Wenn du aus irgendwelchen Gründen keinen Namen übergeben bekommst, dann läuft doch schon irgendwas schief, oder? Und wenn was schief läuft warum sollte man dann versuchen das Problem zu ignorieren und stillschweigend weiter zu arbeiten? Fehler/Probleme dürfen existieren allerdings muss man dann angemessen drauf reagieren. Mit der Hashlist genau das selbe. Was für einen Grund sollte es haben, dass sie nicht existieren kann. Wenn es bei dir so sein kann, dass der Name leer sein darf dann mag das auch okay sein. Dann ignorieren das was ich oben geschrieben. Zu mindest im Bezug auf den Name. Die HashList sollte aber trotzdem ja wohl immer existieren.

Zu deiner Zugriffsverletzung. Adresse 00000C sieht für mich so aus als ob irgendwo auf ein Objket zugeriffen wird was nil ist. Ich kann dir nur empfehlen mal den Code auf ein paar Zeilen zu verteilen und dann einen Haltepunkt zu setzen und dich stück für Stück mit dem Debugger an die Stelle heranzutasten. Dabei dann immer überprüfen wie die Variablen/Objekte aussehen. Wenn nötig (wahrscheinlich) dann solltest du auch in die Methode hineinsteppen. Nur so kannst du versuchen herrauszufinden an welcher Stelle der Fehler genau passiert. Wenn du die gefunden hast, dann musst du schauen was du machen musst um das zu vermeiden.

Ein Problem was sein könnte. Du überprüfst "HashList <> nil" und greifst in der gleiche Bedingung bereits schon auf ein Member von HashList zu. Das funktioniert nur, wenn du in deinen Projektoptionen die Einstellung "Vollständige Boolsche Auswertung" auf nein hast. Sollte die auf ja stehen werden alle Bedingungen geprüft. Egal ob eine der Bedingungen vorher false war oder nicht. Steht die Option auf nein wird bei der ersten False Bedingung abgebrochen. Wenn also HashList nil ist dann kann es trotzdem passieren, dass er darauf zugreift. Lösung. Entweder die Option setzen oder die IF Anweisungen aufteilen (Seperate IF Anweisungen auf mehreren Zeilen).

Dass es an deinem neuen Rechner liegt halte ich für sehr unwahrscheinlich. Angesichts der Tatsache, dass du an der bösen Addresse 0000000C liest, denke ich dass du irgendwo 'nen NIL-Pointer hast. C als hexadezimale Zahl ist 12 im Dezimalsystem. Wahrschienlich verwendest du deinen NIL-Pointer zusammen mit einem Index. Wenn das Array z.B. aus Strukturen mit der Größe 12 Bytes besteht und du dann auf das zweite Element des Arrays zugreifen willst rechnet dein PC

Addresse des ersten Elements (bei dir NIL) + Größe eines Elements

und kommt auf 12. Tja, und auf diese Addresse darfst du eben nicht zugreifen. Gut möglich, dass du einfach den Aufruf der Init-Methode deiner HashList vergessen hast und das Array deshalb gar nicht im Speicher reserviert hast.

Hoffe ich konnte dir helfen,

mrtrain

Das mit der doppelten Abfrage stimmt natürlich, aber warum ist Hash "in welcher Form auch immer (...) bähh" ?
Hash-Sets und -Maps haben durchaus ihre Berechtigung. Eine HashMap hat eine erwartete Zugriffszeit von O(1). Egal wie groß die Datenmenge ist, du bekommst in konstanter Zeit immer ein Ergebnis. Bei einer Baumstruktur beträgt die Zugriffszeit dagegen O(log n), die Zugriffszeit ist als abhängig von der Datenmenge n. Der Nachteil von Hash-Strukturen ist, dass diese konstante Zeit recht groß ist (Hash muss berechnet werden, Kollisionsbehandlung) und zudem etwas mehr Speicher verbraucht wird.

_________________
Yeah!

Ersteinmal danke für die Antworten

Coolcat, deine antwort ist sehr Hilfreich. Ich werds mit ner Map versuchen^^ Jedoch bin ich mir grade unsicher, ob die zufällige Anordnung ein Problem darstellt; Ich werds so oder so ändern, denn was du sagst klingt dramatisch.

Zu Lossey; ja die doppelte Abfrage ist offensichtlich bescheuert!^^ Die pName<>'' -Sache hat schon ihren grund, es kann sein dass ich für Testzwecke keine Textur setze, und die Abfrage kommt mir nicht sonderlich Rechenaufwendig vor. Weiterhin denke ich, ich habe den Fehler sehr eindeutig lokalisiert... bzg der Vollständige Boolsche Auswertung, gut, ich benutze jetzt delphi 2009 und war von meinem delphi 7 gewohnt, dass es so funktioniert, ich frage mich auch warum ich in einer einzigen if-Abfrage noch die anderen werte checken sollte, das ergebnis ist dann False, wenn eine der Bedingungen False ist.

@mrtrain, danke, ich habe die Hashlist .Create't und .Clear't, hm, wenig initialisierung :X mal gucken ob ich aus deinem Beitrag einen nutzen ziehen kann^^ Das wird etwas Zeit kosten.

Gruß, Robin

Ich melde mich zurück wenn ich die HasMap probiert habe^^

_________________
thanks to the internet we have rule 34, wich states that if something exists, theres a pornographic version of it,

Coolcat: Habe nicht gesagt, dass Hashs bähh sind. Habe selber eine HashKlasse geschrieben und benutze Hashs sehr häufig und bin überzeugter Fan. Ich meinte die Verwendung von Hashs in Verbindung mit doppelten Abfragen. Und das habe ich auch geschrieben. Wenn auch gut verschachtelt.

sirrk: Wenn du magst kannst du dir die Unit von mir ja auch mal anschauen. Ist sehr einfach gehalten. Hinzufügen, Löschen, Auslesen, komplett Auslesen. Das wars.

Das mit den boolschen Ausdrücken macht in der Regel keinen Sinn. Wenn man doch auf so etwas angewiesen sein sollte, dann finde ich das persönlich auch ein ungünstiges Codedesign. Ich selber halte in meinem Code so unendliche Verschachtelungen so gering wie möglich. Also generell die gesammten Strukturen. Und wenn man ein bisschen darauf achtet was der Code macht, dann laufen selbst auch komplexe Anwednungsfälle ohne große Probleme ab. Frei nach dem Motto "keep it simple". Und das hat sich in den letzten Jahren schon sehr oft bewahrheitet.

Nachdem ich mir den TextureLoader aus dem ersten Bomberman Tut angeschaut habe, und drauf und dran war den ersteinmal zu stehlen, ist mir beim Umschreiben meines eigenen Textes aufgefallen, dass mein Objekt TexLoader zwei mal existierte... einmal als Eigenständiges Objekt und einmal als Teil des Engine-Objekts. Total dumm ! Aber ich denke trozdem mehr als eine Sache gelernt zuhaben Vielen Dank für die Bemühungen, auslachen erlaubt

Gruß, Robin

_________________
thanks to the internet we have rule 34, wich states that if something exists, theres a pornographic version of it,