float = 4.344e-044#DEN (im Vertexbuffer)
-
LinkeT schrieb:
wo?!
das musst du durch debuggen rausfinden.
-
rapso schrieb:
LinkeT schrieb:
wo?!
das musst du durch debuggen rausfinden.
sach ma liest hier keine was ich schreibe?
der fehler liegt (hab ich durchs DEBUGGEN herausgefunden) bei fread !!!!!! oder soll ich mir das disammbley anschauen und sagen hier ist der fehler juhey ...
-
LinkeT schrieb:
rapso schrieb:
LinkeT schrieb:
wo?!
das musst du durch debuggen rausfinden.
sach ma liest hier keine was ich schreibe?
der fehler liegt (hab ich durchs DEBUGGEN herausgefunden) bei fread !!!!!! oder soll ich mir das disammbley anschauen und sagen hier ist der fehler juhey ...
es sieht eher so aus:
- fread ist fehlerhaft -> chancen gehen gegen 0% dass das so ist
- fehlerhafte benutzung von filestreams -> chancen stehen gut
- fehler woanderes -> chance ist 100%-vorherige moeglichkeit.
-
der fehler liegt bei fread
es ist allerdings verhaeltnismaessig unwahrscheinlich in standard-funktionen die seit 20 jahren im einsatz sind, tatsaechlich noch fehler zu finden...
dein geschildertes verhalten (codegroesse waechst -> fehler behoben / zusaetzlichen heap-speicher allokiert -> fehler verschoben) deutet auf einen fehler deinerseits hin und der muss nicht unbedingt dort lokalisierbar sein wo er auch auftritt.
-
hellihjb schrieb:
der fehler liegt bei fread
es ist allerdings verhaeltnismaessig unwahrscheinlich in standard-funktionen die seit 20 jahren im einsatz sind, tatsaechlich noch fehler zu finden...
dein geschildertes verhalten (codegroesse waechst -> fehler behoben / zusaetzlichen heap-speicher allokiert -> fehler verschoben) deutet auf einen fehler deinerseits hin und der muss nicht unbedingt dort lokalisierbar sein wo er auch auftritt.
klingt eher nach
darueber hinaus waere es sinnvoll die datei im binaermodus ("rb", "wb") zu behandeln...
und
alles einzeln ... ok wenns den sein muss *grml*
klingt nach (edit: das es einzeln laeuft mein ich damit)
- fehlerhafte benutzung von filestreams -> chancen stehen gut
loesung:
lese:
-
und
du allokierst speicher fuer deine vertices und ueberschreibst den zeiger beim lock des vertexbuffers
Ohne malloc stürzt das Program (warum auch immer) ab und zwar mit ein Fehler wo hin zu schreiben.
klingt nach:
da liegt noch mehr im argen
-
hellihjb schrieb:
und
du allokierst speicher fuer deine vertices und ueberschreibst den zeiger beim lock des vertexbuffers
Ohne malloc stürzt das Program (warum auch immer) ab und zwar mit ein Fehler wo hin zu schreiben.
klingt nach:
da liegt noch im argen
ich glaube das stoert ihn nicht so sehr, das kaputte float is hingegen wohl gerade der showstopper
-
offenbar glaubt ihr, weil ich erst seit 4 tagen im forum registriert bin, das ich zu dumm bin nen debugger zu verwenden
http://img402.imageshack.us/my.php?image=fehlerbeifreadog5.jpg
in diesem moment benötigt das program nur 7.512k (laut taskmanager) - und ich hab schon spiele mit mehr als 200.000k hierlaufen lassen (BF2 zB mit 800MB+)
so bei tv1 sollte eigentlich eine 1 stehen (was auch bei der anderen lesse weisse richtig passiert) und man sieht AUCH das es bei 90tenmal passiert und beim 91ten noch mal;)
was das mit dem heap/stack auf sich hat weis ich nicht - ich weiss nur wenn man ein program schreibt was den speicher immer wieder mit malloc reserviert und nicht mit free() wieder frei gibt läuft der speicher irgendwann mal voll -> (im schlimmsten fall) BSOD oder unhandled exeption das programm stürzt ab...
EDIT:
das Program ist im momment 11.5MB im speicher gross (also wenn es läuft)
-
LinkeT schrieb:
offenbar glaubt ihr
und der fehler tritt auf obwohl du auf binary umgestellt hast?
-
da es mit "r" zu 98% (100-2) funktioniert hat sah ich da keine logik drinne das ein kleines b was ändert ... bzw hatte ich das auch zum anfang mal getestet gab aber auch einen fehler - ich führe aber kein logbuch zum nach schauen - welcher es war wies ich nicht mehr...
was mich aber ein wenig in rage gebracht hat war diese(r) kommentar von tggc - aus meiner sicht unqualfiziert und nicht hilfreich, entschuldigung wenn ich andere etwas unhöfflich angegangen bin ...
das mit dem "rb" war der knackpunkt warum auch immer ... es ist halt so[punkt]
-
liegt wohl daran, das vorher wohl ein wert kam der als char 0 ist und das fread dann noch was dranhing, damit wurde dann die nachfolgende zahl eventuell kaputt gemacht. durch das dranhaengen kann auch der memoryueberschreiber aufgekommen sein.
ich werte deinen punkt mal als
close
