Grafik Engine

Übersicht

BlitzBasic

Blitz3D

Gehe zu Seite Zurück 1, 2, 3

	Dreamora	Fr, Aug 04, 2006 19:30 Antworten mit Zitat
Du hast da einige schwerwiegende Denkfehler: 1. "und diese Kugeln vielleicht sogar mit Gebäude kollidieren" Es werden, abgesehen von Granaten und Raketen, nie Projektile verschossen sondern ein LinePick gemacht, da eine Kugel mit 300-900m/s fliegt und für jedes normale Lebewesen unsichtbar ist! Vielleicht ein Grund für deine Performance Probleme 2. Gutes Aussehen != viele Polygone. Selbst die Unreal 2 Engine kann nur 5000-6000 Polygone auf animierten Objekten schlucken. Und da gebe ich gleich mitzubedenken: Diese werden von der GPU animiert! In Blitz werden sie von der CPU animiert, was einerseits langsamer ist und anderseits auch viel mehr zeit braucht weils von der CPU wieder an die GPU gesandt werden muss. Ich gebe dir aber recht, speed ist wichtig. Deswegen ist ein einigermassen realistisches Spieldesign von elementarer bedeutung. Und deswegen sollte man sich auch auf etwas stürzen was mit den eigenen Fähigkeiten harmonisiert ... Dir fehlt, so scheint es mir zumindest, einfach in einem ziemlich umfangreichen Masse das Wissen von 3D Programmierung, wie das mit Objekten, Animation etc hardwareseitig funktioniert. Insofern kann ich dir nur raten erst einmal die Grundlagen für dein spiel zu schreiben bevor du an etwas ran willst was so knapp 20 professionelle, erfahrene Programmierteams auf der Welt in einem gescheiten Mass bisher hinbekommen haben! (und wofür selbst die bei vollzeit arbeit monate gebraucht haben)
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Fr, Aug 04, 2006 19:30
Antworten mit Zitat

Du hast da einige schwerwiegende Denkfehler:

1. "und diese Kugeln vielleicht sogar mit Gebäude kollidieren"

Es werden, abgesehen von Granaten und Raketen, nie Projektile verschossen sondern ein LinePick gemacht, da eine Kugel mit 300-900m/s fliegt und für jedes normale Lebewesen unsichtbar ist!
Vielleicht ein Grund für deine Performance Probleme

2. Gutes Aussehen != viele Polygone.
Selbst die Unreal 2 Engine kann nur 5000-6000 Polygone auf animierten Objekten schlucken. Und da gebe ich gleich mitzubedenken: Diese werden von der GPU animiert! In Blitz werden sie von der CPU animiert, was einerseits langsamer ist und anderseits auch viel mehr zeit braucht weils von der CPU wieder an die GPU gesandt werden muss.

Ich gebe dir aber recht, speed ist wichtig.
Deswegen ist ein einigermassen realistisches Spieldesign von elementarer bedeutung.
Und deswegen sollte man sich auch auf etwas stürzen was mit den eigenen Fähigkeiten harmonisiert ... Dir fehlt, so scheint es mir zumindest, einfach in einem ziemlich umfangreichen Masse das Wissen von 3D Programmierung, wie das mit Objekten, Animation etc hardwareseitig funktioniert. Insofern kann ich dir nur raten erst einmal die Grundlagen für dein spiel zu schreiben bevor du an etwas ran willst was so knapp 20 professionelle, erfahrene Programmierteams auf der Welt in einem gescheiten Mass bisher hinbekommen haben! (und wofür selbst die bei vollzeit arbeit monate gebraucht haben)

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

	X0r	Fr, Aug 04, 2006 19:53 Antworten mit Zitat
Du hast Recht. Ich mache einen zu großen Aufstand. Ich denke, ich bin blöd und bekomme das nicht mit dem speed auf die Reihe und versuche mich immer wieder mit Valve oder Rockstar zu vergleichen, was natürlich Unsinn ist. Sie haben bestimmt ein Studium, arbeiten mit C++(Wozu sie jahrelang studieren mussten) und dazu noch im Team. Zum Shooter: Ich habe das immer mit Kugeln gemacht. Hmm, vielleicht wurde das Spiel deswegen immer langsamer. Ich guck mal im code nach, vielleicht habe ich vergessen sie vom Speicher löschen. Also, zu meinem 3D Wissen: Das einzige, wo ich eine Null bin und womit ich mich noch garnicht beschäftigt habe sind diese vertexes, Polygone(Was ja das gleiche ist?!). Ich lade einfach nur die Objekte, dann haue ich die waffe an die Kamera und los gehts. Mit diesem Surfacesverstecken und so habe ich mich noch nie beschäftigt. Aber was ist mit einer neuen 3D Engine und DirectX? Naja, ich glaube ich muss erst mal mit jemandem zusammen arbeiten. Immerhin, wo ich jetzt so denke, haben an GTA SA auch bestimmt so ca. 7-20 Leute gearbeitet. Hätte jemand Lust mit mir einen Ego Shooter zu machen? (Models wären kein Problem)

X0r

Fr, Aug 04, 2006 19:53
Antworten mit Zitat

Du hast Recht. Ich mache einen zu großen Aufstand. Ich denke, ich bin blöd und bekomme das nicht mit dem speed auf die Reihe und versuche mich immer wieder mit Valve oder Rockstar zu vergleichen, was natürlich Unsinn ist. Sie haben bestimmt ein Studium, arbeiten mit C++(Wozu sie jahrelang studieren mussten) und dazu noch im Team.

Zum Shooter: Ich habe das immer mit Kugeln gemacht. Hmm, vielleicht wurde das Spiel deswegen immer langsamer. Ich guck mal im code nach, vielleicht habe ich vergessen sie vom Speicher löschen.

Also, zu meinem 3D Wissen:
Das einzige, wo ich eine Null bin und womit ich mich noch garnicht beschäftigt habe sind diese vertexes, Polygone(Was ja das gleiche ist?!). Ich lade einfach nur die Objekte, dann haue ich die waffe an die Kamera und los gehts. Mit diesem *Surfacesverstecken* und so habe ich mich noch nie beschäftigt.

Aber was ist mit einer neuen 3D Engine und DirectX?

Naja, ich glaube ich muss erst mal mit jemandem zusammen arbeiten. Immerhin, wo ich jetzt so denke, haben an GTA SA auch bestimmt so ca. 7-20 Leute gearbeitet.
Hätte jemand Lust mit mir einen Ego Shooter zu machen?
(Models wären kein Problem)

	Dreamora	Fr, Aug 04, 2006 20:00 Antworten mit Zitat
Selbst die Unreal 2007 Engine würde das Problem nicht entschärfen wenn du sie so benutzt wie bis anhin. Was das löschen betrifft: Sehr viele New und Delete mit Types können zu ernsthaften Speedproblemen führen. Darüber hinaus ist es die reine "Objektanzahl" die ihren Einfluss hat (wenn du Kollision dann auch noch drin hast: Gute nacht, das muss schon fast grundsätzlich langsam werden weil zig hundert objekte im extremfall getestet werden müssen) 3D Wissen: ich meinte eigentlich nicht solches Grundwissen. Das sollte man Prinzipiell eigentlich schon haben wenn man mehr als ein springendes Bällchen oder so machen will. Dieses wissen würde dich mit deinem geplanten Ziel kein Stückchen weit bringen. Was ich meinte ist noch um einiges höher und erfordert das du auch eine gewisse Ahnung hast wie Grafikkarten arbeiten und wie DirectX arbeitet. Ohne dieses Wissen ist das nämlich nicht sinnvoll machbar, da du garnicht wissen kannst was "besser" überhaupt heissen soll bzw. was eine "optimalere Lösung" / effizientere Lösung für ein Problem ist. Blitz gibt dir zwar so einiges an möglichkeiten. Aber wenn du komplexere Dinge machen willst kommst du nicht drumrum auch das "dahinter" verstehen zu lernen. -> Vertices, Polygone, Surfaces, Culling, SceneGraphs (würde dir empfehlen, einen Quad oder OctTree zu implementieren für dein geplantes Spiel) und natürlich setze ich blind eine gewisse Ahnung von Datenstrukturen und Algorithmen voraus, da dies das grundlegende Werkzeug ist überhaupt etwas effizient lösen zu können. Und dein problem wird eine ziemlich effiziente Lösung brauchen. Und es sagt niemand das du blöd bist. Aber was glaub ziemlich klar ist, ist das du etwas machen willst, was mehrere Level über deinem aktuellen Können liegt und unabhängig von Sprache und Engine NICHT klappen kann und wird.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Fr, Aug 04, 2006 20:00
Antworten mit Zitat

Selbst die Unreal 2007 Engine würde das Problem nicht entschärfen wenn du sie so benutzt wie bis anhin.

Was das löschen betrifft: Sehr viele New und Delete mit Types können zu ernsthaften Speedproblemen führen.
Darüber hinaus ist es die reine "Objektanzahl" die ihren Einfluss hat (wenn du Kollision dann auch noch drin hast: Gute nacht, das muss schon fast grundsätzlich langsam werden weil zig hundert objekte im extremfall getestet werden müssen)

3D Wissen: ich meinte eigentlich nicht solches Grundwissen. Das sollte man Prinzipiell eigentlich schon haben wenn man mehr als ein springendes Bällchen oder so machen will. Dieses wissen würde dich mit deinem geplanten Ziel kein Stückchen weit bringen.

Was ich meinte ist noch um einiges höher und erfordert das du auch eine gewisse Ahnung hast wie Grafikkarten arbeiten und wie DirectX arbeitet. Ohne dieses Wissen ist das nämlich nicht sinnvoll machbar, da du garnicht wissen kannst was "besser" überhaupt heissen soll bzw. was eine "optimalere Lösung" / effizientere Lösung für ein Problem ist.

Blitz gibt dir zwar so einiges an möglichkeiten. Aber wenn du komplexere Dinge machen willst kommst du nicht drumrum auch das "dahinter" verstehen zu lernen.

-> Vertices, Polygone, Surfaces, Culling, SceneGraphs (würde dir empfehlen, einen Quad oder OctTree zu implementieren für dein geplantes Spiel) und natürlich setze ich blind eine gewisse Ahnung von Datenstrukturen und Algorithmen voraus, da dies das grundlegende Werkzeug ist überhaupt etwas effizient lösen zu können. Und dein problem wird eine ziemlich effiziente Lösung brauchen.

Und es sagt niemand das du blöd bist. Aber was glaub ziemlich klar ist, ist das du etwas machen willst, was mehrere Level über deinem aktuellen Können liegt und unabhängig von Sprache und Engine NICHT klappen kann und wird.

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

	X0r	Fr, Aug 04, 2006 20:10 Antworten mit Zitat
http://ultimative.ul.ohost.de/...=games.php Komm, sooo noobig ist das "Spiel" auch nicht(Testspiel, nicht vergessen). Vielleicht ist die Physik nicht die beste, aber immerhin. Naja, du sagst hier jetzt groß DirectX hier und da und verwende anderes ZEug und mach dies und das und ...H a l t. Mit B3D kann ich leider nicht wie in C++ DirectX direkt ansprechen. Das macht er ja selber. Ich sage Plot x,y , der sagt es dem DirectX weiter und der "macht" das ganze Zeug in Zusammenarbeit mit CPU, Ram und und und. Also, ich kann wirklich nichts dafür, wenn ich mit DirectX 7 arbeiten muss. Tut mir Leid. Und was reg ich mich eigentlich auf? Ich habe bisher selber noch icht mal ein sehr gutes B3D Ego Shooter Spiel gesehen, dass nicht nur sau miese Grafik hat, sondern noch sau schnell ist, indem die KI schon fast perfekt ist und die Effekte erst monstermäßig sind. Daaaa muss man doch mit C++ arbeiten. Aber C++ alleine ist nicht. Das habe ich nach gut einem Jahr bemerkt. Dreamora, was du mir mit deinem Du-bist-ein-Unterlevel-Programmierer sagen willst ist bestimmt, dass ich nicht so gut tricksen kann, oder? du meinst bestimmt, dass ich alles so haben will, wie ich es will und auch alles so klappen, wie ich es will, ohne dass ich groß rummachen muss. Ich denke, faulheit ist eines meiner Probleme. Naja, ich werd es versuchen.

X0r

Fr, Aug 04, 2006 20:10
Antworten mit Zitat

http://ultimative.ul.ohost.de/...=games.php
Komm, sooo noobig ist das "Spiel" auch nicht(Testspiel, nicht vergessen). Vielleicht ist die Physik nicht die beste, aber immerhin.

Naja, du sagst hier jetzt groß DirectX hier und da und verwende anderes ZEug und mach dies und das und ...H a l t. Mit B3D kann ich leider nicht wie in C++ DirectX direkt ansprechen. Das macht er ja selber. Ich sage Plot x,y , der sagt es dem DirectX weiter und der "macht" das ganze Zeug in Zusammenarbeit mit CPU, Ram und und und.
Also, ich kann wirklich nichts dafür, wenn ich mit DirectX 7 arbeiten muss. Tut mir Leid.

Und was reg ich mich eigentlich auf? Ich habe bisher selber noch icht mal ein sehr gutes B3D Ego Shooter Spiel gesehen, dass nicht nur sau miese Grafik hat, sondern noch sau schnell ist, indem die KI schon fast perfekt ist und die Effekte erst monstermäßig sind.
Daaaa muss man doch mit C++ arbeiten. Aber C++ alleine ist nicht. Das habe ich nach gut einem Jahr bemerkt.

Dreamora, was du mir mit deinem Du-bist-ein-Unterlevel-Programmierer sagen willst ist bestimmt, dass ich nicht so gut tricksen kann, oder? du meinst bestimmt, dass ich alles so haben will, wie ich es will und auch alles so klappen, wie ich es will, ohne dass ich groß rummachen muss.
Ich denke, faulheit ist eines meiner Probleme. Naja, ich werd es versuchen.

	BladeRunner Moderator	Fr, Aug 04, 2006 20:45 Antworten mit Zitat
Das Problem ist nicht dass Du mit DX7 arbeiten musst sondern dass Du nicht in der Lage bist DX7 effizient auszunutzen. Daran würde auch DX8 oder 9 nix ändern. Im Gegenteil- da gibts nur noch mehr Schnickschnack mit dem man die Karte in die Knie zwingen kann. Genau das "Tricksen" macht aus Deinem Game das meiste. Ein guter Shooter ist schon auf dem Papier nach Gesichtspunkten der Leveloptimierung verfasst. Und dass die meisten B3D- Projekte eher Amateurmäßig daher kommen liegt wohl daran dass B3D von Amateuren benutzt wird. Es ist eine Sprache für Hobbycoder. Dennoch lässt sich damit erstaunliches erzeugen. Lerne die Grundtechniken (Leveloptimierung, Quadtrees etc, nochmal schreib ichs nicht). Dann wirst Du auch mit BB vieles erreichen. Ich behaupte mal dass bis auf ein oder zwei Cracks hier (und ich meine nicht mich) keiner in der Lage ist B3D auch nur Ansatzweise auszunutzen. Dazu sind Jahrelange Erfahrung, passendes Talent und auch viel Fleiss vonnöten. Mehr als die meisten Hobbycoder zu investieren bereit sind.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Fr, Aug 04, 2006 20:45
Antworten mit Zitat

Das Problem ist nicht dass Du mit DX7 arbeiten musst sondern dass Du nicht in der Lage bist DX7 effizient auszunutzen. Daran würde auch DX8 oder 9 nix ändern. Im Gegenteil- da gibts nur noch mehr Schnickschnack mit dem man die Karte in die Knie zwingen kann.
Genau das "Tricksen" macht aus Deinem Game das meiste. Ein guter Shooter ist schon auf dem Papier nach Gesichtspunkten der Leveloptimierung verfasst.
Und dass die meisten B3D- Projekte eher Amateurmäßig daher kommen liegt wohl daran dass B3D von Amateuren benutzt wird. Es ist eine Sprache für Hobbycoder. Dennoch lässt sich damit erstaunliches erzeugen.
Lerne die Grundtechniken (Leveloptimierung, Quadtrees etc, nochmal schreib ichs nicht). Dann wirst Du auch mit BB vieles erreichen.

Ich behaupte mal dass bis auf ein oder zwei Cracks hier (und ich meine nicht mich) keiner in der Lage ist B3D auch nur Ansatzweise auszunutzen.
Dazu sind Jahrelange Erfahrung, passendes Talent und auch viel Fleiss vonnöten.
Mehr als die meisten Hobbycoder zu investieren bereit sind.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	X0r	Fr, Aug 04, 2006 20:52 Antworten mit Zitat
Ich glaube ich weiß jetzt, woran es mit dem speed lag. Bisher habe ich alles mit types und fields gemacht(Also Häuser, Dekoration,..) und allen immer die selbe ID für die Kollision gegeben. Also collisions type_buildings,type_scene,2,3 . Kann das der Fehler sein? Dann muss ich das eben mit einem WorldEditor machen. Was meinen Sie? Lieber alles als einzelne entities oder lieber alles als ein mesh mit einem worldeditor? Und im Moment programmierer ich eigentlich nur Applikationen, wie man auf meine website schwer sehen kann. Dachte immer, das mit Spiele muss man teamweise machen. Aber versuche es mal alleine.

X0r

Fr, Aug 04, 2006 20:52
Antworten mit Zitat

Ich glaube ich weiß jetzt, woran es mit dem speed lag. Bisher habe ich alles mit types und fields gemacht(Also Häuser, Dekoration,..) und allen immer die selbe ID für die Kollision gegeben. Also
collisions type_buildings,type_scene,2,3 .
Kann das der Fehler sein? Dann muss ich das eben mit einem WorldEditor machen.
Was meinen Sie? Lieber alles als einzelne entities oder lieber alles als ein mesh mit einem worldeditor?

Und im Moment programmierer ich eigentlich nur Applikationen, wie man auf meine website schwer sehen kann. Dachte immer, das mit Spiele muss man teamweise machen. Aber versuche es mal alleine.

	BladeRunner Moderator	Fr, Aug 04, 2006 21:04 Antworten mit Zitat
Es gibt keine allgemeingültige Aussage darüber was in ein Mesh soll und was in einzelne Entities. Die Frage was wo rein gehört ist sehr spezifisch vom content abhängig. Prinzipiell würde ich versuchen möglichst viele Surfaces einzusparen. Allerdings muss hier ein Kompromiss gezogen werden, denn wenn Du nur noch ein riesiges Mesh hast auf einer Surface wird das auch immer komplett berechnet, wenn auch nur ein Poly auf dem Schirm ist. Geschicktes design (verwinkelte Gänge zwischen einzelnen Abschnitten etc. hilft hier passsend grosse Meshes zu erstellen. Animierte Figuren bieten sich natürlich als entity an. Und: polys reduzieren wo es nur geht. ein einzelner Vertice belegt locker mal 44 Byte auf der Graka, und du hast noch nicht mal ein Poly angezeigt.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Fr, Aug 04, 2006 21:04
Antworten mit Zitat

Es gibt keine allgemeingültige Aussage darüber was in ein Mesh soll und was in einzelne Entities. Die Frage was wo rein gehört ist sehr spezifisch vom content abhängig. Prinzipiell würde ich versuchen möglichst viele Surfaces einzusparen. Allerdings muss hier ein Kompromiss gezogen werden, denn wenn Du nur noch ein riesiges Mesh hast auf einer Surface wird das auch immer komplett berechnet, wenn auch nur ein Poly auf dem Schirm ist.
Geschicktes design (verwinkelte Gänge zwischen einzelnen Abschnitten etc. hilft hier passsend grosse Meshes zu erstellen.
Animierte Figuren bieten sich natürlich als entity an.
Und: polys reduzieren wo es nur geht.
ein einzelner Vertice belegt locker mal 44 Byte auf der Graka, und du hast noch nicht mal ein Poly angezeigt.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	Dreamora	Fr, Aug 04, 2006 21:07 Antworten mit Zitat
Weder noch Für die Kollision gibts einige einfache Grundregeln: 1. Dinge die keine Kollision benötigen weil sie das Spielgefühl nicht ändern, bekommen keine 2. Schüsse etc bekommen normalerweise auch keine. Zieht exorbitant an der Performance (musst immer bedenken, du bist nicht der einzige der schiesst und du kannst mehr als 1 Schuss abfeuern) und bringt rein garnichts. LinePick nehmen um allfällige Kollisionspunkte zu finden, dort ein Einschusslochdecal platzieren und wenn du willst noch einen "Verputz-Wegsplitter-Emitter" setzen. Mehr brauchts für die meisten Waffen nicht. 3. Komplexere Objekte erhalten unsichtbare Objekte (alpha 0) angehängt die eine viel einfachere Struktur haben und welches sie "umschliesst". Dieses wird dann für die Kollision genutzt, nicht die Grundobjekte 4. Level sollten prinzipiell nicht vor komplexer Geometrie strotzen (von der Deko abgesehen), denn es bringt nicht sonderlich viel 5. Für Shooter die in Häuser und ähnlich (Counter Strike like) spielen, würde ich sehr dazu raten, BSP zu benutzen. Für grössere Dinge mit Aussenbereichen und so musst du dir einen OctTree SceneGraphen schreiben (oder QuadTree wenn es keine wirkliche Aktion über / unter der normalen Bewegungsebene gibt, also das ganze relativ planar ist) Ansonsten wurden dir schon sehr viele Tipps gegeben hier. Das Problem ist und ich weiss das klingt hart, aber: Deinen bisherigen Code wirste wohl zum grössten Teil wegwerfen müssen. Denn der Code mag für einen normalen Shooter irgendwo noch funktioniert haben weil dort sonst nichts an der Performance zog. Nur änderst du die Anforderungen so drastisch, dass er es leider nicht mehr mit macht. Das ist der Preis von "speziellem" Code ... er ist leider nicht allgemein nutzbar. Aber das gibt dir auch die ausserordentlich praktische Chance Papier und Stift zur Hand zu nehmen und dein Handlingsystem von Grund auf für deine Bedürfsnisse zu strukturieren. Allerdings: Informiere dich erst über QuadTree / OctTree und implementiere dir einen solchen! Denn dann kannst du so einiges was du dir überlegst gleich im zusammenhang mit diesem Überlegen! Und das wird dir so einiges stark vereinfachen. (sagen wir als sehr gutes beispiel blockweise laden / entladen der welt indem du einen OctBlock lädst und die Map auch in solchen blöcken speicherst in deinem eigenen Format) Denn es wird alles an dieser Struktur später hängen: Partikel Effekte, hiden und deaktivieren von Objekten / KI in Zonen die nicht in absehbarer Zeit von bedeutung sind. (es macht keinen sinn die zu rechnen wenn der spieler in frühstens 30s dort sein könnte. Dann kann man das auch 3-5s vor dem eintreffen rasch machen. Und Kollision und MeshAnimation muss dort schon garnicht geprüft werden. Letzteres wird auch durch HideEntity deaktiviert!) Oh und natürlich über die erlaubten Meshdaten Gedanken machen. Ist ein Mesh animiert? Wenn ja, wieviele Bones soll es haben (denn je mehr bones, desto weniger Vertices kannst du haben) Ist ein Mesh statisch? wenn ja, dann stehen nämlich viel mehr vertices zur verfügung. Allerdings kann man dann aber auch mit einer guten Textur sehr viel machen! Und lauter solcher Dinge halt. Die gehen zu diesem Zeitpunkt so viel einfacher, als wenn schon ein fixes System steht und sollten bei einem grösseren Projekt prinzipiell auch zu diesem Zeitpunkt festgelegt werden ...
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Fr, Aug 04, 2006 21:07
Antworten mit Zitat

Weder noch

Für die Kollision gibts einige einfache Grundregeln:

1. Dinge die keine Kollision benötigen weil sie das Spielgefühl nicht ändern, bekommen keine

2. Schüsse etc bekommen normalerweise auch keine. Zieht exorbitant an der Performance (musst immer bedenken, du bist nicht der einzige der schiesst und du kannst mehr als 1 Schuss abfeuern) und bringt rein garnichts. LinePick nehmen um allfällige Kollisionspunkte zu finden, dort ein Einschusslochdecal platzieren und wenn du willst noch einen "Verputz-Wegsplitter-Emitter" setzen. Mehr brauchts für die meisten Waffen nicht.

3. Komplexere Objekte erhalten unsichtbare Objekte (alpha 0) angehängt die eine viel einfachere Struktur haben und welches sie "umschliesst". Dieses wird dann für die Kollision genutzt, nicht die Grundobjekte

4. Level sollten prinzipiell nicht vor komplexer Geometrie strotzen (von der Deko abgesehen), denn es bringt nicht sonderlich viel

5. Für Shooter die in Häuser und ähnlich (Counter Strike like) spielen, würde ich sehr dazu raten, BSP zu benutzen. Für grössere Dinge mit Aussenbereichen und so musst du dir einen OctTree SceneGraphen schreiben (oder QuadTree wenn es keine wirkliche Aktion über / unter der normalen Bewegungsebene gibt, also das ganze relativ planar ist)

Ansonsten wurden dir schon sehr viele Tipps gegeben hier.
Das Problem ist und ich weiss das klingt hart, aber: Deinen bisherigen Code wirste wohl zum grössten Teil wegwerfen müssen. Denn der Code mag für einen normalen Shooter irgendwo noch funktioniert haben weil dort sonst nichts an der Performance zog. Nur änderst du die Anforderungen so drastisch, dass er es leider nicht mehr mit macht. Das ist der Preis von "speziellem" Code ... er ist leider nicht allgemein nutzbar.

Aber das gibt dir auch die ausserordentlich praktische Chance Papier und Stift zur Hand zu nehmen und dein Handlingsystem von Grund auf für deine Bedürfsnisse zu strukturieren.
Allerdings: Informiere dich erst über QuadTree / OctTree und implementiere dir einen solchen! Denn dann kannst du so einiges was du dir überlegst gleich im zusammenhang mit diesem Überlegen!
Und das wird dir so einiges stark vereinfachen. (sagen wir als sehr gutes beispiel blockweise laden / entladen der welt indem du einen OctBlock lädst und die Map auch in solchen blöcken speicherst in deinem eigenen Format)

Denn es wird alles an dieser Struktur später hängen: Partikel Effekte, hiden und deaktivieren von Objekten / KI in Zonen die nicht in absehbarer Zeit von bedeutung sind. (es macht keinen sinn die zu rechnen wenn der spieler in frühstens 30s dort sein könnte. Dann kann man das auch 3-5s vor dem eintreffen rasch machen. Und Kollision und MeshAnimation muss dort schon garnicht geprüft werden. Letzteres wird auch durch HideEntity deaktiviert!)

Oh und natürlich über die erlaubten Meshdaten Gedanken machen.

Ist ein Mesh animiert? Wenn ja, wieviele Bones soll es haben (denn je mehr bones, desto weniger Vertices kannst du haben)

Ist ein Mesh statisch? wenn ja, dann stehen nämlich viel mehr vertices zur verfügung. Allerdings kann man dann aber auch mit einer guten Textur sehr viel machen!

Und lauter solcher Dinge halt.
Die gehen zu diesem Zeitpunkt so viel einfacher, als wenn schon ein fixes System steht und sollten bei einem grösseren Projekt prinzipiell auch zu diesem Zeitpunkt festgelegt werden ...

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

	Willi die Rübe	Fr, Aug 04, 2006 21:24 Antworten mit Zitat
Nein, das kann nicht der Fehler sein, denn durch Kollision werden Vertices und Poly's auch nicht reduziert. Dein Problem ist, dass du nachwievor immer noch denkst, dass mehr Vertices&Poly's schöner und professioneller aussehen. Wie BladeRunner schon gesagt hat, kann mit Texturen aber auch den Detailgrad steigern. Code doch erstmal mit ein par Dummys und erst wenn dann dein Code auch funktioniert wie er funktionieren soll, kannst du die Grafik "aufpeppen". Ich arbeite momentan auch an einem Egoshooter, genaugenommen einem Half-Life 1 Clon. Die Grundengine ist schon fast komplett fertig und ich arbeite immer noch mit Meshs aus den Blitz3D Samples. D.h. auch mit unschönen Lowpoly Models lässt es sich Coden. Und als Anmerkung: Ich bin auch 14 Und nur als Info: Ein Mesh besteht aus Surfaces. Eine Surface ( zu Deutsch: Oberfläche ) besteht aus Polygonen auch TriAngles gennant. Ein Polygon besteht aus 3 Vertices. Und ein Vertex ist einfach nur ein Eckpunkt. Also wenn du eine andere 3D Engine suchst und ein bisschen C++ kannst, wäre vllt. BlitzMax+3Impact das Richtige für dich ( http://www.3impact.com ).
Ich habe keine Lösung, aber ich bewundere das Problem. Tehadon Q6600, MSI Neo2-FR, 4GB Ram, nVidia 7800 GTX At the Farewell Party visit: MySpace \| Homepage

Willi die Rübe

Fr, Aug 04, 2006 21:24
Antworten mit Zitat

Nein, das kann nicht der Fehler sein, denn durch Kollision werden Vertices und Poly's auch nicht reduziert. Dein Problem ist, dass du nachwievor immer noch denkst, dass mehr Vertices&Poly's schöner und professioneller aussehen. Wie BladeRunner schon gesagt hat, kann mit Texturen aber auch den Detailgrad steigern. Code doch erstmal mit ein par Dummys und erst wenn dann dein Code auch funktioniert wie er funktionieren soll, kannst du die Grafik "aufpeppen".

Ich arbeite momentan auch an einem Egoshooter, genaugenommen einem Half-Life 1 Clon. Die Grundengine ist schon fast komplett fertig und ich arbeite immer noch mit Meshs aus den Blitz3D Samples. D.h. auch mit unschönen Lowpoly Models lässt es sich Coden.
Und als Anmerkung: Ich bin auch 14

Und nur als Info:
Ein Mesh besteht aus Surfaces. Eine Surface ( zu Deutsch: Oberfläche ) besteht aus Polygonen auch TriAngles gennant. Ein Polygon besteht aus 3 Vertices. Und ein Vertex ist einfach nur ein Eckpunkt.

Also wenn du eine andere 3D Engine suchst und ein bisschen C++ kannst, wäre vllt. BlitzMax+3Impact das Richtige für dich ( http://www.3impact.com ).

Ich habe keine Lösung, aber ich bewundere das Problem.
Tehadon
Q6600, MSI Neo2-FR, 4GB Ram, nVidia 7800 GTX
At the Farewell Party visit: MySpace | Homepage

	X0r	Fr, Aug 04, 2006 21:30 Antworten mit Zitat
Hä? Ich soll die Kollidierungsprüfung zweier Objekte nochmal prüfen? Ich glaube nicht das das nötig ist. Jaa, Half Life 1 hat aber auch nicht die beste Grafik(Kein Wunder. Ist von 1992-1996?). Aber ich will etwas mit fetter Grafik machen. Das geht wohl mit B3D nicht. Gib es zu!! Jede Sprache hat Macken. Och man. Jetzt habe ich das Teil extra gekauft und hab jetzt keine Lust das wegzuschmeißen. Jetzt sagt einer: Ein intelligenter Mensch hätte es erst getestet. Antwort: Ja habe ich doch! Nur da hatte ich nicht so auf speed geachtet, da man mit 16 KB nicht wirklich einen Ego Shooter schreiben kann. Ist doch jetzt gut, Mensch. Ich fang erstmal an. Versuch es so fett wie möglich zu machen, versuche eine gute Physik Engine und und und zu machen und wenn weitere Probleme auftreten, was so ziemlich der Fall sein wird, dann wende ich mich wieder an euch hier in diesem thread.

X0r

Fr, Aug 04, 2006 21:30
Antworten mit Zitat

Hä? Ich soll die Kollidierungsprüfung zweier Objekte nochmal prüfen? Ich glaube nicht das das nötig ist.

Jaa, Half Life 1 hat aber auch nicht die beste Grafik(Kein Wunder. Ist von 1992-1996?). Aber ich will etwas mit fetter Grafik machen. Das geht wohl mit B3D nicht. Gib es zu!! Jede Sprache hat Macken.

Och man. Jetzt habe ich das Teil extra gekauft und hab jetzt keine Lust das wegzuschmeißen.
Jetzt sagt einer: Ein intelligenter Mensch hätte es erst getestet.
Antwort: Ja habe ich doch! Nur da hatte ich nicht so auf speed geachtet, da man mit 16 KB nicht wirklich einen Ego Shooter schreiben kann.

Ist doch jetzt gut, Mensch. Ich fang erstmal an. Versuch es so fett wie möglich zu machen, versuche eine gute Physik Engine und und und zu machen und wenn weitere Probleme auftreten, was so ziemlich der Fall sein wird, dann wende ich mich wieder an euch hier in diesem thread.

	Lunatix	Fr, Aug 04, 2006 21:50 Antworten mit Zitat
Wozu fette GFX? Ich zum bleistift liebe die grafik aus Quake III Arena, das war damals was neues, das war damals auch "fette" gfx! Viele neue games haben eine Hammer GFX.... toll, aber was ist mit der spielgeschichte? dem sound? dem Gameplay? Es iwrd immer an fetter gfx gearbeited, dafür dann aber an den falschen enden gespart! Das ist das problem. Mit DX7 kann man wunderbar ein Quake III Arena machen, man muss nur wissen wie...
[size=9]Pro\|gram\|mier\|er: Ein Organismus, der Koffein in Software umwandelt. Geben Sie eine beliebige 11-stellige Primzahl ein, um fortzusetzen...

Lunatix

Fr, Aug 04, 2006 21:50
Antworten mit Zitat

Wozu fette GFX?

Ich zum bleistift liebe die grafik aus Quake III Arena, das war damals was neues, das war damals auch "fette" gfx!

Viele neue games haben eine Hammer GFX.... toll, aber was ist mit der spielgeschichte? dem sound? dem Gameplay?
Es iwrd immer an fetter gfx gearbeited, dafür dann aber an den falschen enden gespart!

Das ist das problem. Mit DX7 kann man wunderbar ein Quake III Arena machen, man muss nur wissen wie...

[size=9]Pro|gram|mier|er: Ein Organismus, der Koffein in Software umwandelt.
Geben Sie eine beliebige 11-stellige Primzahl ein, um fortzusetzen...

	Dreamora	Fr, Aug 04, 2006 22:07 Antworten mit Zitat
Ich sags nu noch ma obwohl BladeRunner es schon zig mal gesagt hat und andere auch: Fette Grafik ist sache des Designers! Shader machen keine fette Grafik! Shader benötigen sogar noch viel bessere Grafiker damit sie gescheit funktionieren. Und nachdem Blitz3D seit neuestem DXT komprimierte Texturen unterstützt gibt es keinen aber wirklich garkeinen Grund, keine Grafikqualität machen zu können. Nur solange du kein exzellenter Grafiker bist oder einen kennst wird auch eine DX27 Engine das nicht für dich hinbekommen, denn eine Engine erweckt grafik nur zum leben, es zaubert dir keine herbei. Also bitte merke dir folgendes: Eine Engine hat nur ganz am Rande etwas mit der Grafik zu tun die du auf den Schirm zaubern kannst! Das hängt zu einem viel grösseren Masse vom Programmierer und vor allem vom Grafiker ab!
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Fr, Aug 04, 2006 22:07
Antworten mit Zitat

Ich sags nu noch ma obwohl BladeRunner es schon zig mal gesagt hat und andere auch:

Fette Grafik ist sache des Designers!
Shader machen keine fette Grafik! Shader benötigen sogar noch viel bessere Grafiker damit sie gescheit funktionieren.
Und nachdem Blitz3D seit neuestem DXT komprimierte Texturen unterstützt gibt es keinen aber wirklich garkeinen Grund, keine Grafikqualität machen zu können. Nur solange du kein exzellenter Grafiker bist oder einen kennst wird auch eine DX27 Engine das nicht für dich hinbekommen, denn eine Engine erweckt grafik nur zum leben, es zaubert dir keine herbei.

Also bitte merke dir folgendes: Eine Engine hat nur ganz am Rande etwas mit der Grafik zu tun die du auf den Schirm zaubern kannst! Das hängt zu einem viel grösseren Masse vom Programmierer und vor allem vom Grafiker ab!

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

	X0r	Fr, Aug 04, 2006 22:21 Antworten mit Zitat
>Das ist das problem. Mit DX7 kann man wunderbar ein Quake III Arena machen, man muss nur wissen wie... Ich will aber keine Quake III Arena machen. Das mit DirectX ist mir auch klar. Es ist sozusagen auch nur sowas wie eine Engine. Kann bestimmte Sachen. Ja und für größere Sachen braucht man eben bessere DirectX Version. So einfach ist das.

X0r

Fr, Aug 04, 2006 22:21
Antworten mit Zitat

>Das ist das problem. Mit DX7 kann man wunderbar ein Quake III Arena machen, man muss nur wissen wie...
Ich will aber keine Quake III Arena machen. Very Happy

Das mit DirectX ist mir auch klar. Es ist sozusagen auch nur sowas wie eine Engine. Kann bestimmte Sachen. Ja und für größere Sachen braucht man eben bessere DirectX Version. So einfach ist das.

	Lunatix	Fr, Aug 04, 2006 22:28 Antworten mit Zitat
Eben nicht! Kapier es doch : um so besser der programmierer desto besser die effekte! Man kann sehr viel aus DX7 rausholen, wenn man noch nen guten PC hat sogar noch mehr...
[size=9]Pro\|gram\|mier\|er: Ein Organismus, der Koffein in Software umwandelt. Geben Sie eine beliebige 11-stellige Primzahl ein, um fortzusetzen...

Lunatix

Fr, Aug 04, 2006 22:28
Antworten mit Zitat

Eben nicht!

Kapier es doch : um so besser der programmierer desto besser die effekte!
Man kann sehr viel aus DX7 rausholen, wenn man noch nen guten PC hat sogar noch mehr...

[size=9]Pro|gram|mier|er: Ein Organismus, der Koffein in Software umwandelt.
Geben Sie eine beliebige 11-stellige Primzahl ein, um fortzusetzen...

	StepTiger	Fr, Aug 04, 2006 22:34 Antworten mit Zitat
Dreamora hat Folgendes geschrieben: Du hast da einige schwerwiegende Denkfehler: 1. "und diese Kugeln vielleicht sogar mit Gebäude kollidieren" Es werden, abgesehen von Granaten und Raketen, nie Projektile verschossen sondern ein LinePick gemacht, da eine Kugel mit 300-900m/s fliegt und für jedes normale Lebewesen unsichtbar ist! Vielleicht ein Grund für deine Performance Probleme 2. Gutes Aussehen != viele Polygone. Selbst die Unreal 2 Engine kann nur 5000-6000 Polygone auf animierten Objekten schlucken. Und da gebe ich gleich mitzubedenken: Diese werden von der GPU animiert! In Blitz werden sie von der CPU animiert, was einerseits langsamer ist und anderseits auch viel mehr zeit braucht weils von der CPU wieder an die GPU gesandt werden muss. Ich gebe dir aber recht, speed ist wichtig. Deswegen ist ein einigermassen realistisches Spieldesign von elementarer bedeutung. Und deswegen sollte man sich auch auf etwas stürzen was mit den eigenen Fähigkeiten harmonisiert ... Dir fehlt, so scheint es mir zumindest, einfach in einem ziemlich umfangreichen Masse das Wissen von 3D Programmierung, wie das mit Objekten, Animation etc hardwareseitig funktioniert. Insofern kann ich dir nur raten erst einmal die Grundlagen für dein spiel zu schreiben bevor du an etwas ran willst was so knapp 20 professionelle, erfahrene Programmierteams auf der Welt in einem gescheiten Mass bisher hinbekommen haben! (und wofür selbst die bei vollzeit arbeit monate gebraucht haben) Gewehrkugeln haben eine Maximalgeschwindigkeit von etwa 450 m/s nix mit 900 m/s (das wären 3240 km/h. Also fast 3 statt 1.4 Mach) Musste mal gesagt werden lol Mit DX7 kann man aber wirklich viel machen. Ich hab mit dynamic light und projected shadows schon ne menge hinbekommen! Aber da geht noch viel viel mehr!
Noch gestern standen wir am Abgrund, doch heute sind wir schon einen Schritt weiter. Computer: AMD Sempron 3000+; ATI Radeon 9800 Pro; 512 MB DDR RAM 400Mhz; Asus E7N8X-E Deluxe; Samsung 200GB HD 5.4ns acces t Gewinner: BP Code Compo #2 Π=3.141592653589793238...<--- und das aus dem kopf Seit der Earthlings-Diskussion überzeugter Fleisch(fr)esser.

StepTiger

Fr, Aug 04, 2006 22:34
Antworten mit Zitat

Dreamora hat Folgendes geschrieben:

Gewehrkugeln haben eine Maximalgeschwindigkeit von etwa 450 m/s
nix mit 900 m/s (das wären 3240 km/h. Also fast 3 statt 1.4 Mach)

Musste mal gesagt werden *lol*

Mit DX7 kann man aber wirklich viel machen.
Ich hab mit dynamic light und projected shadows schon ne menge hinbekommen! Aber da geht noch viel viel mehr!

Noch gestern standen wir am Abgrund, doch heute sind wir schon einen Schritt weiter.
Computer:
AMD Sempron 3000+; ATI Radeon 9800 Pro; 512 MB DDR RAM 400Mhz; Asus E7N8X-E Deluxe; Samsung 200GB HD 5.4ns acces t
Gewinner: BP Code Compo #2
Π=3.141592653589793238...<--- und das aus dem kopf Laughing

Seit der Earthlings-Diskussion überzeugter Fleisch(fr)esser.

	X0r	Fr, Aug 04, 2006 22:41 Antworten mit Zitat
Hab ich direkt gesagt, dass DirektX 7 schlecht ist? Ich denke nicht. Aber wenn es eine engine geben würde, die eine höhere anspricht würde ich diese auch benutzen. Aus. Ende und basta!

X0r

Fr, Aug 04, 2006 22:41
Antworten mit Zitat

Hab ich direkt gesagt, dass DirektX 7 schlecht ist? Ich denke nicht. Aber wenn es eine engine geben würde, die eine höhere anspricht würde ich diese auch benutzen. Aus. Ende und basta!

	Dreamora	Sa, Aug 05, 2006 12:41 Antworten mit Zitat
StepTiger: hochgeschwindigkeitsmunition bewegt sich im bereich von 900m/s, normale Gewehre wie bei Bundeswehr etc haben 300-350m/s DW: Letzter Versuch: Eine höhere DX Version bringt dir nicht mehr möglichkeiten, als du jetzt schon hast! Über die Grafikpracht entscheidet die verwendete Grafik, nicht die DirectX Version! Das einzige was DX9 bringt im vergleich zu DX7 sind Shader und die kannts du sowieso nicht nutzen! Denn wenn du Shader etc auch drin haben wolltest müsste nicht nur 1 supi Grafiker haben sondern 2-3 ... Hinzu kommt und das hatte ich vorher schon erwähnt: Dir mangelt es an so grundlegendem Verständnis wie 3D Funktioniert, wie DirectX funktioniert und wie Grafikkarten funktionieren, dass du auch mit einer DX9 Engine nicht besser weg kommst! Denn solange du nicht weisst, wie die Grafik entsteht, kannst du sie nicht effizienter entstehen lassen! ~GESCHLOSSEN~ Die Diskussion wurde nu definitiv bis an die Grenze geführt und alle wichtigen Punkte genannt, die zu beachten sind, unabhängig der verwendeten Engine und DirectX Version. und um DW zu zittieren: "Ende und basta!" Dreamora
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Sa, Aug 05, 2006 12:41
Antworten mit Zitat

StepTiger: hochgeschwindigkeitsmunition bewegt sich im bereich von 900m/s, normale Gewehre wie bei Bundeswehr etc haben 300-350m/s

DW: Letzter Versuch: Eine höhere DX Version bringt dir nicht mehr möglichkeiten, als du jetzt schon hast! Über die Grafikpracht entscheidet die verwendete Grafik, nicht die DirectX Version!
Das einzige was DX9 bringt im vergleich zu DX7 sind Shader und die kannts du sowieso nicht nutzen! Denn wenn du Shader etc auch drin haben wolltest müsste nicht nur 1 supi Grafiker haben sondern 2-3 ...
Hinzu kommt und das hatte ich vorher schon erwähnt: Dir mangelt es an so grundlegendem Verständnis wie 3D Funktioniert, wie DirectX funktioniert und wie Grafikkarten funktionieren, dass du auch mit einer DX9 Engine nicht besser weg kommst! Denn solange du nicht weisst, wie die Grafik entsteht, kannst du sie nicht effizienter entstehen lassen!

~GESCHLOSSEN~

Die Diskussion wurde nu definitiv bis an die Grenze geführt und alle wichtigen Punkte genannt, die zu beachten sind, unabhängig der verwendeten Engine und DirectX Version. und um DW zu zittieren: "Ende und basta!"
Dreamora

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

Gehe zu Seite Zurück 1, 2, 3

Übersicht

BlitzBasic

Blitz3D

Nach Oben

BlitzBasic Portal

Grafik Engine