spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

...Man stelle sich ein 3D-Szenario vor, in dem einige Asteroiden platziert werden sollen. Was spricht dagegen, eine Obergrenze für deren Anzahl festzulegen? Aus Performancegründen können sowieso nicht beliebig viele Objekte animiert und gerendert werden. Speicherverschwendung ist das auch nicht, wenn man davon ausgeht, dass zu irgendeinem Zeitpunkt die Obergrenze erreicht wird...

Aber das ist doch Blödsinn. Nur weil du einen anderen Typ nimmst, hast du noch lange keine Obergrenze. Wenn du dann ein weiteres Objekt dazupackst, hast du einen Überlauf, was vermutlich noch viel katastrophaler ist. Und wenn du eh eine Abfrage brauchst, ist der Datentyp wieder egal.

Hm, so meinte ich das nicht, ich war schon für eine Begrenzung. Ich wollte nur anmerken, dass diese nicht durch kleinere Variablentypen automatisch kommen. Letztendlich bin ich mir jetzt aber gar nicht mehr sicher, ob das überhaupt so vorgeschlagen worden ist Sry für die Verwirrung.

Zitat von »Jonathan_Klein«

Aber das ist doch Blödsinn. Nur weil du einen anderen Typ nimmst, hast du noch lange keine Obergrenze. Wenn du dann ein weiteres Objekt dazupackst, hast du einen Überlauf, was vermutlich noch viel katastrophaler ist. Und wenn du eh eine Abfrage brauchst, ist der Datentyp wieder egal.

Genau das hab ich vorhin auch gemeint, ist offenbar nicht ganz angekommen.

Zitat von »S4My«

Ich kann mir kaum vorstellen das hier alle Rechner haben welche nicht von 2000 Asteroiden mit ihren Grafiken und Flugbahnen in die Knie gezwungen würden.

Ich würde mal sagen, das hängt ganz stark davon ab, was genau so ein "Asteroid" sein soll.

Zitat von »S4My«

Unendliche Erweiterbarkeit ist zwar schön und gut, aber ich frage mich immer noch was daran so schwer zu verstehen ist das, besonders bei Spielen, das einfach Wunschdenken ist. Rechner können schlichtweg nicht immer weiter und mehr verarbeiten. Auch sie, so gut sie auch sein mögen, haben irgendwann ihren Punkt an dem sie nicht mehr können.

Das ist eh klar und niemand hat was anderes behauptet. Der Punkt ist, dass du durch die Wahl des Datentypen kein geeignetes Mittel hast um die Anzahl der Objekte zu beschränken. Du brauchst in jedem Fall eine Abfrage; ob dein Counter nun short oder int oder unsigned long long ist, kann daran nix ändern.

Zitat von »S4My«

Wenn ich dann noch dazu ein Spiel für die Allgemeinheit entwickeln möchte so kann ich nicht davon ausgehen, dass jeder PC ein High End-Modell ist.
Noch schlimmer ist es jedoch wenn man trotz des Wortes Grenze immer wieder von dazupacken spricht. Wo es aus sein soll gibt es kein "wenn aber dann". Ich für meinen Teil halte meine selbst gesteckten Grenzen was das Programm betrifft ein, sonst würden sie ja auch keinen Sinn ergeben. Große Spieletitel, um bei Spielen zu bleiben, haben auch Begrenzungen. "Morrowind" aus der "The Elder Scrolls"-Reihe hat so viel ich weiß eine Art Nebel implementiert, damit können kleine Spielareale größer wirken und so verhindert man einerseits das überlasten des Rechners und andererseits das endlose herumlaufen in der Spielwelt. Endlosigkeit ist zwar eine schöne Idee, jedoch schlichtweg nicht machbar, zumindest nicht so, dass dann auch wirklich alle noch Spaß ohne Framedrops haben können.

Wie gesagt, die Tatsache, dass Ressourcen endlich sind, hat nichts mit dem zu tun, worüber wir hier diskutieren. Zumindest seh ich nicht wirklich den Zusammenhang.

Weil das gerade in etwa zum Thema passt: https://community.rapid7.com/community/m…y-flaw-in-mysql

memcmp gibt einen int zurück. Manche Leute sind aber schlauer als die Doku und nehmen einen char zum Speichern des Rückgabewerts, weil sie gelesen haben, dass die Rückgabewerte immer -128 bis 127 sind. Tja. Außer manchmal halt. Hier in diesem Fall sorgt das halt dafür, dass auf bestimmten MySQL-Installationen zufällig jedes 256ste Passwort als richtig akzeptiert wird

Und die MySQL-Leute haben wahrscheinlich sogar eine gute Ausrede: die ersten Code-Zeilen davon stammen wahrscheinlich wirklich noch aus Zeiten, als es noch Vorteile brachte, mit einem Byte anstatt zweien oder vieren zu rechnen. Heute dagegen gibt es wirklich keine Ausrede mehr, das noch zu machen. Im Idealfall erkennt der Compiler den Kontext und erweitert selbsttätig auf 32bit- oder 64bit-Mathematik, oder er ist nicht schlau genug, den Fehler des Programmierers zu erkennen, und generiert zusätzlichen Code, um eine Schleife korrekt mit short anstatt int laufen zu lassen.

Nunja, falls das in diesem Thread nicht eh schon klar sein sollte: "Gefühlte Optimierungen" wie die Nutzung eines kleineren Datentypen für alltägliche Aufgaben sind nicht nur kontraproduktiv, sondern potentiell auch gefährlich. Damit ich aber nicht nur als nörgelnder Opa rüberkomme, versuche ich mich an was Produktivem:

Datentypen-Empfehlung *

size_t - wird in 32Bit-Exen ein unsigned int, ansonsten ein unsigned long long. Kann also nicht negativ werden. Ist zu nutzen für:
- Array-Indizes
- Größenrechnungen
- Element-Anzahlen
- Speicherallokationen
- praktisch immer, falls im Zweifel

uint32_t - aus stdint.h, eigene typedefs für solche grundlegenden Typen sind ebenso eine dumme Idee. Immer 32bit unsigned int, auch auf 64Bit-Systemen. Ist zu nutzen für:

- Hashes
- Datenübertragung an Festplatten oder Netzwerkpartner

int - 32Bit vorzeichenbehaftet. Ist zu nutzen für:

- diskrete (schrittweise) Koordinatenrechnungen, z.B. Adressierung der Zellen einer TileMap, weil man da für Bereichsrechnungen auch gern mal ins Negative kommt

short, unsigned short, char, unsigned char - 16bit und 8Bit, mit oder ohne Vorzeichen. Sind zu nutzen für:

- Datenübertragung an Festplatten oder Netzwerkpartner
- spezielle Datenstrukturen, die Abermillionen Mal auftreten und daher ohne solche Optimierungen nicht in den Speicher passen würden
- spezielle Datenstrukturen, die in großen Zahlen auftreten und Abermilliarden Mal pro Sekunde verarbeitet werden müssen - dort kann es sich nach Profiling erweisen, dass eine Reduzierung der Speicherbandbreite einen Gewinn darstellt

NACH PROFILING!

float - 32Bit-Fließkomma-Zahl. Ist zu nutzen für:

- alle Werte, die fließend über die Zeit hinweg geändert werden sollen - Bildschirmkoordinaten, 3D-Koordinaten, aber auch Lebenspunkte, Mana, usw.
- hat nur etwa 7 Stellen Genauigkeit, und zwar Vorkomma und Nachkomma zusammen.

double - 64Bit-Fließkomma-Zahl. Ist zu nutzen für:

- besonders große Absolutwerte, die aber trotzdem eine große Genauigkeit haben sollen
- besonders langsam verändernde Werte
- hat etwa 15 Stellen Genauigkeit - wiederum Vorkomma + Nachkomma zusammen.

Anekdote am Rande: Die Splitterwelten hatten mal das Problem, dass sich die Gesundheit gar nicht mehr regeneriert hat, wenn man vom Splitterrand in den leeren Himmel geschaut hatte und VSync aus war. Der Gesundheits-Wert war ein float und wurde jedes Frame ein bisschen erhöht. In diesem Fall einer besonders hohen Framerate waren das dann so viele winzige Teilschritte, dass die Genauigkeit eines floats nicht mehr ausreichte.

Ich hoffe, das hilft.


* alle Bitbreiten gelten für die gängigen Desktop-Systeme: Windows, Linux, Mac, und müssten auch Bestand für Konsolen (XBox, PS, Wii) sowie für aktuelle Mobilgeräte haben. Laut C-Standard sind diese Angaben aber nicht garantiert, exotische Systeme können davon abweichen.

Zitat von »Schrompf«

Weil das gerade in etwa zum Thema passt: https://community.rapid7.com/community/m…y-flaw-in-mysql

memcmp gibt einen int zurück. Manche Leute sind aber schlauer als die Doku und nehmen einen char zum Speichern des Rückgabewerts, weil sie gelesen haben, dass die Rückgabewerte immer -128 bis 127 sind.
(...)
Nunja, falls das in diesem Thread nicht eh schon klar sein sollte: "Gefühlte Optimierungen" wie die Nutzung eines kleineren Datentypen für alltägliche Aufgaben sind nicht nur kontraproduktiv, sondern potentiell auch gefährlich.

Einen Rückgabewert zu beschneiden ist natürlich potentiell gefährlich. Das hat aber an sich nichts mit der Wahl eines Datentyps an sich zu tun, sondern mit der Konvertierung.

Zu Deiner Anekdote: Aus diesem Grund halte ich inkrementelle Verfahren ebenfalls für potentiell gefährlich. Sie sind numerisch nicht stabil. Wenn sie sich vermeiden lassen, sollte man es tun - aber ja, das bedarf eventuell mehr Aufwand.

Zitat von »BlueCobold«

Einen Rückgabewert zu beschneiden ist natürlich potentiell gefährlich. Das hat aber an sich nichts mit der Wahl eines Datentyps an sich zu tun, sondern mit der Konvertierung.

Das stimmt, aber ich empfand die Geschichte im Ganzen als exemplarisch für die Diskussion in diesem Thread. Der MySQL-Bug begründete sich ja darin, dass eigentlich ein int zurückgegeben wird, aber ein Programmierer mit "Kontextwissen" der Meinung war, dass da für immer und ewig ein char ausreicht. Und das noch dazu an einer Stelle, die wahrscheinlich schon damals keine solche "Optimierung" nötig hatte... immerhin reden wir hier von der Authentifizierung, die bestenfalls einmalig bei Erstellen der Verbindung passiert.

Zitat

Zu Deiner Anekdote: Aus diesem Grund halte ich inkrementelle Verfahren ebenfalls für potentiell gefährlich. Sie sind numerisch nicht stabil. Wenn sie sich vermeiden lassen, sollte man es tun - aber ja, das bedarf eventuell mehr Aufwand.

Wir rechnen inzwischen nur noch halbsekündlich - da muss man dann halt den Zeitpunkt des nächsten Auftretens mitspeichern, aber dafür ist die Rechnung stabil und unabhängig von der Bildrate. Aber ich halte es nicht für "gefährlich" im gleichen Sinne wie die anderen "gefährlichen" Punkte, die ich hier im Thread genannt habe. Das Schlimmste, was hier passieren kann, ist dass nach einer Weile der tatsächliche Gesundheitswert vom erwarteten Gesundheitswert abweicht. Das ist doch eine subtil andere Gefahr als ein Absturz oder Variablen-Überlauf mit potentiell unbegrenzten Logik-Folgefehlern.

Solange es nicht dazu führt, dass jemand mit 0 HP unsterblich rumläuft, ist das kein Problem (Dieses Problem hatten bisher übrigens sowohl Lineage 2, als auch WoW und Diablo 3 ) Halb-sekündlich klingt übrigens sehr vernünftig.