PureBoard

Thomas, nun sag doch mal, wo Deine 32-Bit-Werte herkommen !

Hab nur die 32-Bit Version des PB-Compilers genutzt. Der Rest ist gleich.

Hallo,

.f und .d Ungenauigkeiten, wer kennt die nicht. Ist halt systemisch bedingt.

@Helle,

mal eine Frage, ich war nämlich gerade über mein Ergebnis enttäuscht bei dem Test von dir,
mein I7 mit Win64 spuckte da rund 12000 ms aus, egal ob mit 32 oder 64 Bit PB.

Was spielt für den Test alles eine Rolle, oder ist die tatsächliche Zeit eher Nebensache.

Ein Test mit einem P4 mit 32 Bit XP brachte rund 29000 ms (nur 32 Bit). Ein weiterer Test
auf einem 2Core2Duo mit 32 Bit Windows 8 ebenfalls wie beim I7 rund 12000 ms.
Zum Schluß noch ein Test auf einem Celeron ( ) - mit sage und schreibe rund 90000 ms

Gruß Jens

Ich würde ja den Debugger ausschalten beim solchen Tests

Hi Thomas, wo du Recht hast, hast du Recht Auf die Idee bin ich zwischenzeitlich
auch schon gekommen, und da ist es dann nicht mehr Besorgniseregend

1653 - 1076 - 1077 - 1638 ms (I7-32)
1685 - 1107 - 1107 - 1685 ms (I7-64)

1359 - 797 - 812 - 1343 ms (2C2D-32)

Gruß Jens

Nun dann stelle ich mir aber die Frage, wenn man das weiß warum ändert man dann nicht einfach die Funktion OpenWindowedScreen() in der 32 bit Version so das die Genauigkeit automatisch wieder auf den richtigen Stand gebracht wird nachdem sie aufgerufen wurde. Denn ich denke was Helle hier geschrieben hat ist nicht gerade trivial und der Eine oder Andere hier wird sich sicherlich auch schon mal gefagt haben warum seine Berechnungen ein anderes Ergebnis lieferten als erwartet.

Warum sollte man es ändern? Ist doch ein geiles Feature, auf einem Screen kommt es doch auf Geschwindigkeit drauf an und
nicht auf Rechengenauigkeit. Das ganze ist ja kein Bug oder Fehler, das ist bewußt so gemacht worden und wurde auch von
MS entsprechend dokumentiert.

Da hast du ja recht das es bei den meisten Anwendungen nicht so auf Genauigkeit ankommt aber eben nicht immer und wenn ich den Typ .d verwende dann erwarte ich auch die Genauigkeit vom Typ .d und nicht vom Typ .f man hat ja schließlich schon seine Gründe warum man Doubles verwendet. Da wäre es vieleicht ganz hilfreich wenn es in der PB-Hilfe einen entsprechenden Hinweis darauf geben würde und wie man es ändern kann.

captain_hesse hat geschrieben:Da wäre es vieleicht ganz hilfreich wenn es in der PB-Hilfe einen entsprechenden Hinweis darauf geben würde und wie man es ändern kann.

Naja, aber wenn in der Hilfe auf jede solcher selten auftretenden Besonderheiten hingewiesen wird, wird diese sehr schnell
unübersichtlich und somit für Einsteiger unbrauchbar.

Meiner Meinung nach, sind solche Sachen im Forum besser aufgehoben. Mit einer überladenen Hilfe ist auch nicht jedem
gedient.

Sollte man hier vielleicht in die FAQ eintragen, ist nur die Frage, guckt da jemand nach

ts-soft hat geschrieben:Warum sollte man es ändern? Ist doch ein geiles Feature, auf einem Screen kommt es doch auf Geschwindigkeit drauf an und
nicht auf Rechengenauigkeit. Das ganze ist ja kein Bug oder Fehler, das ist bewußt so gemacht worden und wurde auch von
MS entsprechend dokumentiert.

Das ist bei MS dokumentiert, aber bei PB ist das einfach ein Bug. In der Hilfe steht nichts davon, dass
die Rechengenauigkeit für Doubles durch OpenScreen herunter gesetzt wird. Auf Linux und MacOS/X kann
das wieder ganz anders sein, also ist es ein PureBasic-Bug.
Um das zu vermeiden, muß PureBasic auch nur ein Flag bei der DX9-Initialisierung von PB und OGRE hinzufügen,
und schon ist es erledigt. Oder ein Flag bei OpenScreen/OpenWindowedScreen auf Windows hinzufügen.

ts-soft hat geschrieben:Naja, aber wenn in der Hilfe auf jede solcher selten auftretenden Besonderheiten hingewiesen wird, wird diese sehr schnell
unübersichtlich und somit für Einsteiger unbrauchbar.

Sorry Thomas, aber das ist Quatsch! Die Hilfe hat solche Nebeneffekte, wenn schon vorhanden, zu erwähnen.
Wenn OpenScreen() die Genauigkeit von Fliesskommazahlberechnungen von Doubles auf Float reduziert, dann
ist das zu erwähnen... oder eben ein Bug.
Auf Linux und Mac passiert das bestimmt nicht, also kann man nich von einem "geilen Feature" sprechen, sondern
bei PureBasic mit einem Fehler in der Programmierung.
Die Programmierer von PureBasic oder OGRE haben ein wichtiges Flag für DirectX9 vergessen, ganz einfach.