Landschaften ala Gothic

Übersicht

BlitzBasic

Blitz3D

Gehe zu Seite Zurück 1, 2, 3, 4 Weiter

	NightPhoenix	Mi, Jan 17, 2007 21:18 Antworten mit Zitat
Ach, du auch haben ge-x-ter Kasten? Also hab Halo2 jetz vor paar Tagen erst wiedermal gespielt! Mir ist folgendes dazu aufgefallen: 1. Vor jedem Level Laden, bzw. eher Level erweitern (neues laden, altes löschen) durchquert man irgendwelche Tunnel oder Gänge Es gibt dabei keinen Ladebildschirm 2. Mitten im Gang gibt es eine Stelle an der man deutlich ein knattern der X.Box Konsole hört (Rechnen/Festplattenzugriff) und das spiel für 1-2 Sekunden ruckelt. 3. Alle "Videos" in Halo2 sind Echtzeitberechnet. Jedesmal wenn ihm Video die Kamera große Distanzen zurücklegt kann man diese Ladezeiten nicht nur an bissl ruckeln sehen, sondern auch an den Texturen. In den ersten 2-3 Sekunden sind die Texturen dann nur sehr sehr wenig detailliert (fällt auf jeden Fall ziemlich auf). Schritt für Schritt werden die detaillierten Texturen dann auf die Objekte gelegt... es ruckelt zwar, das Spiel an sich bleib aber nicht stehen. Beim durchlaufen eines levels bekommt man dabei nicht die Gelegenheit diese Txturenumstellung mit zu erleben, da man dafür einfach zu langsam ist, denn das neue Level wird früher geladen, als man es überhaupt zu Gesicht bekommt! MfG.

NightPhoenix

Mi, Jan 17, 2007 21:18
Antworten mit Zitat

Ach, du auch haben ge-x-ter Kasten? Laughing

Also hab Halo2 jetz vor paar Tagen erst wiedermal gespielt!

Mir ist folgendes dazu aufgefallen:

1.
Vor jedem Level Laden, bzw. eher Level erweitern (neues laden, altes löschen) durchquert man irgendwelche Tunnel oder Gänge
Es gibt dabei keinen Ladebildschirm

2.
Mitten im Gang gibt es eine Stelle an der man deutlich ein knattern der X.Box Konsole hört (Rechnen/Festplattenzugriff) und das spiel für 1-2 Sekunden ruckelt.

3.
Alle "Videos" in Halo2 sind Echtzeitberechnet. Jedesmal wenn ihm Video die Kamera große Distanzen zurücklegt kann man diese Ladezeiten nicht nur an bissl ruckeln sehen, sondern auch an den Texturen. In den ersten 2-3 Sekunden sind die Texturen dann nur sehr sehr wenig detailliert (fällt auf jeden Fall ziemlich auf). Schritt für Schritt werden die detaillierten Texturen dann auf die Objekte gelegt... es ruckelt zwar, das Spiel an sich bleib aber nicht stehen. Beim durchlaufen eines levels bekommt man dabei nicht die Gelegenheit diese Txturenumstellung mit zu erleben, da man dafür einfach zu langsam ist, denn das neue Level wird früher geladen, als man es überhaupt zu Gesicht bekommt!

MfG.

	BIG BUG	Mi, Jan 17, 2007 21:55 Antworten mit Zitat
Also ich persönlich kann das überhaupt nicht haben, wenn während dem Spiel noch etwas nachgeladen wird. Da habe ich lieber "richtige" Ladebildschirme und dann meine Ruh...
B3D-Exporter für Cinema4D!(V1.4) MD2-Exporter für Cinema4D!(final)

BIG BUG

Mi, Jan 17, 2007 21:55
Antworten mit Zitat

Also ich persönlich kann das überhaupt nicht haben, wenn während dem Spiel noch etwas nachgeladen wird. Da habe ich lieber "richtige" Ladebildschirme und dann meine Ruh...

B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)

	NightPhoenix	Mi, Jan 17, 2007 22:07 Antworten mit Zitat
du wartest also lieber 10 Sekunden, als 2-4 Sekunden mit bissl geruckel zu spielen? 2-4 Sekunden isn Klacks, selbst dann kann man sich ungehindert bewegen, bloß die FPS sinkt halt in der Zeit auf 15 ab... das ist wohl verträglicher als ein hässlicher Ladebilschirm stell dir mal vor in Gothic 2 käme aller 100 Meter ein Ladebildschirm omg! ne danke

NightPhoenix

Mi, Jan 17, 2007 22:07
Antworten mit Zitat

du wartest also lieber 10 Sekunden, als 2-4 Sekunden mit bissl geruckel zu spielen?
2-4 Sekunden isn Klacks, selbst dann kann man sich ungehindert bewegen, bloß die FPS sinkt halt in der Zeit auf 15 ab... das ist wohl verträglicher als ein hässlicher Ladebilschirm Rolling Eyes

stell dir mal vor in Gothic 2 käme aller 100 Meter ein Ladebildschirm Very Happy

omg! ne danke

	FWeinb ehemals "ich"	Mi, Jan 17, 2007 22:29 Antworten mit Zitat
Also ich finde es auch besser wenn am anfang des Spiels alle daten geladen sind das doch nevieg wenn jede 100m das spiel ruckelt und dann wider normal ist also dann lieber 20 sec warten und ein füssiges spiel spielen also dauert zu warten das das mit dem ruckeln entlich aufhört
"Wenn die Menschen nur über das sprächen, was sie begreifen, dann würde es sehr still auf der Welt sein." Albert Einstein (1879-1955) "If you live each day as if it was your last, someday you'll most certainly be right." Steve Jobs

FWeinb

ehemals "ich"

Mi, Jan 17, 2007 22:29
Antworten mit Zitat

Also ich finde es auch besser wenn am anfang des Spiels alle daten geladen sind das doch nevieg wenn jede 100m das spiel ruckelt und dann wider normal ist also dann lieber 20 sec warten und ein füssiges spiel spielen also dauert zu warten das das mit dem ruckeln entlich aufhört

"Wenn die Menschen nur über das sprächen, was sie begreifen, dann würde es sehr still auf der Welt sein." Albert Einstein (1879-1955)
"If you live each day as if it was your last, someday you'll most certainly be right." Steve Jobs

	NightPhoenix	Mi, Jan 17, 2007 22:33 Antworten mit Zitat
aller 100 meter ist übertrieben.... in halo entsprich das aller 10-20 Minuten wird ein neuer Lvelabschnittgeladen... das ruckelt kurz... und dann hat man für 10-20 Minuten Ruhe. Vice City hat auch in etwa sowas, bloß da kommt eine Lade-Einblendung wenn mans so will, wenn man über die Brücke fährt, ruckelt kurz und gut Das nervt und behindert keinen @Ich Das Problem in diesem Thread ist ja, dass wir so viele MB Speichern müssen, dass dies der VRAM nicht alles auf einmal speichern kann. Die meiste Ladezeit kommt bei höher Entwickelten Spielen sowiso durch Physik, x-echtzeit berechnungen, usw. zustande, weniger durch Texturen/Objekte MfG.

NightPhoenix

Mi, Jan 17, 2007 22:33
Antworten mit Zitat

aller 100 meter ist übertrieben.... in halo entsprich das aller 10-20 Minuten wird ein neuer Lvelabschnittgeladen... das ruckelt kurz... und dann hat man für 10-20 Minuten Ruhe. Vice City hat auch in etwa sowas, bloß da kommt eine Lade-Einblendung wenn mans so will, wenn man über die Brücke fährt, ruckelt kurz und gut

Das nervt und behindert keinen

@Ich
Das Problem in diesem Thread ist ja, dass wir so viele MB Speichern müssen, dass dies der VRAM nicht alles auf einmal speichern kann. Die meiste Ladezeit kommt bei höher Entwickelten Spielen sowiso durch Physik, x-echtzeit berechnungen, usw. zustande, weniger durch Texturen/Objekte

MfG.

	skey-z	Mi, Jan 17, 2007 23:31 Antworten mit Zitat
Physik und Echtzeitberechnung haben weniger mit der Ladezeit zu tun, da wie der Name es schon sagt, es in echtzeit, also während des Spiels passiert, dies wirkt sich lediglich auf die FPS, den die dafür benötigten Dateien sind größtenteils viel kleiner als Objekte und Texturen und werden einmal am Anfang des Spiels eingelesen, eingebunden oder geladen und gut ist, und diese Berechnugen werden auc hgrößtenteils durch die CPU berechnet und haben relativ wenig mit dem VRam zu tun. Lediglich die Shader und die Darstellung werden über die GraKa berechnet und ziehen somit an dieser Performance. Die Methode wie geladen wird hängt auch immer vom Spiel ab, bei Spielen wie Gothic, Wow und so, wo man sich wirklich in einer großen Welt bewegt, und auch mit anderen Charakteren Komunizieren kann, wäre es sehr schlecht, wenn man immer wieder im Ladebildschirm hängt und nicht machen kann. Bei Spielen die Levelbasierend sind ist der Ladebildschirm sehr oft notwendig, da man weiß, man hat diesen Abschnitt geschafft und in dieser Zeit kann man sich mal entspannen, auf Toilette gehen oder sonst was machen ohne gefahr zu laufen, nach dem Laden "Game Over" zu sein.
Awards: Coffee's Monatswettbewerb Feb. 08: 1. Platz BAC#57: 2. Platz Twitter

skey-z

Mi, Jan 17, 2007 23:31
Antworten mit Zitat

Physik und Echtzeitberechnung haben weniger mit der Ladezeit zu tun, da wie der Name es schon sagt, es in echtzeit, also während des Spiels passiert, dies wirkt sich lediglich auf die FPS, den die dafür benötigten Dateien sind größtenteils viel kleiner als Objekte und Texturen und werden einmal am Anfang des Spiels eingelesen, eingebunden oder geladen und gut ist, und diese Berechnugen werden auc hgrößtenteils durch die CPU berechnet und haben relativ wenig mit dem VRam zu tun.
Lediglich die Shader und die Darstellung werden über die GraKa berechnet und ziehen somit an dieser Performance.

Die Methode wie geladen wird hängt auch immer vom Spiel ab, bei Spielen wie Gothic, Wow und so, wo man sich wirklich in einer großen Welt bewegt, und auch mit anderen Charakteren Komunizieren kann, wäre es sehr schlecht, wenn man immer wieder im Ladebildschirm hängt und nicht machen kann.
Bei Spielen die Levelbasierend sind ist der Ladebildschirm sehr oft notwendig, da man weiß, man hat diesen Abschnitt geschafft und in dieser Zeit kann man sich mal entspannen, auf Toilette gehen oder sonst was machen ohne gefahr zu laufen, nach dem Laden "Game Over" zu sein.

Awards:
Coffee's Monatswettbewerb Feb. 08: 1. Platz
BAC#57: 2. Platz
Twitter

	Omenaton_2	Do, Jan 18, 2007 11:28 Antworten mit Zitat
Ich würde an deiner Stelle gar nicht mit Echtzeitnachladen arbeiten versuchen. Gestalte die Welt lieber so, wie man das früher auhc bei fast allen 3D Spielen gemacht hatte: Du hast mehr oder weniger "Sektoren", inder immer ein bestimmter Satz von Objekten und dazugehörigen Texturen, Boden inbegriffen enthalten ist. Das wird am Anfang geladen. Es darf aber nicht zu viel sein. Du mußt sehr genau überlegen, wieviele Polygone du maximal haben kannst, wie Viele Texturen geladen sein dürfen und dann danach geschickt diese Resourcen zwischen Boden, Himmel, Spielercharachtere, NPCs und Naturelementen wie Bäume, Steine aber auch Gebäude verteilen kannst. Dann editierst du einen Sektor nur mit diesen Elementen. Wenn man das geschickt macht, sieht das gut genug aus. Die Welt muß dann geschickt so aufgeteilt werden, daß zeimlich unauffällig, natürlich wirkend, Engstellen gibt, Übergänge, wo man in einen anderen Sektor wechseln kann, mit ganz andern Satz von Daten, da wird dann alles Alte gelöscht und der neue Satz nachgeladen. Zum Beispiel so: Sektor 1 ist ein weitläufiger Tal mit Hügeln und Burgruinen. Wenn man in eine der Ruinen hineingeht, findet man einen sehr dunklen Tunneleingang. Man öffnet da eine Tür und es wird kurz sehr dunkel oder das Bild der sich öffnenden Tür bleibt dargestellt (man hört ein ächzendes Geräsuch als ob man die Tür nur schwer nd langsam öffnen könnte, man müßte einen rostigen Schläßel undrehen) und in dieser Zeit wird schnell in paar Sekunden das nötige neue Grafik geladen. Dann geht man durch ein Tunnel und kommt auf der anderen Ende raus, wo ein Wald liegt. So würde ich es machen.

Omenaton_2

Do, Jan 18, 2007 11:28
Antworten mit Zitat

Ich würde an deiner Stelle gar nicht mit Echtzeitnachladen arbeiten versuchen.
Gestalte die Welt lieber so, wie man das früher auhc bei fast allen 3D Spielen gemacht hatte:
Du hast mehr oder weniger "Sektoren", inder immer ein bestimmter Satz von Objekten und dazugehörigen Texturen, Boden inbegriffen enthalten ist. Das wird am Anfang geladen. Es darf aber nicht zu viel sein.
Du mußt sehr genau überlegen, wieviele Polygone du maximal haben kannst, wie Viele Texturen geladen sein dürfen und dann danach geschickt diese Resourcen zwischen Boden, Himmel, Spielercharachtere, NPCs und Naturelementen wie Bäume, Steine aber auch Gebäude verteilen kannst.
Dann editierst du einen Sektor nur mit diesen Elementen. Wenn man das geschickt macht, sieht das gut genug aus.
Die Welt muß dann geschickt so aufgeteilt werden, daß zeimlich unauffällig, natürlich wirkend, Engstellen gibt, Übergänge, wo man in einen anderen Sektor wechseln kann, mit ganz andern Satz von Daten, da wird dann alles Alte gelöscht und der neue Satz nachgeladen. Zum Beispiel so:
Sektor 1 ist ein weitläufiger Tal mit Hügeln und Burgruinen.
Wenn man in eine der Ruinen hineingeht, findet man einen sehr dunklen Tunneleingang. Man öffnet da eine Tür und es wird kurz sehr dunkel oder das Bild der sich öffnenden Tür bleibt dargestellt (man hört ein ächzendes Geräsuch als ob man die Tür nur schwer nd langsam öffnen könnte, man müßte einen rostigen Schläßel undrehen) und in dieser Zeit wird schnell in paar Sekunden das nötige neue Grafik geladen. Dann geht man durch ein Tunnel und kommt auf der anderen Ende raus, wo ein Wald liegt.
So würde ich es machen.

	flashmaxel	Do, Jan 18, 2007 14:28 Antworten mit Zitat
Zitat: Sie haben es so gemacht wie alle: Threaded loading. Das geht in Blitz nicht, du kannst nur in einem Thread arbeiten und deswegen nicht im hintergrund laden. Gibt es nicht vieleicht doch eine Möglichkeit - ich stell mir das so vor: 1. Funktion in einer Dll aufrufen, die einen Thread startet, so fährt schonmal das BB programm fort. 2. In dem Thread das Bild laden und per api RtlMoveMemory in den BB ImageBuffer kopieren. Ich bin auf die Idee gekommen weil ich das hier gesehen habe: http://www.blitzbasic.com/Comm...opic=30480 . Allerdings weiß ich nicht ob die Dll überhaupt auf den BB Speicherbereich zugreifen kann (müsste doch eigentlich gehen CheatEngine z.B. macht das ja )? Zudem kenn ich mich da noch sehr schlecht aus, deswegen: Glaubt ihr das könnte so in der Art funktionieren ?
Real C programmers never die; they cast to void.

flashmaxel

Do, Jan 18, 2007 14:28
Antworten mit Zitat

Zitat:

Sie haben es so gemacht wie alle: Threaded loading. Das geht in Blitz nicht, du kannst nur in einem Thread arbeiten und deswegen nicht im hintergrund laden.

Gibt es nicht vieleicht doch eine Möglichkeit - ich stell mir das so vor:

1. Funktion in einer Dll aufrufen, die einen Thread startet, so fährt schonmal das BB programm fort.
2. In dem Thread das Bild laden und per api RtlMoveMemory in den BB ImageBuffer kopieren.

Ich bin auf die Idee gekommen weil ich das hier gesehen habe: http://www.blitzbasic.com/Comm...opic=30480 . Allerdings weiß ich nicht ob die Dll überhaupt auf den BB Speicherbereich zugreifen kann (müsste doch eigentlich gehen CheatEngine z.B. macht das ja )?
Zudem kenn ich mich da noch sehr schlecht aus, deswegen:
Glaubt ihr das könnte so in der Art funktionieren ?

Real C programmers never die; they cast to void.

	coldie	Fr, Jan 19, 2007 16:03 Antworten mit Zitat
Wenn man weis wie die zu ladende Datei aufgebaut ist, kann man sie doch einfach in mehreren Schritten in eine Bank laden. Für 70kb braucht mein Rechner so um die 10 millisecs (inklusive öffnen und schließen der Datei).

coldie

Fr, Jan 19, 2007 16:03
Antworten mit Zitat

Wenn man weis wie die zu ladende Datei aufgebaut ist, kann man sie doch einfach in mehreren Schritten in eine Bank laden. Für 70kb braucht mein Rechner so um die 10 millisecs (inklusive öffnen und schließen der Datei).

	NightPhoenix	Fr, Jan 19, 2007 16:50 Antworten mit Zitat
quasi externe .txt dateien die informationen enthalten?

NightPhoenix

Fr, Jan 19, 2007 16:50
Antworten mit Zitat

quasi externe .txt dateien die informationen enthalten?

	Dreamora	Fr, Jan 19, 2007 16:56 Antworten mit Zitat
coldie hat Folgendes geschrieben: Wenn man weis wie die zu ladende Datei aufgebaut ist, kann man sie doch einfach in mehreren Schritten in eine Bank laden. Für 70kb braucht mein Rechner so um die 10 millisecs (inklusive öffnen und schließen der Datei). Nur sind 10ms inakzeptabel, weil du hast bei 60 FPS insgesamt nur 16ms Zeit. Du könntest normalerweise wenns gut geht 5-6ms darauf verwenden, wenn du allerdings etwas hast, was soviele Daten hat, das es Streaming benötigt, kannst du davon ausgehen, dass es in 1-2ms geschehen müsste. Aber ansonsten kann man sich sein eigenes Streaming Format schreiben, jo. (die von Blitz unterstützen Formate sind keine Streaming Formate, die kann man schlecht bis garnicht streamend auslesen) Und nein, das dürfte kaum eine TXT sein Mit Texturen und statischen 3D Objekten wäre ein solches vorgehen durchaus möglich. Einfach stück um stück laden und intern entsprechend umwandeln und aus den Daten ein Mesh / Textur erzeugen. Es wird jedoch nicht funktionieren wenn man animierte Objekte, MD2, BSP oder Sounds streamen will. Dafür braucht man dann höhere "Hacks" und muss die Funktionsaufrufe selbst in eine streaming DLL umleiten.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Fr, Jan 19, 2007 16:56
Antworten mit Zitat

coldie hat Folgendes geschrieben:

Nur sind 10ms inakzeptabel, weil du hast bei 60 FPS insgesamt nur 16ms Zeit.

Du könntest normalerweise wenns gut geht 5-6ms darauf verwenden, wenn du allerdings etwas hast, was soviele Daten hat, das es Streaming benötigt, kannst du davon ausgehen, dass es in 1-2ms geschehen müsste.

Aber ansonsten kann man sich sein eigenes Streaming Format schreiben, jo. (die von Blitz unterstützen Formate sind keine Streaming Formate, die kann man schlecht bis garnicht streamend auslesen)
Und nein, das dürfte kaum eine TXT sein Smile

Mit Texturen und statischen 3D Objekten wäre ein solches vorgehen durchaus möglich. Einfach stück um stück laden und intern entsprechend umwandeln und aus den Daten ein Mesh / Textur erzeugen.

Es wird jedoch nicht funktionieren wenn man animierte Objekte, MD2, BSP oder Sounds streamen will. Dafür braucht man dann höhere "Hacks" und muss die Funktionsaufrufe selbst in eine streaming DLL umleiten.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	coldie	Fr, Jan 19, 2007 17:04 Antworten mit Zitat
@NightPhoenix: Nein nicht unbedingt .txt dateien. Für eine Terrain-engine hab ich mir z.B. ein Dateiformat ".terr" ausgedacht. Dort sind unter anderem einfach wie bei einer Heightmap die verschiedenen höhen gespeichert. Man kann das in eine Bank schreiben und dann bei einem bereits vorhandenen 3dMesh entsprechend die Y-Position der Vertexes ändern. Bei mir sieht das laden dann konkret so aus: Zitat: Select loadmap case 1 terrl0file = ReadFile("maps\l0\mapn1.terr") bytes = ReadBytes(terrainbank,terrl0file,0,5128^2+90) ; erste hälfte auslesen CloseFile terrl0file loadmap = 2 case 2 terrl0file= ReadFile("maps\l0\mapn1.terr") bytes = ReadBytes(terrainbank,terrl0file,5128^2+90,5*128^2+90) ; zweite hälfte auslesen CloseFile terrl0file loadmap = 0 end select @Dreamora: Die 10 ms fallen aber auch nur an wenn geladen wird. Mann kann natürlich auch noch weniger kb pro frame laden.

coldie

Fr, Jan 19, 2007 17:04
Antworten mit Zitat

@NightPhoenix:

Nein nicht unbedingt .txt dateien.
Für eine Terrain-engine hab ich mir z.B. ein Dateiformat ".terr" ausgedacht. Dort sind unter anderem einfach wie bei einer Heightmap die verschiedenen höhen gespeichert.
Man kann das in eine Bank schreiben und dann bei einem bereits vorhandenen 3dMesh entsprechend die Y-Position der Vertexes ändern.

Bei mir sieht das laden dann konkret so aus:

Zitat:

Select loadmap

case 1

terrl0file = ReadFile("maps\l0\mapn1.terr")
bytes = ReadBytes(terrainbank,terrl0file,0,5*128^2+90) ; erste hälfte auslesen
CloseFile terrl0file
loadmap = 2

case 2

terrl0file= ReadFile("maps\l0\mapn1.terr")
bytes = ReadBytes(terrainbank,terrl0file,5*128^2+90,5*128^2+90) ; zweite hälfte auslesen
CloseFile terrl0file
loadmap = 0

end select

@Dreamora:

Die 10 ms fallen aber auch nur an wenn geladen wird. Mann kann natürlich auch noch weniger kb pro frame laden.

	shure_kyu Newsposter	Sa, Jan 20, 2007 1:20 Antworten mit Zitat
ich versteh das ganze problem nicht das hat doch dc damals schon in stranded hinbekommen!!! indem er einfach alles geladen hat nur nicht gezeichnet, erst wenn sie im sichtbereich des spieler waren wurde gezeichnet so kann man doch große welten erstellen. entweder hab ich den faden verloren oder ihr redet aneinnander vorbei. ok und wenn es doch zu viel wird einfach die methode nutzen mit den zwischen räumen wie in halo2 is doch nicht das problem oder ?
_______//¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\________ ◄Blitz 3D/MAX • PC - 2x 3.16Ghz, 4GB-Ram, ATi HD 4890 1024MB• win7 • site$ Rush2Play ° My-Htc.de► ¯¯¯¯¯¯¯\__________________________________________________________________________//¯¯¯¯¯¯¯¯ BBP-RSS FEED Halt dich auf dem laufenden! (C)Shure_kyu

shure_kyu

Newsposter

Sa, Jan 20, 2007 1:20
Antworten mit Zitat

ich versteh das ganze problem nicht das hat doch dc damals schon in stranded hinbekommen!!!
indem er einfach alles geladen hat nur nicht gezeichnet, erst wenn sie im sichtbereich des spieler waren wurde gezeichnet so kann man doch große welten erstellen. entweder hab ich den faden verloren oder ihr redet aneinnander vorbei.
ok und wenn es doch zu viel wird einfach die methode nutzen mit den zwischen räumen wie in halo2 is doch nicht das problem oder ?

_______//¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\________
◄Blitz 3D/MAX • PC - 2x 3.16Ghz, 4GB-Ram, ATi HD 4890 1024MB• win7 • site$ Rush2Play ° My-Htc.de►
¯¯¯¯¯¯¯\__________________________________________________________________________//¯¯¯¯¯¯¯¯
BBP-RSS FEED Halt dich auf dem laufenden!
(C)Shure_kyu

	coldie	Sa, Jan 20, 2007 1:33 Antworten mit Zitat
Nun ja, ab einer bestimmten Datenmenge ist es einfach nicht mehr möglich vorher alles zu laden. Bei einem Flugsimulator wäre das mit den Zwischenräumen doch nicht wirklich umsetzbar oder?

coldie

Sa, Jan 20, 2007 1:33
Antworten mit Zitat

Nun ja, ab einer bestimmten Datenmenge ist es einfach nicht mehr möglich vorher alles zu laden. Bei einem Flugsimulator wäre das mit den Zwischenräumen doch nicht wirklich umsetzbar oder?

	Dreamora	Sa, Jan 20, 2007 9:29 Antworten mit Zitat
shure_kyu hat Folgendes geschrieben: ok und wenn es doch zu viel wird einfach die methode nutzen mit den zwischen räumen wie in halo2 is doch nicht das problem oder ? Das führt zu Resultaten wie in HL2 auf meinem alten Notebook (9700, 768MB RAM, 1.5Ghz P-M), nämlich Sequenzen wo man mehr Ladezeit pro Raum hat als man braucht um durch ihn durch zu kommen. Weder erstrebenswert noch taugt der Ansatz was, speziell wenn es Outdoor sein soll, wo es keine Räume gibt
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Sa, Jan 20, 2007 9:29
Antworten mit Zitat

shure_kyu hat Folgendes geschrieben:

ok und wenn es doch zu viel wird einfach die methode nutzen mit den zwischen räumen wie in halo2 is doch nicht das problem oder ?

Das führt zu Resultaten wie in HL2 auf meinem alten Notebook (9700, 768MB RAM, 1.5Ghz P-M), nämlich Sequenzen wo man mehr Ladezeit pro Raum hat als man braucht um durch ihn durch zu kommen. Weder erstrebenswert noch taugt der Ansatz was, speziell wenn es Outdoor sein soll, wo es keine Räume gibt Smile

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	shure_kyu Newsposter	Sa, Jan 20, 2007 9:46 Antworten mit Zitat
ja ich bin auch zu dem entschluss gekommen, nach ein paar test, das es sich mit bb nicht sehr besonders lohnt, eine so imens große welt wie in gothic zu erstellen. bei so einem projekt sollte man dann doch lieber auf eine andere sprache ausweichen, oder man kennt spezielle techniken in bb um so etwas umzusetzen.
_______//¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\________ ◄Blitz 3D/MAX • PC - 2x 3.16Ghz, 4GB-Ram, ATi HD 4890 1024MB• win7 • site$ Rush2Play ° My-Htc.de► ¯¯¯¯¯¯¯\__________________________________________________________________________//¯¯¯¯¯¯¯¯ BBP-RSS FEED Halt dich auf dem laufenden! (C)Shure_kyu

shure_kyu

Newsposter

Sa, Jan 20, 2007 9:46
Antworten mit Zitat

ja ich bin auch zu dem entschluss gekommen, nach ein paar test, das es sich mit bb nicht sehr besonders lohnt, eine so imens große welt wie in gothic zu erstellen. bei so einem projekt sollte man dann doch lieber auf eine andere sprache ausweichen, oder man kennt spezielle techniken in bb um so etwas umzusetzen.

	NightPhoenix	Sa, Jan 20, 2007 10:06 Antworten mit Zitat
Alle die den Faden verloren haben, hier nochmal das Hauptproblem: Eine riesige Welt erschaffen, möglichst ohne Ladebildschirme, bzw. langen Ladezeiten (sehr gutes Beispiel Gothic II). Nun besteht das Problem, dass man eine Welt wie Gothic II nicht ohne Ladezeiten machen kann, denn die Texturen belegen viel zu viel VRAM, sodass der Computer wegen der giganischen Masse Texturen auf den RAM zurückgreifen muss, das Ergebnis ist eine FPS Zahl von 12! -> nicht gut spezielle techniken... naja nicht wirklich... man müsste sich für absolut jedes Objekt in der Welt ein entitydistanceBefehl machen.... wenn dieser kleiner ist als die Sichtweite wird dieses entsprechnede Objekt geladen, wenn es außerhalb dieses Bereiches ist wird es wieder gelöscht. Probleme: 1. EntityDistance Abfragen für absolut jedes Objekt dauert zu lange in der Schleife.... 2. Viel zu viel Code 3. oft ruckelnder "Spielspaß", wenn überhaupt noch möglich. mögliche Lösungen: 1. Nur jeden 1000. Schleifendurchlauf auf EntityDistance prüfen Nunja und dann dachte ich mir noch was anderes, ziemlich ähnliches. Man könnte ja an allen Objektkoordinaten Würfel erstellen (createcube) mit types.... wenn jetzt einer dieser würfel mit einer unsichtbaren Box, welche dem Spieler folgt, kollidiert wird genau dieser ersetzt mit dem Objekt so und so.... entweder man macht für jedes unterschiedliche Objekt unterschiedliche Types, oder man lässt es bleiben... Müsste aber theoretisch schneller sein, als entitydistance, da ja nur lokal auf kollisionen geprüft wird. Probleme: 1. bei einer Stadt wirds ziemlich problematisch (viel ruckeln) 2. Wir haben wohl tausende Surfaces Die letzte Variante ist die klassische Variante mit Abschnitten wo immer nachgeladen wird... 1. Große Abschnitte, aber schlechtere Texturen 2. kleine Abschnitte, dafür aber "hochglanz"texturen Nungut, ich könnte zum Spiel hinzu natürlich noch allen die es sich dann downloaden das neue Flagschiff von NVidia mitschicken... das hat ja gleich 640mb VRAM das soll jetz aber nicht verbindlich sein MfG. Nightphoenix

NightPhoenix

Sa, Jan 20, 2007 10:06
Antworten mit Zitat

Alle die den Faden verloren haben, hier nochmal das Hauptproblem:
Eine riesige Welt erschaffen, möglichst ohne Ladebildschirme, bzw. langen Ladezeiten (sehr gutes Beispiel Gothic II).
Nun besteht das Problem, dass man eine Welt wie Gothic II nicht ohne Ladezeiten machen kann, denn die Texturen belegen viel zu viel VRAM, sodass der Computer wegen der giganischen Masse Texturen auf den RAM zurückgreifen muss, das Ergebnis ist eine FPS Zahl von 12! -> nicht gut

spezielle techniken... naja nicht wirklich...
man müsste sich für absolut jedes Objekt in der Welt ein entitydistanceBefehl machen.... wenn dieser kleiner ist als die Sichtweite wird dieses entsprechnede Objekt geladen, wenn es außerhalb dieses Bereiches ist wird es wieder gelöscht.
Probleme:
1. EntityDistance Abfragen für absolut jedes Objekt dauert zu lange in der Schleife....
2. Viel zu viel Code
3. oft ruckelnder "Spielspaß", wenn überhaupt noch möglich.
mögliche Lösungen:
1. Nur jeden 1000. Schleifendurchlauf auf EntityDistance prüfen

Nunja und dann dachte ich mir noch was anderes, ziemlich ähnliches. Man könnte ja an allen Objektkoordinaten Würfel erstellen (createcube) mit types.... wenn jetzt einer dieser würfel mit einer unsichtbaren Box, welche dem Spieler folgt, kollidiert wird genau dieser ersetzt mit dem Objekt so und so.... entweder man macht für jedes unterschiedliche Objekt unterschiedliche Types, oder man lässt es bleiben...
Müsste aber theoretisch schneller sein, als entitydistance, da ja nur lokal auf kollisionen geprüft wird.
Probleme:
1. bei einer Stadt wirds ziemlich problematisch (viel ruckeln)
2. Wir haben wohl tausende Surfaces

Die letzte Variante ist die klassische Variante mit Abschnitten wo immer nachgeladen wird...
1. Große Abschnitte, aber schlechtere Texturen
2. kleine Abschnitte, dafür aber "hochglanz"texturen

Nungut, ich könnte zum Spiel hinzu natürlich noch allen die es sich dann downloaden das neue Flagschiff von NVidia mitschicken... das hat ja gleich 640mb VRAM Wink

das soll jetz aber nicht verbindlich sein Razz

MfG. Nightphoenix

	Phalastos	Sa, Jan 20, 2007 10:13 Antworten mit Zitat
Zitat: man müsste sich für absolut jedes Objekt in der Welt ein entitydistanceBefehl machen.... wenn dieser kleiner ist als die Sichtweite wird dieses entsprechnede Objekt geladen, wenn es außerhalb dieses Bereiches ist wird es wieder gelöscht. Du mußt einfach mit Blöcken arbeiten und somit nur die jeweiligen Blöcke auf Sichtbarkeit / Entfernung prüfen lassen.
Forbiddenmagic - Warfare of Forgotten Power

Phalastos

Sa, Jan 20, 2007 10:13
Antworten mit Zitat

Zitat:

man müsste sich für absolut jedes Objekt in der Welt ein entitydistanceBefehl machen.... wenn dieser kleiner ist als die Sichtweite wird dieses entsprechnede Objekt geladen, wenn es außerhalb dieses Bereiches ist wird es wieder gelöscht.

Du mußt einfach mit Blöcken arbeiten und somit nur die jeweiligen Blöcke auf Sichtbarkeit / Entfernung prüfen lassen.

Forbiddenmagic - Warfare of Forgotten Power

	NightPhoenix	Sa, Jan 20, 2007 10:15 Antworten mit Zitat
meinst du mit Blöcken die Cube Variante? oder meinst du mit Blöcken eine spezielle Verwaltung von Objekten?

NightPhoenix

Sa, Jan 20, 2007 10:15
Antworten mit Zitat

meinst du mit Blöcken die Cube Variante?
oder meinst du mit Blöcken eine spezielle Verwaltung von Objekten?

	Dreamora	Sa, Jan 20, 2007 11:08 Antworten mit Zitat
Damit meint er, dass du die Daten so speicherst, dass du jeweils eine Zone laden / entladen kannst ( in Shootern ist das häufig ein Raum oder ein Gang mit Räumen, in grossen Aussenbereichen versucht man via Wälder / Berge ähnliche "Sichteinschränkungen" zu erreichen, denn das laden / entladen von Zonen geht nicht via distanz sondern mittels potentieller Sichtbarkeit sprich "könnte der spieler dieses gebiet bald zu sehen bekommen? Wenn ja laden. und entsprechend fürs entladen). Einzelne Objekte macht keinen Sinn, der Verwaltungsaufwand wäre so gigantisch, dass du vom gestaffelten Laden höchstens noch Nachteile hast anstatt Vorteile. Ein einfaches Beispiel um das zu verdeutlichen: Spieler läuft immer zwischen Punkt A und B hin und her. Einzelne Objekte würden hier die ganze Zeit geladen und wieder entladen, die Performance ist im Eimer. Zonen jedoch würden konstant im RAM bleiben, da der Spieler nicht soweit weg kommt, dass die Zone entladen werden müsste.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Sa, Jan 20, 2007 11:08
Antworten mit Zitat

Damit meint er, dass du die Daten so speicherst, dass du jeweils eine Zone laden / entladen kannst ( in Shootern ist das häufig ein Raum oder ein Gang mit Räumen, in grossen Aussenbereichen versucht man via Wälder / Berge ähnliche "Sichteinschränkungen" zu erreichen, denn das laden / entladen von Zonen geht nicht via distanz sondern mittels potentieller Sichtbarkeit sprich "könnte der spieler dieses gebiet bald zu sehen bekommen? Wenn ja laden. und entsprechend fürs entladen). Einzelne Objekte macht keinen Sinn, der Verwaltungsaufwand wäre so gigantisch, dass du vom gestaffelten Laden höchstens noch Nachteile hast anstatt Vorteile.

Ein einfaches Beispiel um das zu verdeutlichen: Spieler läuft immer zwischen Punkt A und B hin und her.
Einzelne Objekte würden hier die ganze Zeit geladen und wieder entladen, die Performance ist im Eimer.
Zonen jedoch würden konstant im RAM bleiben, da der Spieler nicht soweit weg kommt, dass die Zone entladen werden müsste.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Gehe zu Seite Zurück 1, 2, 3, 4 Weiter

Übersicht

BlitzBasic

Blitz3D

Nach Oben

BlitzBasic Portal

Landschaften ala Gothic