Diskussionen über interessante Themen
-
TGGC schrieb:
BTW: Lest doch erstmal die readme von dem KKrieger bevor ihr hier was behauptet.
-
zum thema kleine intros/demos (mainly 64k) mit genialen effekten solltet ihr euch mal die werke der "farbrausch"-crew ansehen... (http://www.farb-rausch.com/)
ich finde "the product" am geilsten. ist schon etwas älter, aber cool!...
-
Falls du noch abzählst...meine Stimme würd ich für Terraindarstellung abgeben
-
BTW, ich denke, wenn man erst mit "dem Handwerkszeug", generellen Methoden, etc. und nicht sowas spezialisiertem wie Schatten anfangen würde, hätten die Leute hier mehr davon.
Man könnte diese grundlegeneren Themen ja dafür schneller abhandeln.
-
Und an was denkst du da, for-Schleifen? Stimmt von sowas hab ich echt unheimlich viel.
Bye, TGGC \-/
-
TGGC schrieb:
Und an was denkst du da, for-Schleifen? Stimmt von sowas hab ich echt unheimlich viel.
Hahaha...
Nee, halt sowas, was (fast) jeder 3D-Progger irgendwann mal braucht. Und da gehören nicht unbedingt Schatten dazu. Das ist vorwiegend was für FPSler, ein Stratege hält die sicher für unwichtig.Vielleicht zuerst tatsächlich mal diskutieren, wie man eine Engine generell aufbauen könnte. U.a. auch API-Unabhängigkeit, um Flamewars zu vermeiden!
Frustrum Culling / SceneManagement - braucht jeder!
Modelloader.
Dann erst Terrain und Schatten.
Superoptimierungen (schnelle Mathematik) erst am Schluß.
Andererseits hat die Menge ja entschieden. Und wenn eh nur die 5 Männeken hier diskutieren.... mhhhh... bin mal gespannt.
Ach, vergiß es!
-
Ganz unten anzufangen würde sicher besser sein, denn so würden sich evt. auch Leute
an den späteren Themen beteiligen können, die im mom noch wenig/nichts zu sagen
haben, weil es an ganz anderer Stelle klemmt.
-
SirLant schrieb:
Ganz unten anzufangen würde sicher besser sein, denn so würden sich evt. auch Leute
an den späteren Themen beteiligen können, die im mom noch wenig/nichts zu sagen
haben, weil es an ganz anderer Stelle klemmt.Genau deswegen meint' ich.
-
Genau. Und die Mehrheit ist sowieso für 'Game-Engine'.
-
Nur gut, das wir schon das Schattenthema angefangen haben.
Bye, TGGC \-/
-
Sieht so aus als ob es jetzt durch wäre. Dann können wir ja mit dem 2. Thema anfangen. Game-Engine.
Ich lese dazu gerade die 'Artikelreihe' 'Enginuity' auf Gamedev.net
-
Jover schrieb:
Ich lese dazu gerade die 'Artikelreihe' 'Enginuity' auf Gamedev.net
Die hab ich bis zum 2. Teil auch gelesen, hab dann aber aufgehört... Ich fand das Design da auch teilweise ziemlich komisch.
Ich finde es zum Beispiel unlogisch, dass ein MemoryObject eine (statische) Liste mit allen toten, bzw. lebenden Objekten hat. Ich hätte das eher mit einer MemoryManager Klasse gelöst, die eben diese Objekte speichert.
-
godlikebot schrieb:
Jover schrieb:
Ich lese dazu gerade die 'Artikelreihe' 'Enginuity' auf Gamedev.net
Die hab ich bis zum 2. Teil auch gelesen, hab dann aber aufgehört... Ich fand das Design da auch teilweise ziemlich komisch.
Ich finde es zum Beispiel unlogisch, dass ein MemoryObject eine (statische) Liste mit allen toten, bzw. lebenden Objekten hat. Ich hätte das eher mit einer MemoryManager Klasse gelöst, die eben diese Objekte speichert.Ich kann dazu noch nichts sagen, da ich gerade erst begonnen habe zu lesen.
Kennt jemand noch andere lesenswerte Dokumente über dieses Thema?
-
Ich kenn sonst nur noch das Portal Engine Tutorial auf Flipcode.
-
Also da es wohl nun doch niemand gibt, der über "Game-Engine" (was auch immer genau das für'n Thema wär) diskutieren wollte, ist als nächstes mit 2 + 3 Stimmen "Scriptsprache" dran.
Bye, TGGC \-/
-
scriptsprache ist sehr interessant, ich hab mal was gegoogelt, und war geschockt, dass man sofort in der tiefsten compiler theorie gefangen ist.
es wär mal interessant, wieviel eine scriptsprache können muss, um schon eine scriptsprache zu sein, und wieviel scriptsprache man in der Praxis wirklich braucht.
-
Ne Skriptsprache schreiben und anwenden ist ja etwas total anderes, man muss sich
keine eigene Sprache schreiben, sondern kann fertige Skriptsprachen benutzen.Was mich jedoch interressieren würde, wäre wie man diese in sein Programm einbindet.
Habe nur einmal ein kleines Stückchen Code bei dem Lua benutzt wurde gesehen und
mir ist zwar die benutzung klar, aber nicht wie man so etwas weiträumig in ein
Programm einbindet und nacher z.B. die KI in der Skriptsprache schreibt.
-
TGGC schrieb:
Also da es wohl nun doch niemand gibt, der über "Game-Engine" (was auch immer genau das für'n Thema wär) diskutieren wollte, ist als nächstes mit 2 + 3 Stimmen "Scriptsprache" dran.
Bye, TGGC \-/
Ich lese gerade
-
SirLant schrieb:
Was mich jedoch interressieren würde, wäre wie man diese in sein Programm einbindet.
Kommt natürlich immer darauf an, welche Sprache man benutzt. Meine Skriptsprache der Wahl ist Python. Und das Einbinden dieser in C(++) Programme ist ein Kinderspiel. Man muss lediglich den Interpreter in sein Programm linken (bzw die Wrapper - lib für die Interpreter DLL), ein bisschen Wrapper Code schreiben um seine Python Funktionen von C aus aufrufbar zu machen und umgekehrt, und schon hat man ein Skript - Interface zu der (meiner Meinung nach) schönsten Skriptsprache wo gibt. Ich denke ähnlich wird es bei allen Skriptsprachen sein, die (auch) dafür gedacht sind als Skriptsprache eines Programmes zu dienen. Bei Python finde ich vorteilhaft, das es ein ähnliches Objektmodell wie C++ hat, das sich leicht miteinander integrieren lässt (zu sehen ua bei www.wxPython.org), eine schöne Syntax (besser als bei C, C++) hat und eine soooo grosse Auswahl von Modulen hat. Das ließe sich noch um einiges fortsetzen, aber wer wollte das dann noch lesen :D.
Generell: Wer an C++ gewöhnt ist, dürfte mit Python keine Probleme haben.
-
nehmen wir mal an, ich wollte eine scriptsprache erstellen, ich hab mir mal ein tutorial dazu durchgelesen, und eigentlich geht mir das viel zu weit, was die da machen...
wenn ich sowas machen würde, dann würde ich das vielleicht nach folgendem prinzip machen:
\1:
restart_game 5
im programm soll dann einfach die funktion restartgame(5); aufgerufen werden,dh meine scriptsprache soll die scriptsprache in funktionen übersetzen, die dann ausgeführt werden.
das kriegt man noch hin, also das ist nicht so das problem.
wie kann ich aber sowas lösen:
a=b+c;
in einem c++ programm, indem ich keine operatoren kennen würde, würde ich einfach folgendes machen:
zuweisung(a,addition(b,c));
sowas kann das script aber nicht generieren,der return wert ist im moment mein großes problem.
ich hab mir überlegt,ob man das so machen kann:
jede funktion besitzt eine return Variable,und der compiler macht folgendes:
aus: a=b+c wird
[cpp]
//irgendwo innerhalb einer Klasse
T return_addition;
addition(b,c);
zuweisung(a,return_addition);
der weg ist natürlich sehr umständlich, und ich bin auch nich sehr zufrieden damit, aber ich möchte soweit wie möglich von (pseudo) assembler entfernt sein(wenn das überhaupt möglich ist, falls nicht, dann muss ich mich dem schicksal beugen :P)
