JLI Spieleprogrammierung

[Fallen]

Das was du ansprichst dürfte der berühmte FPU Bug sein. Das ist ein Hardwarefehler. Du scheinst mit Borland zu programmieren kann das sein. Da habe ich das Phänomän auch.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[Manuel87]

Ne ich hab vc++ und dev-cpp also kein Borland! Das ist schon so wie ich sag! Probier mal aus! Gib ein paar zahlen ein mit wenigen nachkommerstellen und zeig sie mit printf an! Oder schreib sie in ein debugfile! Da sollte jetzt bei manchen eine kleine abweichung sein! Aber ich probiers nochmal aus und sag dann bescheid! Ist schon länger her dass mir das aufgefallen ist!
c.u-

[Fallen]

Achso, das liegt an dem reservierten Speicher für float. Bei printf müsste der versuchen double oder sowas auszugeben und da hat er eben noch extra ballast dran. Du kannst die Ausgabe bei printf so formatieren das er das nicht so macht.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[Manuel87]

Deine "Ballasttheori" ist ja ganz nett! Aber ich hab das schnell getestet und sie trifft nicht zu! Ich hab den Speicher dahinter null gesetzt und dann probiert und das ergebnis war das selbe!

ungefährer code:
char a[100];
float *fa=NULL;
memset(a,0,99);
fa=(float*)a;
(*fa)=4000.2; <= tritt nur bei größeren zahlen auf (soweit ichs getestet hab!)
printf("%f\n",fa);
...
...

danach hab ich noch den restlichen speicher gecheckt und es sind nur die ersten 4 BYtes verändert und die anderen null!

Ich galube, da es nur bei größeren zahlen auftritt, das es ein format mit Hochzahlen ist und normalen zahlen, sodass kleine werte mit wenig nachkommerstellen realtiv genau bis exact gespeichert werden können! Doch bei großen zahlen mit vielen nachkommerstellen wird float ungenau!

VORSICHT bei loops mit der zeit (like gameloop!)!
Mir ist es passiert, dass ich da negative zahlen bekommen hab:

Ich hab in meinem loop nicht viel getan! Nur mein animationstool getestet und ein paar simple striche per gdi gezeichnet! Da ist es mir passiert das die bewegung plötzlich falsch war! (das liegt nicht an meinem animationstool [nicht nur!]); Der loop war in der form:

float last,etime;// letzte; und vergangene zeit zwischen loopanfang und ende

last=get_tick();
calculate(etime);
doo_drawing();
etime=get_tick()-last;

Nun kann es passieren, dass durch ungenauigkeiten des types float last aufgerundet wird und get_tick von mir aus abgerundet oder gleich bleibt! Dadurch dass der unterschied zwischen den beiden last und get_tick soooo winzig klein ist wird dann last größer als get_tick()!
Probiert es aus wenn ihrs nicht glaubt! Wenn ihr wollt geb ich euch das test prog! Oder besser den source code!

Jedenfalls ist dann etime negative was rein nach mathematik und so nicht sein kann!!

get_tick ist nur eine pseudofunktion... sie soll die sekunden die seit mitternacht vergangen sind als float zurückgeben

allerdings find ich float trotzdem besser als double (wenn man die genauigkeit nicht braucht!!!) und benutzte in solchen loops einfach eine Obergrenzer der framerate! Eine die bei einem Spiel wahrscheinlich eh nicht erreicht werden kann, aber es ist notwendig, damit mein spiel z.b. auch noch in 10 Jahren ,wenn computer um ein vielfaches schneller sind rennt!