spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"DragonMaster"«

Erstens, sie sind lagsam.

an dir haftet der vc6.0 der 1998 releast wurde, außerdem haben die sich das ziemlich leicht gemacht und einfach exception default mäsig aus gemacht
also exception müssen nicht langsamm sein, du kennst doch bestimmt die funktion longjmp
damit kannts du wenn du wills dir exception handling nachbauen (passiert bei longjmp den was zu laufzeit wenn nicht geprungen wird)

Zitat von »"DragonMaster"«

Zweitens, sie sind mit dem Umgang mit DLL's nicht zu gebrauchen.

ist eine dll nicht dazu da das mährere programme sie gleichzeitig benutzen? wie viele games auf einmal wills du den am pc laufen lassen?
wozu tust die dir das eigentlich an? du wirst zu einer dll schnittstelle gezwungen, verzichtest aus excpetion, verzichtest auf inline optimierungen usw.

Zitat von »"DragonMaster"«

Die Entwickler sind dann, bei der Entwicklung ihrer PlugIn's, an den VC++ 7 Kompiler gebunden, und können z.B. nicht den Intel Compiler benutzten. Exceptions gehen ja schon nicht mehr wenn man VC 7 mit VC 6 mischt. Das hatte ich schon mal in einem Projekt. Die Exceptions werden dann nicht richtig verarbeitet oder gar Ignoriert.

wie viele jahre hast du vor dich vom 6.0 behindern zu lassen?

Ich habe ein ähnlichen Ansatz verfolgt wie Dragonmaster, nur mit dem unterscheid, das bei mir Jedes Plugin seine eigene Fehlerbehandlungsmhanismus besitzt. Der grund dafür ist, das bei einem Globalen system alles zusammenläuft und man bei steigender Anzahl von Plugins echt Probleme bekommt die übersicht zu behalten. Um auch bei einfachen Protokoll Funktionen, die Laufzeit nicht zu stak zu drücken, besitzt jedes Plugin dafür eine Queues, die alle paar Frames nur entleert wird. Von exceptions in Größeren Projekten kann ich nur abraten. Auf Low Level ebene sprich bei Listen und Array’s usw.. habe ich einfach eine Variable, die, die fehler speichert, sowie eine Funktion GetLastError, auf der ebene exceptions einzusetzen ist der Performance Killer Nr.1. Zumal der einigt relevante fehler ein BadAlloc sein kann, und dafür ein try catch block? Ein Overflow würde ich einfach intern abfangen, und mittels einer Grow() Methode bekämpfen.

Und da jede weitere Fehlerbehandlung nun mal die LowLevel Container benötigt, muss man sich schon überlegen, wie man das ganze aufbaut. Das Globale ErrorHandling habe ich ebenfalls in einem Thread laufen, wenn es nötig ist, können ganze PlugIn Gruppen abgesägt werden, und neu gestartet werden.

mfg

Maverick

Zitat von »"David Scherfgen"«

Hallo, schön, dass Du auch mal hier ins Forum kommst

ich brauche mal ne pause von html

Zitat von »"David Scherfgen"«

DLLs sind nicht zwangweise dafür da, mehrere Programme gleichzeitig zu machen. Eine richtig gute Engine lässt sich durch Plug-Ins erweitern, und die wahrscheinlich beste Möglichkeit, diese Plug-Ins zu realisieren, sind DLL-Dateien. Man braucht dann die eigentliche Engine nicht zu modifizieren.

diese plugin erweiterung sind die notwendig? ich mein man kann das doch alles statisch linken und dann würde ich ja auch nicht die enginverändern (der teil wäre in einer lib und nur zu gelinkt)

Zitat von »"David Scherfgen"«

Inline-Optimierungen gehen auch nicht unbedingt verloren, man kann ja die wichtigen Inline-Funktionen direkt in die Header-Datei des Plug-Ins schreiben.

hätte hinschreiben sollen das ich nicht inline funktion meine (die man sowieso in header definieren muss)
z.b. haben ich beim msvc 2003 gelesen das er eine weiter optimierungs stuffe hat "globale optimirung" oder, nach den linken geht er das programm noch mal durch, die teile die in einer dll sind sind da außen vor

Zitat von »"Anonymous"«

Von exceptions in Größeren Projekten kann ich nur abraten. Auf Low Level ebene sprich bei Listen und Array’s usw.. habe ich einfach eine Variable, die, die fehler speichert, sowie eine Funktion GetLastError, auf der ebene exceptions einzusetzen ist der Performance Killer Nr.1. Zumal der einigt relevante fehler ein BadAlloc sein kann, und dafür ein try catch block? Ein Overflow würde ich einfach intern abfangen, und mittels einer Grow() Methode bekämpfen.

mit welchen compilier hast du die Performance Killer Nr.1 erfahrungen gemacht? oder ist das so ein bachgefühl?

das mit overflow und grow würde die exception benutzer auch nicht anders lösen, exception sollte man ja nur benutzen wenn man auf einer bestimten ebene nix mit den fehler anfangen kann

Zitat von »"Anonymous"«

Das Globale ErrorHandling habe ich ebenfalls in einem Thread laufen, wenn es nötig ist, können ganze PlugIn Gruppen abgesägt werden, und neu gestartet werden.

ist dabei auch sicher gestellt das alle ressorcen sauber frei gegeben werden? und wie offt wird den so was benutztabgesägt neu gestartet)

Zitat von »"DragonMaster"«

Wie man eine DLL einsetzt ist jedem selbst überlassen. Das Prinzip einer DLL sollte aber klar sein. Ein vorteil von dynamisch geladenen DLL's ist, das sie nicht unbedingt mit vc7 geschrieben müssen wenn das eigene Projekt mit vc7 geschrieben wurde. Die DLL's die ich verwende werden alle dynamisch als PlugIn geladen. Nur der Kernel wird an das Projekt fest verlinkt.

ok sehe aber die notwendigkeit nicht ein game in in mehrern sprachen zu schreiben, bei programmen kann ich es verstehen das man die gui in vb, objekt-pascal oder ähnlichen schreibt und das back-end in c/c++
aber bei ein game?

Zitat von »"DragonMaster"«

Aber nicht nur ein Game würde die PlugIn's benutzten. Der Level Editor wird ebenfalls einiege PlugIn's benutzen. Z.B. das Grafik PlugIn

aber um ein ram ersparnis zu bekommen müssten beide zu gleich laufen

Zitat von »"DragonMaster"«

Das sollte bei jedem Kompeiler so sein

:cussing: ;D

Zitat von »"DragonMaster"«

Ob inline benutzt wird oder nicht, entscheidet oft der Compiler selber. Das kann sogar soweit gehen das eine DLL gar nicht mehr mit dem Projekt verlinkt wird. Hab ich oft wenn ich die WinAPI nutze. Zudem ist es sehr schwer inline zu nutzen, wenn in den PlugIn's nur Interfaces sind. D.h. virtuelle Methoden

;D

Zitat von »"DragonMaster"«

@longjmp Funktion
Hab ich noch nie mit gearbeitet.

ich auch nicht (ist ein goto was über scope ebenen springen kann)
exception müssen nich viel mehr kosten, ok der msvc 6.0 hat das image der exception so angekratz das es noch ein paar jahre dauer kann.
wie der msvc 7.0 abschneidet ka