MM-MatzEdit
Worklogs
MM-MatzEdit Kommentare
will hier keine diskusion anfachen, aber um das zu komplettieren muss ich nochmal darauf hinweisen, das die terrainfunktionen in all diesen gescheiterten projekten einwandfrei funktionierten und dann eher bei anderen (waren ja meist cooperationen) die probleme zu finden waren.
ein tadelloses beispiel für ein komplettes spiel zeigte matthias z.b. mit speedboat.
zustimmen kann ich dir bladerunner, dass bei den gescheiterten projeken die ziele zu hoch gesteckt waren und dies wahrscheinlich der grund des scheiterns war.
mir gefiel auch nie der "einheitslook" all dieser projekte, aber dieser entstand ja dadurch, das die terrains, die der funktionierende teil waren, alle von matthias kamen.
da kann man doch wohl nix mehr gegen sagen, terrains waren immer top.
und ein editor mit veränderbaren texturen etc. verhindert dann auch diesen "einheitslook"
also sollte man sowas nicht voreilig verurteilen.
ich freue mich drauf
Zitat:
Er hat sich eigentlich immer auf die Karte konzentriert, denn wesentlich mehr hatte noch kein Projekt von ihm zu bieten. Ich binhalt der Meinung er sollte vielleicht mal einen anderen Web bestreiten. Und vor allem Abschied von diesem Gigantismus nehmen. Immer geht es um riesige (online-)Welten. Das kann nur in die Hose gehen.
naja bisher scheiterten die projekte ja nicht an der karte, sondern an der spielmechanik!
jetzt konzentriert er sich auf die karte. also bin ich zumindest zuversichtlich.
zum thema speicher vs rechenleistung denke ich ebenfalls das diesmal ein besserer schritt in richtung weniger sinnlose speicherbelegung gemacht wird. für modelle eines spiels muss ja noch platz bleiben und bei casual gamern muss man auch nicht immer von 512+ ram ausgehen. fps technisch muss natürlich auch bedacht werden das rechenpower dann auch entsprechend kleiner ist meistens. also sollte da ein guter mittelwert gefunden werden. ich denke im vergleich zum reinen lod system (wo ich auch noch kein wirklich aureichedes für meshterrains in b3d gesehen hab) ist dies aber schon der richtige weg.
viel erfolg beim weiteren coden.
Naja,...
Freitag, 3. Oktober 2008 um 15:36 Uhr von BladeRunner
... mir stellt sich die Frage wieviele 3D-Editoren und Spielereien gleicher Machart Du noch machen willst?
Du hattest Oil War - zu groß, eingestellt. Dann dieses Megaprojektedingsi, bei dem 'das wichtigste natürlich die Karte ist' - man hört nix mehr davon. Dein Contestspiel war ein Terrain mit 2 Helikoptern. Und nun den hier, der ja auch wieder für Karten von epochaler Tiefe angelegt ist. Wie lang wirst Du daran sitzen um es dann fallen zu lassen?
Ich sagte es Dir schon im Forum mehrfach und (auch wenn Du es wohl nicht wissen willst) wiederhole mich nochmal:
Denk kleiner, und konzentriere Dich auf die Spielmechanik, sonst wird jedes deiner Projekte im selben Stadium versumpfen.
Nun, das macht insofern Sinn, als dass du Arbeitsspeicher sparst für die Meshes.
Jedoch musst du auch sehen, dass ein solches Tile vergleichsweise wenig Speicher frisst, zumal heutzutage von einem Arbeitsspeichervolumen >512 MB ausgegangen werden kann.
Vergleichsweise dazu steht dein Algorithmus, der ständig nicht sichtbare Meshes entfernt und On-the-fly neue erstellt - überleg dir mal, wieviel Rechenzeit das frisst, wenn man bedenkt, dass DX7 nicht für solche Vertexoperationen gedacht ist.
Ich würde dir empfehlen, das ganze darauf zu beschränken, die Meshes am Anfang zu erstellen und dann je nach Entfernung mit LOD zu arbeiten (indem du die verschieden detaillierten Meshes ein- und ausblendest).
Ist natürlich deine Entscheidung, aber man sollte immer ein Auge auf die CPU - Auslastung werfen.
Na gut ich gehe mal etwas daruf ein. Vieleicht wäre es auch eine Idee für andere die ähnliches vor haben.
Nehmen wir an die Camera steht auf position 0,0,0 und hat eine CameraRange von 1000. Also sind alle Tiles sichtbar die im Bereiche -1000x bis +1000x und -1000z bis +1000z liegen. Wenn nun das Terrain um zb das 10fache gedeht ist wären es 7x7 Tiles da ein Tiles 16x16 Einheiten groß ist.
Letzendlich sinds also 49 Tiles (Entitys).
Wenn nun Tiles aus dem sichtbereich verschwinden weil mann die Camera bewegt werden diese als unsichtbar makiert.
Wenn nun allerdings neue Tiles in den Sichtbereich gelangen wird einfach nur nach ein unsichtbares Tiles gesucht und dieses an die neue Position gesetzt und mit neuen Höhendaten und Textur gefüttert.
Die Wassegrundfläche die sich wiederholt besteht aus 4x4 Tiles und frist somit einmalig (64*64*4B+16*16*2B)*4 =67KB.
Und das ist soooo wenig das es für mich nichts ist.
"Das besondere ist nun das die MeshTiles nicht als Entitys bereit liegen sondernt
in Echtzeit erstellt werden, aus Daten die in Banken liegen."
Wie meinst du das?
Wenn du sie erstellst, werden sie ja automatisch zu Entities, daher verstehe ich den Sinn dieser Aussage nicht ganz.
Ausserdem, was meinst du damit, dass das Wasser keinen Speicher frisst?
Solange du Wasser hast, muss es ja irgendwie RAM & VRAM verbrauchen, da man sonst ja nix davon sehen würde.
Ansonsten hört sich das ganze vielversprechend an, auch wenn man auf dem Screen noch nicht viel sieht.
perfekt
Donnerstag, 2. Oktober 2008 um 19:58 Uhr von biggicekey
endlich das was du am besten kannst und genau das was ich gerade brauche! also halte dich ran. als beta tester stehe ich dir mit meinem langsamen system wie im icq schonmal bequatscht immer gern zur verfügung.
bis denne