theorie und praxis...
Übersicht
BlitzBasic Blitz3D
onkelz89Betreff: theorie und praxis... |
 Mi, Mai 04, 2005 22:34Antworten mit Zitat 
|
|
|---|---|---|
|
hi
ich plane ein großes game(planung zu 85% fertig) ich will noch nicht groß von erzählen... nur tatsachen: also es müssen mehrere 1000 schätzungsweise immer so zwischen 8.000 und 20.000 objekten auf der spielfläche sein... die objekte sind nicht gerade weit auseinander. minimale distance 1 (dicht an dicht) maximale " 100(wenn mal zB. ein parkplatz ohen autos kommt) schafft das blitz? oder wird die berechnung bei 30fps ruckeln? achja game soll in 800x600 laufen(erstmal) objektdaten: kleine objekte haben nur 8points (zB cube) große objekte können schon über 25000 points haben... pc: AMD-Athlon 512ddr-ram 1.7 Ghz |
||
Dreamora |
Mi, Mai 04, 2005 22:42 Antworten mit Zitat
|
|
|---|---|---|
|
Wenn du es sinnvoll strukturierst, dann schon.
Die meisten der Objekte werden ja nicht gleichzeitig auf dem Bildschirm sein. Das hängt jedoch sehr von deinem Können ab. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
onkelz89 |
Mi, Mai 04, 2005 23:16 Antworten mit Zitat
|
|
|---|---|---|
|
ne schon klar sehen wird man halt meistens die wände von den häusern... oder autos/menschen aber keine 1000 auf einmal
mir ist eben noch ne idee gekommen: die objekte sind alle per type gesteuert... es gibt ein field rang rang gibts von 1(wichtig) bis 3(unwichtig) wenn rang=1 dann wird das objekt nie gelöscht wenn rang=2 dann wird das objekt nur bei einer weiten entfernung(spieler-objekt) gelöscht wenn rang=3 dann schon nach einer kurzen und immer in dem bereich wo man sich aufhält ist drum herum ein radius wo ständig neues geladen wird aber nie zuviel auf einmal... und altes (momentan)unbrauchbares wird gelöscht und später beibenutzung neu erstellt... das würde doch viel weniger ram verbrauchen oder??? |
||
|
skey-z |
Do, Mai 05, 2005 1:11 Antworten mit Zitat
|
|---|---|---|
|
jep, dass schonmal ein guter anfang, wenn du nur die "sichtbaren/nahen" objekte darstellst.
eine weiter optimierung wäre nur die sichtbaren polygone darzustellen. und am besten erst mal coden, dabei schon an optimierung denken und wenn es danach nicht flüßig laufen sollte, weiter optimieren. |
||
|
Awards:
Coffee's Monatswettbewerb Feb. 08: 1. Platz BAC#57: 2. Platz |
||
Dreamora |
Do, Mai 05, 2005 2:09 Antworten mit Zitat
|
|
|---|---|---|
|
Schlechte Variante mit dem Optimieren während dem grundlegenden Coden.
Erst Coden und wenn alles läuft, optimieren und schauen, was etwas bringt und was nicht und entsprechend Optimierungen einbauen oder verwerfen. ansonsten baut man viele optimierungen ein, die man später nimmer raus nehmen kann und die vielleicht sogar mehr performance kosten, als nötig wäre. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
|
|
skey-z |
Do, Mai 05, 2005 2:17 Antworten mit Zitat
|
|---|---|---|
| ich meinte auch, keine nicht, dass man sein hauptaugenmerk auf die optimierung setzten soll, während des codens, aber man kann ja darauf achten, überflüssige oder intensive rechnungen etc zu vermeiden. | ||
|
Awards:
Coffee's Monatswettbewerb Feb. 08: 1. Platz BAC#57: 2. Platz |
||
|
Vertex |
Do, Mai 05, 2005 11:22 Antworten mit Zitat
|
|---|---|---|
|
Die Frage ist, was du mit den Objekten machst. Mehrere Entitys -> Lahm. Mehr Objekte in einem Surface untergrebracht -> Schnell. Wobei nur Objekte in einem Surface untergebracht werden können, die a) statisch sind, und b) nur eine und die selbe Textur(besser gesagt Brush) besitzen.
Bei Bäumen oder Gras ist soetwas immer vorteilhaft. Stichwort LOD bei der Flächenverteilung von Meshs, die nur zum Hintergrund gehören. mfg olli |
||
| vertex.dreamfall.at | GitHub | ||
Übersicht
BlitzBasic Blitz3D
Powered by phpBB © 2001 - 2006, phpBB Group