3D Modul - Ideen/Vorschläge

Übersicht

BlitzMax, BlitzMax NG

Allgemein

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

	Vertex	Do, Apr 07, 2005 14:54 Antworten mit Zitat
Jan_: Das kann ich mir selber auch nicht erklähren. Für solche Dinge ist oft BMax bzw. das System verantwortlich. furbolg: Die Idee den VBO mit allen Frames zu füllen, ist natürlich genial, aber wie du schon sagtest, bei durschnittlich 1800 Vertices(= 600 Triangles) und 150 Frames macht das 150180012 Byte ~ 3MB. Habe schon den VBO auf GL_DYNAMIC_DRAW gestellt. Das manipulieren wie es unter DirectX mit LockBuffer und UnLockbuffer (in GL = glMapBufferARB und glUnMapBufferARB) geht, ist unter OpenGL sau lahm. Es muss ja der komplette VBO vom VRAM in den WRAM und wieder zurück kopiert werden. Bin selber kein Fan vom MD2 Format, ist halt optimiert worden fürs alte Quake2, aber es muss drotzdem mit der selben Geschwindigkeit lösbar sein, wie mit Blitz3D. Letzendlich dürften sich VBOs von Direct3D nicht zu OpenGL VBOs unterscheiden ?oder Auch skelektare Animationen müssen auf das Updaten des VBOs zurückgreifen, da darf das auch nicht so von Statten gehen. Das umstruktieren des VBOs von: XYZ NX NY NZ U0 V0 U1 V1 R G B A XYZ NX NY NZ U0 V0 U1 V1 R G B A XYZ NX NY NZ U0 V0 U1 V1 R G B A ... Nach XYZ XYZ XYZ NX NY NZ NX NY NZ NX NY NZ U0 V0 U0 V0 U1 V1 U1 V1 R G B A R G B A R G B A Wo ich dann nur noch die XYZs rüberkopieren muss, hat anscheinend auch keine Auswirkung. Habe mal versucht, statts den insgesamt 56 Bytes pro Vertex, nur die 12 Bytes für XYZ zu updaten, liegt abd immer noch im Bereich von 470 FPS. Das ist echt der Hass. Mir fällt auch keine Optimierung mehr ein. mfg olli
vertex.dreamfall.at \| GitHub

Vertex

Do, Apr 07, 2005 14:54
Antworten mit Zitat

Jan_: Das kann ich mir selber auch nicht erklähren. Für solche Dinge ist oft BMax bzw. das System verantwortlich.

furbolg: Die Idee den VBO mit allen Frames zu füllen, ist natürlich genial, aber wie du schon sagtest, bei durschnittlich 1800 Vertices(= 600 Triangles) und 150 Frames macht das 150*1800*12 Byte ~ 3MB.

Habe schon den VBO auf GL_DYNAMIC_DRAW gestellt. Das manipulieren wie es unter DirectX mit LockBuffer und UnLockbuffer (in GL = glMapBufferARB und glUnMapBufferARB) geht, ist unter OpenGL sau lahm. Es muss ja der komplette VBO vom VRAM in den WRAM und wieder zurück kopiert werden.

Bin selber kein Fan vom MD2 Format, ist halt optimiert worden fürs alte Quake2, aber es muss drotzdem mit der selben Geschwindigkeit lösbar sein, wie mit Blitz3D. Letzendlich dürften sich VBOs von Direct3D nicht zu OpenGL VBOs unterscheiden ?oder

Auch skelektare Animationen müssen auf das Updaten des VBOs zurückgreifen, da darf das auch nicht so von Statten gehen.

Das umstruktieren des VBOs von:
XYZ
NX NY NZ
U0 V0
U1 V1
R G B A
XYZ
NX NY NZ
U0 V0
U1 V1
R G B A
XYZ
NX NY NZ
U0 V0
U1 V1
R G B A
...
Nach
XYZ
XYZ
XYZ
NX NY NZ
NX NY NZ
NX NY NZ
U0 V0
U0 V0
U1 V1
U1 V1
R G B A
R G B A
R G B A

Wo ich dann nur noch die XYZs rüberkopieren muss, hat anscheinend auch keine Auswirkung. Habe mal versucht, statts den insgesamt 56 Bytes pro Vertex, nur die 12 Bytes für XYZ zu updaten, liegt abd immer noch im Bereich von 470 FPS.

Das ist echt der Hass. Mir fällt auch keine Optimierung mehr ein.
mfg olli

vertex.dreamfall.at | GitHub

	Vertex	Fr, Apr 08, 2005 17:08 Antworten mit Zitat
Geil wie ich bin, habe ich heute zufällig meinen MD2 Importer gelöscht, und mein hart umstrukturiertes Surfacesystem ist langsamer als das alte. Ein schöner Tag, um mal alles zusammen zu schlagen, was einem vor die Augen kommt!
vertex.dreamfall.at \| GitHub

Vertex

Fr, Apr 08, 2005 17:08
Antworten mit Zitat

Geil wie ich bin, habe ich heute zufällig meinen MD2 Importer gelöscht, und mein hart umstrukturiertes Surfacesystem ist langsamer als das alte.

Ein schöner Tag, um mal alles zusammen zu schlagen, was einem vor die Augen kommt!

vertex.dreamfall.at | GitHub

	stfighter01	Fr, Apr 08, 2005 18:26 Antworten mit Zitat
autsch. und deshalb "save early save often" aber: wozu md2? die trennung md2 u. andere meshes/animationen fand ich ohnehin nicht sehr toll. Vorrangig würd ich mich ohnehin auf die polygonverarbeitung (sortierung, rendering ...) also die kernsysteme stürzen. Vorher hat ohnehin niemand interresse an animationen (wills nicht madig machen, aber es ist wohl so). keep up good work. btw. du kiegst das schon wieder hin mfg stfighter
Denken hilft!

stfighter01

Fr, Apr 08, 2005 18:26
Antworten mit Zitat

autsch.

und deshalb "save early save often" Sad

aber: wozu md2?
die trennung md2 u. andere meshes/animationen fand ich ohnehin nicht sehr toll.
Vorrangig würd ich mich ohnehin auf die polygonverarbeitung (sortierung, rendering ...) also die kernsysteme stürzen.
Vorher hat ohnehin niemand interresse an animationen (wills nicht madig machen, aber es ist wohl so).

keep up good work.
btw. du kiegst das schon wieder hin Wink

mfg stfighter

Denken hilft!

	Dreamora	Sa, Apr 09, 2005 17:52 Antworten mit Zitat
MD2 etc sind auch nicht auf statische Buffer wie VBO oder List ausgelegt sondern auf die dynamischen, SysRAM gebunden Varianten ausgelegt (sind glaub im Falle von OpenGL die Arrays oder so ... bin noch net soweit durch das ich mich um nonstatische gekümmert hätte) Wenn du VBO mit sinnvollem Speed nutzen willst musst du es wie WoW über VertexShader Animation machen.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Sa, Apr 09, 2005 17:52
Antworten mit Zitat

MD2 etc sind auch nicht auf statische Buffer wie VBO oder List ausgelegt sondern auf die dynamischen, SysRAM gebunden Varianten ausgelegt (sind glaub im Falle von OpenGL die Arrays oder so ... bin noch net soweit durch das ich mich um nonstatische gekümmert hätte)

Wenn du VBO mit sinnvollem Speed nutzen willst musst du es wie WoW über VertexShader Animation machen.

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

	Vertex	So, Apr 10, 2005 15:35 Antworten mit Zitat
stfighter01: TDDMD2 hatte von TDDDMesh geerbt, und noch CountFrames, SetFrame und GetFrame spendiert bekommen. Aber ja, hätte ich den mal lieber ein Backup angelegt Ich wollte bzw. will MD2 Unterstützen, um nur ein weiteres Feature zu haben. Weiterhin muss MD2 auch animierbar bleiben, ohne großen Geschwindigkeitseinbrauch. Dreamora: In wie weit meinst du das VBOs statisch sei? VertexArrays sind bedeutend langsamer als VBOs. Den Ansatz über VertexShader verstehe ich nicht. Ob ich nun im VBO die Daten direkt manipuliere oder die neue Position an den Shader(über VBO oder VertexArray) sende, spielt meiner Meinung nach keine Rolle ?oder? Das die VBOs so lahm beim updaten sind, liegt übrigens nicht an meiner Engine. Habe das ganze mal abgekapselt und musste festellen, dass es wieder nur die halbe FPS Rate war. mfg olli Edit: Sehe gerade, das ich das ganze mit 60000 Vertices versucht hatte... Ich versuche ein letztes mal, das jetzt über einen sepperaten VBO nur für Vertexpositionen zu machen. Geht dies immer noch nicht, muss ich warscheinlich die Engine aufgeben.
vertex.dreamfall.at \| GitHub

Vertex

So, Apr 10, 2005 15:35
Antworten mit Zitat

stfighter01: TDDMD2 hatte von TDDDMesh geerbt, und noch CountFrames, SetFrame und GetFrame spendiert bekommen. Aber ja, hätte ich den mal lieber ein Backup angelegt Smile

Ich wollte bzw. will MD2 Unterstützen, um nur ein weiteres Feature zu haben. Weiterhin muss MD2 auch animierbar bleiben, ohne großen Geschwindigkeitseinbrauch.

Dreamora: In wie weit meinst du das VBOs statisch sei? VertexArrays sind bedeutend langsamer als VBOs. Den Ansatz über VertexShader verstehe ich nicht. Ob ich nun im VBO die Daten direkt manipuliere oder die neue Position an den Shader(über VBO oder VertexArray) sende, spielt meiner Meinung nach keine Rolle ?oder?

Das die VBOs so lahm beim updaten sind, liegt übrigens nicht an meiner Engine. Habe das ganze mal abgekapselt und musste festellen, dass es wieder nur die halbe FPS Rate war.

mfg olli

Edit: Sehe gerade, das ich das ganze mit 60000 Vertices versucht hatte... Ich versuche ein letztes mal, das jetzt über einen sepperaten VBO nur für Vertexpositionen zu machen. Geht dies immer noch nicht, muss ich warscheinlich die Engine aufgeben.

vertex.dreamfall.at | GitHub

	Dreamora	So, Apr 10, 2005 16:01 Antworten mit Zitat
Statisch weil sie zwischen den RAMs rumgeschoben werden, wann immer du sie manipulieren willst. Deswegen sind sie auf non-shader Karten eigentlich wirklich nur für statische Daten zu gebrauchen. Wenn man das net beachtet, kommt ein Spiel wie Spellforce raus, das auf nonshader karten auf 2 FPS zusammenbricht (habs mit GF4 MX und Radeon 9000 getestet die nahezu identisch sind vom Shadersupport abgesehen) Da kommst du mit alten Ansätzen bedeutend besser weg für animierte Objekte. Und so langsam können sie nicht sein, sonst würde es keine 3D Shooter geben seit Q1 ... denn VBOs gibts erst seit Q3+ Mit dem VertexShader ersparst du dir dabei das rumschieben indem du die GPU das machen lässt, welche das beträchtlich schneller kann als ein VRAM -> RAM -> CPU -> VRAM. Von der Bandbreitenersparnis sprechen wir garnet erst (denn 60-200 FPS pro s ... jedes Mal jedes VBO rein und wieder raus ... Das macht net ma PCI-E mit )
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

So, Apr 10, 2005 16:01
Antworten mit Zitat

Statisch weil sie zwischen den RAMs rumgeschoben werden, wann immer du sie manipulieren willst. Deswegen sind sie auf non-shader Karten eigentlich wirklich nur für statische Daten zu gebrauchen. Wenn man das net beachtet, kommt ein Spiel wie Spellforce raus, das auf nonshader karten auf 2 FPS zusammenbricht (habs mit GF4 MX und Radeon 9000 getestet die nahezu identisch sind vom Shadersupport abgesehen)
Da kommst du mit alten Ansätzen bedeutend besser weg für animierte Objekte. Und so langsam können sie nicht sein, sonst würde es keine 3D Shooter geben seit Q1 ... denn VBOs gibts erst seit Q3+ Smile

Mit dem VertexShader ersparst du dir dabei das rumschieben indem du die GPU das machen lässt, welche das beträchtlich schneller kann als ein VRAM -> RAM -> CPU -> VRAM. Von der Bandbreitenersparnis sprechen wir garnet erst (denn 60-200 FPS pro s ... jedes Mal jedes VBO rein und wieder raus ... Das macht net ma PCI-E mit Wink

)

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

	Vertex	So, Apr 10, 2005 16:49 Antworten mit Zitat
Habe jetzt erste Tests mit sepperaten VBO für die Vertexposition durchgeführt, und es kostet bei 2500 Vertices gerade 10 FPS von 960 FPS. Früher waren es 480 FPS. Bei MD2 kommen nochmal ein paar FPS ab, da ja die Frames interpoliert werden müssen. Kostet denke ich max. 20 FPS, jedoch ist das von der FPU abhängig. In wie weit ich das Bonesystem über VertexPrograms(= VertexShader) ausstatten werde, bleibt die große Frage. Für User-VertexPrograms müsste die Grafikkarte min. zwei Shader-Pipelines bereitstellen. Weiter weiß ich nicht, wie man dann die Vertexdaten sepperat den Bones zuweisen soll. Aber dazu muss ich mir später gedanken machen mfg olli
vertex.dreamfall.at \| GitHub

Vertex

So, Apr 10, 2005 16:49
Antworten mit Zitat

Habe jetzt erste Tests mit sepperaten VBO für die Vertexposition durchgeführt, und es kostet bei 2500 Vertices gerade 10 FPS von 960 FPS. Früher waren es 480 FPS. Bei MD2 kommen nochmal ein paar FPS ab, da ja die Frames interpoliert werden müssen. Kostet denke ich max. 20 FPS, jedoch ist das von der FPU abhängig.

In wie weit ich das Bonesystem über VertexPrograms(= VertexShader) ausstatten werde, bleibt die große Frage. Für User-VertexPrograms müsste die Grafikkarte min. zwei Shader-Pipelines bereitstellen. Weiter weiß ich nicht, wie man dann die Vertexdaten sepperat den Bones zuweisen soll. Aber dazu muss ich mir später gedanken machen Smile

mfg olli

vertex.dreamfall.at | GitHub

	Jan_ Ehemaliger Admin	So, Apr 10, 2005 19:18 Antworten mit Zitat
Wow, ich bewunder dich, wie du üb er solchen Bahnhof reden kannst, und es anscheinend auch verstehst, obwohl, das thema ja recht neu für dich zu scheint
between angels and insects

Jan_

Ehemaliger Admin

So, Apr 10, 2005 19:18
Antworten mit Zitat

Wow, ich bewunder dich, wie du üb er solchen Bahnhof reden kannst, und es anscheinend auch verstehst, obwohl, das thema ja recht neu für dich zu scheint

between angels and insects

	Vertex	Sa, Apr 16, 2005 23:08 Antworten mit Zitat
Danke! Wenn man einmal die Funktionsweise erkannt hat, das OpenGL eine Statemachine ist, und sich schonmal Gedanken zu einigen Effekte gemacht hat, geht es recht zuügig zu lernen. Habe mich jetzt in letzter Zeit viel eingelesen. Die OpenGL 2.0 Specs sind mir gestern unter die Augen gekommen, wo zum Glück mal alle Formeln zur Berechnung von Sachen wie Lighting, Projektion usw. beschrieben werden. Ein wahrer segen zu den ganzen Tutorials, wo fast garnicht auf die Mathematik hinter Effekten eingegangen wird. Jedenfalls ist es mir heute gelungen Dot3 Bumpmapping zu realisieren, das genauso funktioniert, wie in Blitz3D. Auf Grundlage dessen, müsste es mir auch möglich sein, Specularmaps zu realisieren(Unrealengine lässt grüßen ) Weiterhin habe ich herausgefunden, wie man Texturprojektion betreibt(auch hier lässt Unrealengine grüßen). Damit ist es möglich auch Schatten auf realtiv einfache weise zu realisieren. So ein Schatten ist dann halt von der Auflösung der Schattentextur abhängig. Dot3 Bumpmapping ist noch etwas langsam zu betreiben mit selbst berechneten Vertexfarben. Das geht einfacher und schneller über VertexShader. Diese werden bald über TDDDMaterial ansprechbar sein. Ich bekomme bald einen neuen Computer mit OGL 1.4 kompatibler Karte. Dann kann ich sicher auch mal Fragmentshader testen und Shader-Hochsprache GlSlang ausprobieren. Derzeit bin ich weiter am grübeln, ob es sich für mich lohnt, das Projekt in BMax weiter zu führen. Mir schwebt weiterhin eine C++ mit SDL Umsetzung im Kopf. Die aktuelle DreiDe-Struktur lässt sich mit meinen neuen Erkentnissen und dem neuen Surfacesystem nichtmehr aufrecht erhalten. Und die Unlogik bei Freigaben von Ressourcen in BMax unterstützt mich nicht gerade dabei, es in BMax neu zu beginnen. Ist nicht aus der Engine selber heraus entstanden, sondern aus einem Test heraus, der dann doch für die Vertexfarben-Berechnung von 100 Zeilen aufs 20 fache angewachsen ist(wie gesagt, mit Vertexshader ist soetwas schneller und einfacher möglich). Die Berechnung hier ist jedoch noch etwas falsch. Die Implementierung ist aber 1 zu 1 mit Blitz3D kompatibel. mfg olli
vertex.dreamfall.at \| GitHub

Vertex

Sa, Apr 16, 2005 23:08
Antworten mit Zitat

Danke! Wenn man einmal die Funktionsweise erkannt hat, das OpenGL eine Statemachine ist, und sich schonmal Gedanken zu einigen Effekte gemacht hat, geht es recht zuügig zu lernen.

Habe mich jetzt in letzter Zeit viel eingelesen. Die OpenGL 2.0 Specs sind mir gestern unter die Augen gekommen, wo zum Glück mal alle Formeln zur Berechnung von Sachen wie Lighting, Projektion usw. beschrieben werden. Ein wahrer segen zu den ganzen Tutorials, wo fast garnicht auf die Mathematik hinter Effekten eingegangen wird.

Jedenfalls ist es mir heute gelungen Dot3 Bumpmapping zu realisieren, das genauso funktioniert, wie in Blitz3D. Auf Grundlage dessen, müsste es mir auch möglich sein, Specularmaps zu realisieren(Unrealengine lässt grüßen Smile

)

Weiterhin habe ich herausgefunden, wie man Texturprojektion betreibt(auch hier lässt Unrealengine grüßen). Damit ist es möglich auch Schatten auf realtiv einfache weise zu realisieren. So ein Schatten ist dann halt von der Auflösung der Schattentextur abhängig.

Dot3 Bumpmapping ist noch etwas langsam zu betreiben mit selbst berechneten Vertexfarben. Das geht einfacher und schneller über VertexShader. Diese werden bald über TDDDMaterial ansprechbar sein.

Ich bekomme bald einen neuen Computer mit OGL 1.4 kompatibler Karte. Dann kann ich sicher auch mal Fragmentshader testen und Shader-Hochsprache GlSlang ausprobieren.

Derzeit bin ich weiter am grübeln, ob es sich für mich lohnt, das Projekt in BMax weiter zu führen. Mir schwebt weiterhin eine C++ mit SDL Umsetzung im Kopf. Die aktuelle DreiDe-Struktur lässt sich mit meinen neuen Erkentnissen und dem neuen Surfacesystem nichtmehr aufrecht erhalten. Und die Unlogik bei Freigaben von Ressourcen in BMax unterstützt mich nicht gerade dabei, es in BMax neu zu beginnen.

user posted image

Ist nicht aus der Engine selber heraus entstanden, sondern aus einem Test heraus, der dann doch für die Vertexfarben-Berechnung von 100 Zeilen aufs 20 fache angewachsen ist(wie gesagt, mit Vertexshader ist soetwas schneller und einfacher möglich). Die Berechnung hier ist jedoch noch etwas falsch. Die Implementierung ist aber 1 zu 1 mit Blitz3D kompatibel.

mfg olli

vertex.dreamfall.at | GitHub

	Dreamora	So, Apr 17, 2005 13:50 Antworten mit Zitat
Was für eine Freigabeunlogik von BM meinst du? Da gibt es eigentlich keine Unlogik: Was nirgends mehr referenziert wird, wird freigegeben, der Rest wird behalten. ( im OO Modus. ansonsten gibt Release die Int handles zum "abschuss" frei)
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

So, Apr 17, 2005 13:50
Antworten mit Zitat

Was für eine Freigabeunlogik von BM meinst du?
Da gibt es eigentlich keine Unlogik: Was nirgends mehr referenziert wird, wird freigegeben, der Rest wird behalten. ( im OO Modus. ansonsten gibt Release die Int handles zum "abschuss" frei)

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

	Vertex	So, Apr 17, 2005 14:53 Antworten mit Zitat
Naja in der Hilfe steht gerade zu so einem sehr wichtigen Thema nix beschrieben, auser das bei FlushMem alle ungenutzten Ressourcen freigegeben werden. Die Frage ist, wann ist eine Referenz ungenutzt? Wenn sie auf Null steht? Sobald eine Funktion verlassen wird, wird da jede dort erstellte Ressource auf Null gesetzt? Wie sieht es aus, wenn eine Ressource in einem übergebenen Type als Attribut eingebunden wird oder als Rückgabewert agiert? Was ist wenn ein Type mit so einem Attribut selber freigegeben wird? Wie sieht es mit Banks aus? Soetwas ist klar und deutlich in C++ über new und delete geregelt. Weiter stört es mich, das Arrays mit festen Größen in Types dennoch als Pointer gehandhabt werden. In C und C++ könnte ich hier beim Auslesen aus einer Datei, oder beim Kopieren nur einen einzigen Befehl anwenden, in BMax müsste ich das Array extra auslesen bzw. extra kopieren. Das stört auch die Zusammenarbeit mit APIs die zum großen Teil auf C-Strukturen basieren, und man dafür immer Banks erstellen muss. Der Milkshape3D könnte hier sehr viel schneller arbeiten, und aber drotzdem sauber strukturiert bleiben. Aber nein, ich muss ihn auf Banks umstellen, und dann umständlich und im Widerspruch zum OOP mit Offsets arbeiten. mfg olli
vertex.dreamfall.at \| GitHub

Vertex

So, Apr 17, 2005 14:53
Antworten mit Zitat

Naja in der Hilfe steht gerade zu so einem sehr wichtigen Thema nix beschrieben, auser das bei FlushMem alle ungenutzten Ressourcen freigegeben werden. Die Frage ist, wann ist eine Referenz ungenutzt? Wenn sie auf Null steht? Sobald eine Funktion verlassen wird, wird da jede dort erstellte Ressource auf Null gesetzt? Wie sieht es aus, wenn eine Ressource in einem übergebenen Type als Attribut eingebunden wird oder als Rückgabewert agiert? Was ist wenn ein Type mit so einem Attribut selber freigegeben wird? Wie sieht es mit Banks aus? Soetwas ist klar und deutlich in C++ über new und delete geregelt.

Weiter stört es mich, das Arrays mit festen Größen in Types dennoch als Pointer gehandhabt werden. In C und C++ könnte ich hier beim Auslesen aus einer Datei, oder beim Kopieren nur einen einzigen Befehl anwenden, in BMax müsste ich das Array extra auslesen bzw. extra kopieren. Das stört auch die Zusammenarbeit mit APIs die zum großen Teil auf C-Strukturen basieren, und man dafür immer Banks erstellen muss. Der Milkshape3D könnte hier sehr viel schneller arbeiten, und aber drotzdem sauber strukturiert bleiben. Aber nein, ich muss ihn auf Banks umstellen, und dann umständlich und im Widerspruch zum OOP mit Offsets arbeiten.

mfg olli

vertex.dreamfall.at | GitHub

	stfighter01	So, Apr 17, 2005 17:07 Antworten mit Zitat
hmm warum banks? gukst du arrays->slices. zum redimensionieren, kopieren ... was die speicherverwaltung betrifft, so ist das schon ganz gut ausgetüftel. fast das gleiche system benutzt z.b. java. es macht nix anderes als das es objekte in den müll kübelt auf die du gar keinen zugriff mehr hättes. also wenn ALLE referenzen die auf dieses objekt zeigen - seien es globale, lokale od. field variablen auf einen anderen wert gesetzt wurden. damit kannst du immer sicher sein das kein objekt 'verloren' geht. und erst dann wird beim nächsten FLUSHMEM der destruktor des objekts aufgerufen, und das objekt zerstört. spart irrsinnig viel schreibaufwand und die gefahr durch memoryleaks wird kleiner. glaub mir, wenns nicht sein muss willst du dich gar nicht selbst um dieses speichermanagement kümmern (und es muss nicht sein nur darfst du eben nicht vergessen die werte auf null zu setzen, bzw. zu überschreiben wenn du ein objekt nicht mehr benötigst, da sonst das teil ewig lang im speicher rumkrebst. du kannst z.b.: auch ein neues parameterobjekt einer funktion übergeben, und dies wird mit dem ende der funktion wieder vergessen -> objekt weg speicher frei. mfg stfighter
Denken hilft!

stfighter01

So, Apr 17, 2005 17:07
Antworten mit Zitat

hmm
warum banks?
gukst du arrays->slices. zum redimensionieren, kopieren ...

was die speicherverwaltung betrifft, so ist das schon ganz gut ausgetüftel.
fast das gleiche system benutzt z.b. java.
es macht nix anderes als das es objekte in den müll kübelt auf die du gar keinen zugriff mehr hättes.
also wenn ALLE referenzen die auf dieses objekt zeigen - seien es globale, lokale od. field variablen auf einen anderen wert gesetzt wurden.
damit kannst du immer sicher sein das kein objekt 'verloren' geht.
und erst dann wird beim nächsten FLUSHMEM der destruktor des objekts aufgerufen, und das objekt zerstört.
spart irrsinnig viel schreibaufwand und die gefahr durch memoryleaks wird kleiner.
glaub mir, wenns nicht sein muss willst du dich gar nicht selbst um dieses speichermanagement kümmern (und es muss nicht sein Wink

nur darfst du eben nicht vergessen die werte auf null zu setzen, bzw. zu überschreiben wenn du ein objekt nicht mehr benötigst, da sonst das teil ewig lang im speicher rumkrebst.
du kannst z.b.: auch ein neues parameterobjekt einer funktion übergeben, und dies wird mit dem ende der funktion wieder vergessen -> objekt weg speicher frei.

mfg stfighter

Denken hilft!

	Vertex	So, Apr 17, 2005 17:20 Antworten mit Zitat
Das klährt jedoch nicht, um was sich Blitz selber kümmert, und um was nicht. Eben so sachen wie bei lokalen Variablen in Funktionen etc.. Heißt das z. B. das wenn ich keinen eigenen Destruktor in meinem Type benutze, das Objekt für alle Ewigkeit im Speicher herumhängt? Mir pers. wäre es lieber, wenn man wieder, wenn man mit Release arbeiten müsste. Auch lokal-angelegte Objekte blieben so lange im Speicher, bis man sie mit Release freigibt. So muss ich durch Testen mit MemAlloced immer selber das ganze Zeug herausfinden. Unter Linux gab es z.B. bei vielen Memoryleaks, wo ich nicht weiß, ob ich dafür verantwortlich bin, oder ob dies ein Bug von BMax ist. mfg olli Edit: OK, das mit dem Destruktor ist ja eine gute Sache. Schade das man keine Parameter am Konstruktor übergeben kann.
vertex.dreamfall.at \| GitHub

Vertex

So, Apr 17, 2005 17:20
Antworten mit Zitat

Das klährt jedoch nicht, um was sich Blitz selber kümmert, und um was nicht. Eben so sachen wie bei lokalen Variablen in Funktionen etc.. Heißt das z. B. das wenn ich keinen eigenen Destruktor in meinem Type benutze, das Objekt für alle Ewigkeit im Speicher herumhängt? Mir pers. wäre es lieber, wenn man wieder, wenn man mit Release arbeiten müsste. Auch lokal-angelegte Objekte blieben so lange im Speicher, bis man sie mit Release freigibt.

So muss ich durch Testen mit MemAlloced immer selber das ganze Zeug herausfinden. Unter Linux gab es z.B. bei vielen Memoryleaks, wo ich nicht weiß, ob ich dafür verantwortlich bin, oder ob dies ein Bug von BMax ist.

mfg olli

Edit: OK, das mit dem Destruktor ist ja eine gute Sache. Schade das man keine Parameter am Konstruktor übergeben kann.

vertex.dreamfall.at | GitHub

	stfighter01	So, Apr 17, 2005 18:46 Antworten mit Zitat
nein, so ist es nicht gedacht. der destruktor wird VOR der zerstörung aufgerufen. das ist so quasi eine 'abschiedsfunktion' das objekt selbst wird gelöscht, ob es nun einen destruktor besitzt od. nicht. man kann damit ein paar dinge regeln die halt nur dann auszuführen sind wenn das objekt verschwindet (z.b. aus einer linkedlist verkettung rausnehmen) und es ist GANZ GENAU festgelegt wann ein objekt verschwindet. angenommen du erstellt eine funktion u. diese bekommt eine lokale variable. ruft du die funktion das erste mal auf ist die var= null du speicherst etwas in der variable also referenziert sie auf ein objekt. nach dem verlassen der funktion ist die variable wieder undefiniert. u. somit referenziert sie auch dieses objekt nicht mehr. hast du den wert nicht zurückübergeben od. in irgendeiner globalen variable gespeichert od. sonst was, so wird das objekt beim nächsten flushmem gelöscht. andernfalls hat dieses objekt ja wieder eine neue referenz und muss bestehen bleiben. und wenn du dein objekt nicht übergeben, gespeichert od. sonst was hast, dann hast du auch keinen zugriff mehr auf das objekt u. es wäre daher ohnehin nutzlos (also toll wenn es gelöscht wird). in cpp müsstest du diese objekt in der funktion mit NEW allocieren und am ende bzw. vor jedem return mit DELETE löschen. diese ev. mehrfache löscharbeit sparts du dir hiermit. das ganze ist nicht chaotisch od. undurchschaubar. da du selbst flushmem aufrufen musst (hoffentlich fällt dies auch bald kannst du sogar GANZ GENAU wissen wann dein objekt zerstört wird. vielleicht verwechselst du das ganze auch ein bisschen mit den Blitzbasic types, auf welche du immer zugriff hast (z.b.: über for ... each) dort könnte dieses speichersystem nicht funktionieren. in Bmax hast du nur zugriff auf das objekt wenn du seine referenz darauf besitzt. [edit] mag sein das es Bmax bugs gibt, die memleaks verursachen. einer ist als (in der praxis eh nicht vorkommender) knownbug ja in der language referenz definiert. andere sind natürlich auch möglich, aber ich bin zuversichtlich das dieses problem sicher bald verschwindet u. sollte die entwicklung deiner progamme nicht behindern. [/edit] mfg stfighter
Denken hilft!

stfighter01

So, Apr 17, 2005 18:46
Antworten mit Zitat

nein, so ist es nicht gedacht.
der destruktor wird VOR der zerstörung aufgerufen.
das ist so quasi eine 'abschiedsfunktion' Wink

das objekt selbst wird gelöscht, ob es nun einen destruktor besitzt od. nicht.
man kann damit ein paar dinge regeln die halt nur dann auszuführen sind wenn das objekt verschwindet (z.b. aus einer linkedlist verkettung rausnehmen)

und es ist GANZ GENAU festgelegt wann ein objekt verschwindet.

angenommen du erstellt eine funktion u. diese bekommt eine lokale variable.

ruft du die funktion das erste mal auf ist die var= null
du speicherst etwas in der variable also referenziert sie auf ein objekt.
nach dem verlassen der funktion ist die variable wieder undefiniert.
u. somit referenziert sie auch dieses objekt nicht mehr.
hast du den wert nicht zurückübergeben od. in irgendeiner globalen variable gespeichert od. sonst was, so wird das objekt beim nächsten flushmem gelöscht.
andernfalls hat dieses objekt ja wieder eine neue referenz und muss bestehen bleiben.
und wenn du dein objekt nicht übergeben, gespeichert od. sonst was hast, dann hast du auch keinen zugriff mehr auf das objekt u. es wäre daher ohnehin nutzlos (also toll wenn es gelöscht wird).
in cpp müsstest du diese objekt in der funktion mit NEW allocieren und am ende bzw. vor jedem return mit DELETE löschen.
diese ev. mehrfache löscharbeit sparts du dir hiermit.
das ganze ist nicht chaotisch od. undurchschaubar.
da du selbst flushmem aufrufen musst (hoffentlich fällt dies auch bald Wink

kannst du sogar GANZ GENAU wissen wann dein objekt zerstört wird.

vielleicht verwechselst du das ganze auch ein bisschen mit den Blitzbasic types, auf welche du immer zugriff hast (z.b.: über for ... each)
dort könnte dieses speichersystem nicht funktionieren.
in Bmax hast du nur zugriff auf das objekt wenn du seine referenz darauf besitzt.

[edit]
mag sein das es Bmax bugs gibt, die memleaks verursachen.
einer ist als (in der praxis eh nicht vorkommender) knownbug ja in der language referenz definiert.
andere sind natürlich auch möglich, aber ich bin zuversichtlich das dieses problem sicher bald verschwindet u. sollte die entwicklung deiner progamme nicht behindern.
[/edit]

mfg stfighter

Denken hilft!

	Dreamora	So, Apr 17, 2005 22:05 Antworten mit Zitat
Selbst Blitz3D Types kann man relativ simpel rekonstruieren durch eine typeglobale liste: Code: [AUSKLAPPEN] [EINKLAPPEN] type test global _list:tlist method new () if _list = null _list = new tlist endif _list.addlast (self) end method method delete () _list.remove (self) end method method destroy () ' dient dem Falle, wo man explizit eine referenz löschen will _list.remove (self) end method end type Damit ist das alte verhalten von types vollständig rekonstruiert inklusive dem "delete" verhalten
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

So, Apr 17, 2005 22:05
Antworten mit Zitat

Selbst Blitz3D Types kann man relativ simpel rekonstruieren durch eine typeglobale liste:

Code: [AUSKLAPPEN]

type test
global _list:tlist

method new ()
if _list = null
_list = new tlist
endif
_list.addlast (self)
end method

method delete ()
_list.remove (self)
end method

method destroy ()
' dient dem Falle, wo man explizit eine referenz löschen will
_list.remove (self)
end method
end type

Damit ist das alte verhalten von types vollständig rekonstruiert inklusive dem "delete" verhalten

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

	Vertex	Mo, Apr 18, 2005 0:29 Antworten mit Zitat
OK, macht das ein wenig verständlicher. Finde jedoch, das soetwas essentielles in der Hilfe, sei sie noch so schlecht, nicht fehlen darf. Und ja, ich habe noch die New Delete Logik von BlitzClassic im Kopf. Zum Thema Engine: Beschäftige mich fleißig weiter mit allen Themen rund um 3D Engines. Werde sie auch ein wenig aus dem Low-Level- in den High-Level-Bereich heben, in dem einem auch Funktionen z. B. Erstellen von Lightmaps für Terrains bereitgestellt werden. Muss dennoch Entscheidungen in Sache C++ oder BMax mal fällen. BMax weil es noch kein gescheites 3D Modul gibt, und C++ weil ich da eingerostet bin, es für meine Zukunft brauche, ich davon ausgehe, das hier ein optimierterer Compiler im Einsatz ist und ich bis jetzt noch keine kostenlose gute IDE für BMax habe(Ganxta soll sich mal ranhalten. Bisherige Versionen von BlitzEdit waren noch ziemlich buggy ) mfg olli
vertex.dreamfall.at \| GitHub

Vertex

Mo, Apr 18, 2005 0:29
Antworten mit Zitat

OK, macht das ein wenig verständlicher. Finde jedoch, das soetwas essentielles in der Hilfe, sei sie noch so schlecht, nicht fehlen darf.

Und ja, ich habe noch die New Delete Logik von BlitzClassic im Kopf.

Zum Thema Engine: Beschäftige mich fleißig weiter mit allen Themen rund um 3D Engines. Werde sie auch ein wenig aus dem Low-Level- in den High-Level-Bereich heben, in dem einem auch Funktionen z. B. Erstellen von Lightmaps für Terrains bereitgestellt werden.

Muss dennoch Entscheidungen in Sache C++ oder BMax mal fällen. BMax weil es noch kein gescheites 3D Modul gibt, und C++ weil ich da eingerostet bin, es für meine Zukunft brauche, ich davon ausgehe, das hier ein optimierterer Compiler im Einsatz ist und ich bis jetzt noch keine kostenlose gute IDE für BMax habe(Ganxta soll sich mal ranhalten. Bisherige Versionen von BlitzEdit waren noch ziemlich buggy Smile

)

mfg olli

vertex.dreamfall.at | GitHub

	Dreamora	Mo, Apr 18, 2005 8:13 Antworten mit Zitat
BM hat einen genau so optimierten Compiler, da für Module GCC genutzt wird. Das ist insofern wirklich kein Grund. Was die IDE betrifft: http://www.onlinebubbles.com/blide/ Wenn dir das noch net ausreicht, hast du definitiv ein Problem oder bist MS geseucht ohne Ende Und voll auf C++ einsteigen sehe ich als einen Fehler, da die Sprache ausserhalb von Linux zum Tode verurteilt ist auf längere Sicht. Auf Apple wurde sie ja bereits beerdigt und MS hat mit C# / Managed C++ auch den Auslauf des regulären C++ eingeläutet. Würde mich von daher dringendstens an das Programmieren in managed umgebung (also mit Garbage Collector etc) eingewöhnen ... denke dazu ist BM garnicht mal so schlecht Auch wenn es noch 1 - 2 Macken hat (zb kannst du komplette Referenzringe aushängen die dann nicht freigegeben werden, da BM aktuell die Root Referenzen noch nicht überwacht), so ist es doch durch die Spielelastigkeit eine der "angenehmsten" Arten es zu erlernen
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mo, Apr 18, 2005 8:13
Antworten mit Zitat

BM hat einen genau so optimierten Compiler, da für Module GCC genutzt wird. Das ist insofern wirklich kein Grund.

Was die IDE betrifft: http://www.onlinebubbles.com/blide/
Wenn dir das noch net ausreicht, hast du definitiv ein Problem oder bist MS geseucht ohne Ende Wink

Und voll auf C++ einsteigen sehe ich als einen Fehler, da die Sprache ausserhalb von Linux zum Tode verurteilt ist auf längere Sicht. Auf Apple wurde sie ja bereits beerdigt und MS hat mit C# / Managed C++ auch den Auslauf des regulären C++ eingeläutet.

Würde mich von daher dringendstens an das Programmieren in managed umgebung (also mit Garbage Collector etc) eingewöhnen ... denke dazu ist BM garnicht mal so schlecht Smile

Auch wenn es noch 1 - 2 Macken hat (zb kannst du komplette Referenzringe aushängen die dann nicht freigegeben werden, da BM aktuell die Root Referenzen noch nicht überwacht), so ist es doch durch die Spielelastigkeit eine der "angenehmsten" Arten es zu erlernen Smile

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

	Vertex	Mo, Apr 18, 2005 12:56 Antworten mit Zitat
Arg, mein geliebtes C++ soll bald verschwinden? C# usw. bieten doch nicht die ausreichende Geschwindigkeit für Spiele. Und wegen Blide: Wahhhhhhnsinnn! Nach den Sceenshots zu urteilen, ist die IDE gerade zu ideal für mich. Wenn ich dann zu Hause bin, werde ich DreiDe komplett neu in Angriff nehmen. In BMax wohlgemerkt mfg olli
vertex.dreamfall.at \| GitHub

Vertex

Mo, Apr 18, 2005 12:56
Antworten mit Zitat

Arg, mein geliebtes C++ soll bald verschwinden? C# usw. bieten doch nicht die ausreichende Geschwindigkeit für Spiele.

Und wegen Blide: Wahhhhhhnsinnn! Nach den Sceenshots zu urteilen, ist die IDE gerade zu ideal für mich.

Wenn ich dann zu Hause bin, werde ich DreiDe komplett neu in Angriff nehmen. In BMax wohlgemerkt Smile

mfg olli

vertex.dreamfall.at | GitHub

	regaa	Mo, Apr 18, 2005 13:53 Antworten mit Zitat
Arrrr...., warum gab es blide nicht bevor ich mir Protean zugelegt hab?! btw: wahnsinn wie schnell du dich in gewisse Themenbereiche einarbeiten kannst. Hast du Mark mal gefragt ob BNet offiziel in den Pub Ordner wandern darf?
UltraMixer Professional 3 - Download QB,HTML,CSS,JS,PHP,SQL,>>B2D,B3D,BP,BlitzMax,C,C++,Java,C#,VB6 , C#, VB.Net

regaa

Mo, Apr 18, 2005 13:53
Antworten mit Zitat

Arrrr...., warum gab es blide nicht bevor ich mir Protean zugelegt hab?!

btw: wahnsinn wie schnell du dich in gewisse Themenbereiche einarbeiten kannst.

Hast du Mark mal gefragt ob BNet offiziel in den Pub Ordner wandern darf?

UltraMixer Professional 3 - Download
QB,HTML,CSS,JS,PHP,SQL,>>B2D,B3D,BP,BlitzMax,C,C++,Java,C#,VB6 , C#, VB.Net

	Suco-X Betreff: ........	Mo, Apr 18, 2005 14:02 Antworten mit Zitat
Hi Ich arbeite schon länger mit Blide. Bis auf paar Bugs die es noch gibt, wirklich optimal die IDE. War schon in der Alpha sehr stabil. Mittlerweile ja beta. Natürlich wird noch das Net Framework(Bye bye Modem lahmers) benötigt. Aber für die kurze Entwicklungszeit kann man den Macher nur loben. Mal schauen was noch draus wird. Mfg Suco
Intel Core 2 Quad Q8300, 4× 2500 MHz, 4096 MB DDR2-Ram, GeForce 9600GT 512 MB

Suco-X

Betreff: ........

Mo, Apr 18, 2005 14:02
Antworten mit Zitat

Hi
Ich arbeite schon länger mit Blide. Bis auf paar Bugs die es noch gibt, wirklich optimal die IDE. War schon in der Alpha sehr stabil. Mittlerweile ja beta. Natürlich wird noch das Net Framework(Bye bye Modem lahmers) benötigt.
Aber für die kurze Entwicklungszeit kann man den Macher nur loben.
Mal schauen was noch draus wird.
Mfg Suco

Intel Core 2 Quad Q8300, 4× 2500 MHz, 4096 MB DDR2-Ram, GeForce 9600GT 512 MB

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

Übersicht

BlitzMax, BlitzMax NG

Allgemein

Nach Oben

BlitzBasic Portal

3D Modul - Ideen/Vorschläge

Betreff: ........