Um die Programmierer bei MS, die uns das Leben so schwer machen, in Schutz zu nehmen
Sie versuchen ein großes Spagat. Zum einen verlangen wir alle maximale Kompatibilität mit den Vorgängerversionen. Zum anderen wollen wir sowohl optimale Ausnutzung der aktuellen Hardwareoptionen, und eine immer größere Detailtreue. Will man beides gleichzeitig, gibt es irgendwann ein riesiges Durcheinander und 10 Möglichkeiten, dasselbe darzustellen - und das kommt dann irgendwann in irgendeiner Situation durcheinander, der FSxxx crasht, und jeder schimpft.
Die aktuelle Entwicklung ist, das analog zu der CPU-Entwicklung, die das parallele Abarbeiten mehrere Programmteile gleichzeitig erlaubt und dadurch schneller wird, der Code für den MSFS von sequentieller Programmierung auf parallele Objekte umgestellt wird - wir müssen alle umdenken, aber das ist durch die Entwicklung der DV vorgegeben.
Was MS macht, ist das es in den SDKs viele Methoden als obsolete, not supported in future version kennzeichnet - so waren schon im FS2000-SDK die Terrain-Polygone so gekennzeichnet - im FS2002 taten sie es dann doch noch halbwegs, im FS2004 garnicht mehr.
Leider ist es aber bei vielen Entwicklern so, das sie, wenn sie einmal ein Tool gefunden haben, mit dem sie erfolgreich arbeiten können, dies solange benutzen wie irgend möglich, anstatt sich aufs jeweils neueste Werkzeug, das von MS stammt, zu stürzen. Airport statt GMAX, ttools statt Trafficdatabasebuilder, usw sind die Beispiele dafür. Andererseits kann mans verstehen, bis die SDKs rauskommen ist das Neue am Neuen schon weg, bis man sich da eingearbeitet hat ist der Nächste schon vor der Tür, ich erinnere mich noch daran, das die Welle von Produkten, die im Juni/Juli für den FS2002 rauskamen, hier kräftig kritisiert wurde.
Was zu schnell ist ist die Geschwindigkeit, mit der die Versionen aufeinander folgen, weniger als zwei Jahre ist einfach zu wenig Zeit - drei Jahre wären besser.
15.09.2003, 10:05
Baum-Darstellung