Kurze frage zu einem Spielprogramier problem

[bingo88]

Die wachsende Diskrepanz zwischen CPU- und Speichergeschwindigkeit ("Memory Wall") ist in der Tat ein Problem. Man muss halt versuchen, die Speicherzugriffe so gut wie möglich zu verstecken, ganz vermeiden kann man sie ja nicht. Zumal du bei Spielen noch mit dem Problem zu kämpfen hast, dass du oft nicht alle notwendigen Daten vor dem Spielstart in den Speicher bekommst (kein Platz) und du den Kram zwischenzeitlich von Platte laden musst. Bei Half-Life 1 gab es ja auch diese schönen Loadings zwischendurch Bei Konsolen sieht das zum Teil noch viel schlimmer aus, da du deine Daten oft noch von einem optischen Datenträger beziehst. Wie sehr man damit zu kämpfen hat, hängt aber vom Spiel ab. Open World Titel haben damit ein echtes Problem, Spiele wie Sidescroller oder Point-and-Click Adventures eher weniger.

 

[Supercomputer]

Je mehr Daten da sind, desto schwieriger wird es.

 

[bingo88]

Kann man im Prinzip so sagen, ja. Ist halt auch eine Herausforderung, das macht das meiner Meinung nach auch so interessant.

 

[Supercomputer]

Der einzige wirklich schnelle Speicher ist der L1 Cache
Danach wird es wirklich langsam.

So wird man gezwungen mit möglichst kleinen Daten möglichst viel zu machen, das ist die Herausforderung und der Grund warum mache Menschen programmieren,

 

[bingo88]

Der einzige wirklich schnelle Speicher ist der L1 Cache
Danach wird es wirklich immer langsamer.

So würde ich das ausdrücken ^^ Selbst der L3 Cache kann noch was rausholen.

So wird man gezwungen mit möglichst kleinen Daten möglichst viel zu machen (...)

Sofern die Problemstellung das zulässt, ist das durchaus sinnvoll.

 

[Supercomputer]

Ok, der Vorteil vom L3 Cache ist halt, dass die Kerne sich den teilen.

 

[Gary94]

Der einzige wirklich schnelle Speicher ist der L1 Cache

Da kommen aber vorher noch die Register der einzelnen Kerne.

 

[Supercomputer]

Die Register halten doch nur die aktuellen Befehlen

 

[bingo88]

Nein, das stimmt so nicht. Es gibt verschiedene Register, die unterschiedliche Aufgaben übernehmen. Einige enthalten Daten, andere Befehle, andere Statusinformationen (Flags, Speicheradressen, etc.).

 

[Supercomputer]

Oh, ok

 

[Supercomputer]

Mittlerweile bin ich beim Konstruieren der Objekte, jedoch kommt mir da eine Frage, wie viele Punkte sollten für einen Kreis/ eine Kugel berechnet werden?
Also wie groß sollte das Raster sein?

 

[Bunny_Joe]

Du musst erstmal entscheiden welche Art von Raster du verwenden willst. Hat nen großen Einfluss auf die Polygonzahl.
https://dl.dropboxusercontent.com/u/448525/keep/Polycount/spheres_and_polycounts.png

Dann kannst du ggf. noch Optimierungen vornehmen.
http://i42.photobucket.com/albums/e305/muzzoid/optimisation.png

 

[Supercomputer]

Ja, darüber habe ich mir auch schon Gedanken gemacht, je kleiner das Raster, desto runder ist die Kugel und um so genauer sind Kollisionsberechnungen, jedoch braucht dies auch wieder mehr Rechenleistung.

 

[Supercomputer]

Ich werde als Raster ein symmetrisches Raster nutzen. Also alle Punkte sind von den umgebenen Punkten gleich weit entfernt.
Nun habe ich jedoch noch eine Frage an euch. Welche Form würdet ihr bevorzugen?

1. setroomheight(long double lenght) // Hiermit werden die Längen definiert
   setroombasicform(bool circle, bool square, bool rectangle, bool sphere, bool cube, bool cuboid) // Mit dieser Funktion wird der Raum erstellt

2. setroomheight(long double lenght) // Hiermit werden die Längen definiert
   setroombaiscform(int id) // Mit der id wird dann der Raum initialisiert

3. setroomascicle(long double widht, long double height) // Cicle kann auch eine Ellipse werden, daher sind 2 Längenangaben möglich, bleibt eine jedoch werden sie automatisch gleich gesetzt

Bei den Funktionen, die eine bestimmte Eigenschaft vor geben z.B. "height" oder "cicle" werden dementsprechend für jede Eigenschaft geschrieben.

Oder hättet ihr eine andere/bessere Idee?

 

[Magogan]

Length, nicht lenght

Die Kollisionserkennungen bei einer Kugel solltest du lieber anhand des Abstandes zum Mittelpunkt machen anstatt anhand des Modelles. Das verringert den Rechenaufwand enorm.

Ich würde eine einzige Funktion zum Initialisieren des Raumes benutzen. Ggf. auch überladen, da du bei einer Kugel ja nur Mittelpunkt und Radius brauchst, bei einem Zylinder aber mindestens 2 Punkte und einen Radius. Vielleicht doch wirklich pro Typ eine eigene Funktion, ist wahrscheinlich sinnvoller. Je nachdem, was einfacher für dich ist.

 

[Supercomputer]

Length, nicht lenght

Schande über mein Haupt


Mir ist es recht egal, welche Variante ich nehme das, was von den Usern am liebsten verwendet wird.

 

[Supercomputer]

Nach der "Sommerpause" bin ich nun mal wieder zum Programmieren gekommen und kann an jeden der an größeren Projekten arbeitet nur sagen, kommentiert alles, schreibt Romane sonnst kommt ihr nicht mehr zurecht.

 

[Bunny_Joe]

Nach der "Sommerpause" bin ich nun mal wieder zum Programmieren gekommen und kann an jeden der an größeren Projekten arbeitet nur sagen, kommentiert alles, schreibt Romane sonnst kommt ihr nicht mehr zurecht.

Da hats wohl jemand auf die harte Tour gelernt?

 

[Magogan]

Sinnvolle Variablennamen etc. sind aber auch nicht schlecht, wenn man später den Code verstehen will. Ich verstehe auch ohne viele Kommentare, was mein Programm macht, allerdings weiß ich nicht, wie das nach ein paar Monaten Pause aussieht. Das meiste ist aber logisch und nachvollziehbar benannt, also sollte ich keine größeren Probleme haben.

 

[Supercomputer]

Ich kann doch auch ganz einfach, aus jeder Form eine eigenen Klasse machen, oder?

aktuell frage ich nur z.B.

set_as_cube(bool SET);

und mit SET wird dann bool is_cube gesetzt; (Standard ist es false)

ich könnte doch auch einfach eine Klasse mit is_cube anlegen und dann nur die dafür gebrauchten Operationen zur Verfügung stellen, oder liege ich da falsch?