Neue X2 - Die Bedrohung Screenshots 2/Dez/02

[Rei Ayanami]

Tut mir leid, wenn ich hier meine Unwissenheit präsentiere, aber was ist
gmax? Sowas wie DirektX? Grafikbeschleuniger?

Das ist sowas wie eine kostenlose Light-Version des proffesionellen und sauteuren Programms "3D Studio Max",welches fuer die Objekt und Levelerstellung fast aller aktuellen Spiele verwendet wird.

Ya mata ne,Rei

[Glyph]

Du vergisst Maya

CU Glyph

[eirik]

Eigentlich braucht man GMax doch nicht in jedem Fall. Es gibt doch genug freie Programme wie z.B. Blender. Oder wie ist es mit einem freiem Editor für ein freies Render-Prgramm? Man schaue einfach bei freshmeat.net nach.
Ich verstehe Egosoft da nicht so ganz. Programme wie Unreal und Nachfolger leben immer noch von ihrer Community

[HeadKill]

Re: all 3d Editor.

Naja da habt ihr schon recht mit freeware, aber Moment.

Endscheidend ist folgendes:
Was für ein Format die EGOSOFT-3Dengine zusammenarbeitet. (soweit ich weiß 3DS) ist bekannt von > 3d Studio Max <
Ich weiß alles bekannt, aber nun de punkt ich kenne 3d Studio Max aber auch > Cinema 3d Studio < von MAXONE (der größte Konkurrent von 3d Studio Max).
Es gibt eine Lightversion von Cinema 3d Studio und das ist von
DATABACKER Creative 3D Studio (Hersteller: MAXONE).
Zuletzt 9.-€ bei DATABACKER

NUN das Problem.
Wenn 3d-Daten von einem Programm ins andere Konvertiert werden so gibt es einige Probleme:
1. Lichteffekte sind anders
2. Probleme mit Fehldarstellungen von Texturen.
3. Texturpfade werden teils nicht erkannt.
4. Objektzusammenhänge werde nicht immer interpretiert.
5. da gibt’s noch viele andere Probleme

soviel zu diesen Punkt.
Es gibt viele Möglichkeiten, um ein Game mit einen Editor auszurüsten.
Ich fände jedoch das ein Editor für das Spiel nicht angebracht währe, da dies zur Spielverzerrung führen würde.
Was ich aber nicht schlecht fände wen es so was wie ein Baukastensystem.
Aber nur für die Onlineversion.

jo bis denn denn

[Deleted User]

Man kanns gar nicht oft genug sagen: "Einfach nur STARK!"

[Vassenego]

Bilder sind Super,

aber an der Stelle meine Frage, was für eine PC, und was für eine Geschwindigkeit muss der PC (also Hardwarevorraussetzung) haben, das X² ohne Probleme und Ruckelfrei abläuft.

Gute Frage, ich seh mich schon im April in den Laden meines Vertrauens hecheln um mir X2 zu holen und mit einem neuen P4 - 3GHz, mit 1024 MB RAM und einer Radeon 9700 nach Hause fahren.
Macht dann 3000,- Euro für X2, aber das sollte es wert sein.

@Pics

( ... .... ... )


... ...gut
Vassenego

[HeadKill]

RE: Vassenego
Das mit der Hardware hat sich geklärt
Laut Sendung bei GIGA, ist ein 700 MHz, Geforce 2 ausreichend.
Aber das hast du ja auch mitbekommen.
cu

[Old Man II]

Tja die Frage von HeadKill ist berechtigt. Wenn ich die Menge an Schiffen sehe die dann auch noch mit diesen Effekten in einen Kampf gehen dann kann ich die Hardwarevorraussetzungen die Bernd immer angibt nicht mehr glauben. Zur Erinnerung, bei GIGA sagte er eine Gforce2 ist nützlich und die Prozessoren sollten 1GHz haben. Ich fürchte er meint nur für das Intro oder?

CU

[HeadKill]

Ich bin der Meinung, das irgendwo immer Grenzen vorhanden sind.
Hoffentlich entscheidet sich EGOSOFT über ein Assembler-Programmierung der Engine.
Ein Beispiel.
Befehl In Assembler in C++:

// Anfang

#include "stdafx.h"

int main(int argc, char* argv[])

{
int Test11=11;

__asm inc Test11

Test11++;

return 0;

}
// Ende
Die beiden Anweisungen __asm inc Test11 und Test11++ ergeben das selbe.
Beider addieren den wert mit sich selbst um 1 (ein Zähler)
Nun der Punkt beider brauche aber unterschiedlich viel an Takte der Prozessors.
Ergebnis im Disassembler.
.
.
.
9: int Test11=11;
0040B768 mov dword ptr [ebp-4],0Bh
10: __asm inc Test11
0040B76F inc dword ptr [ebp-4]
11:
12: Test11++;
0040B772 mov eax,dword ptr [ebp-4]
0040B775 add eax,1
0040B778 mov dword ptr [ebp-4],eax
13:
14: return 0;
.
.
Man sieht das der Prozessor für die Anweisung „Test11++;“ länger rechnen muss als die Anweisung „__asm inc Test11“

So was kann in manchen Schleifen sehr viel bringen. (für Abziehen „dec“)

Also viel Spaß beim Tunen Leute
Ps noch was für durch zwei Teilen und anschlißent abrunden geiler Befehl „__asm shr Test11“

Assembler ist einfach, aber im Zusammenhang echt Schwierig.

MfG HeadKill der Querdenker

[Freggel.Doe]

@Headkill: die ganzen sachen, die du da beschreibst sind so einfache optimierungen, dass ein vernünftiger compiler die selbst vornimmt. ein increment oder dekrement sollte man nie als assembler-include hinschreiben müssen. genausowenig den shift nach rechts für die division durch 2, bzw nach links für multiplikation. die heutigen compiler nehmen teilweise optimierungen vor, die man als mensch schon gar nicht mehr nachvollziehen kann und deswegen kann es durchaus auch mal nachteilig sein, assembler-includes zu verwenden, da man den compiler damit davon abhält, eventuell eine bessere übersetzung für den umgebenden codeblock zu finden.

gruss freggel

[HeadKill]

Re: Freggel.Doe

Das kann durchaus sein, aber wieso sind Assembler 3D-Engiene immer besser als von Hochsprachen geschriebene 3D-Engine.

Das waren natürlich simple Beispiele, und ich weiß auch das Programmierer die das Jahre schon machen mehr Ahnung von Programmierung haben wie ich. Aber manchmal wird diese Option vergessen. Denn auch Hochsprachen haben Menschen Programmiert.

Das Programm wurde von MS Visual Studio erstellt.
Wenn das eine sinnvolle Optimierung war dann aber hallo.

[Freggel.Doe]

Das kann durchaus sein, aber wieso sind Assembler 3D-Engiene immer besser als von Hochsprachen geschriebene 3D-Engine.

ich muss leider zugeben, dass ich keine 3d-engine kenne, die in assembler programmiert wurde, nur weil normals c oder c++ zu langsam war.

Aber manchmal wird diese Option vergessen. Denn auch Hochsprachen haben Menschen Programmiert.

Das Programm wurde von MS Visual Studio erstellt.
Wenn das eine sinnvolle Optimierung war dann aber hallo.

wie du selbst sagst, wird manchmal vergessen, optimierungen einzuschalten. vielleicht ist dass bei deinem erzeugtem beispiel-code auch der fall gewesen.
ausserdem bin ich davon überzeugt, dass jeder programmierer seine release-version mit allen möglichen optimierungs-optionen compilieren wird, da während der ausführung das programm halt schnellstmöglich laufen sollte. ich könnte mir vorstellen, dass egosoft das auch so machen wird.

gruss freggel

[Octavius]

Bei heutigen Compilern kann nahezu jede Optimierung auf Maschinenebene entfallen (Assembler), da es bereits im Quellcode der Hochsprachen möglich ist, einen Algorithmus so zu formulieren, daß eine Optimierung durch den Compiler nicht mehr durch Assembler-Codierung zu verbessern wäre. Genauso wie es Freeggel.Doe erläuterte.

Und wer es nicht lassen kann, der optimiert dann meistens für ein paar Prozent Geschwindigkeitszuwachs an einer Stelle (sei es nur deshalb, um Zeit für Parameterübergaben zu sparen), wo man an anderer Stelle durch eine Konzeptionsänderung und deren Implementation in einer Hochsprache wie C/C++ locker mal eben 50% Performance gewinnen könnte. Der Aufwand für maschinennahe Programmierung lohnt sich daher in der Regel nicht im Programm oder den dazugehörigen Modulen.

Assemblerprogrammierung beschränkt sich heute vorwiegend auf die Entwicklung von Betriebssystem API's und Treiber für Hardware und Softwareschnittstellen.

Für die Programmierung von Grafik gibt es für Betriebssysteme optimierte Schnittstellen, wie zum Beispiel OPEN GL (für viele Betriebssysteme verfügbar) oder DIRECT X speziell für windows-basierte Betriebssysteme und mittlerweile auch für Linux. Diese haben Schnittstellen zu Hochsprachen und sprechen Ihrerseits wieder die Treiber für die Hardware-Grafik an, an denen sich bereits Experten für die Grafikchips die Zähne dafür ausgebissen haben. Allein auch aus Kompatibilitätsgründen macht es keinen Sinn, hier in Assembler irgendetwas reinzupfuschen. Solche Treiber auf unterster Ebene sind zum Beispiel die Detonator-(Allround)Treiber für Karten der nVidia-Serie.

Es gibt für verschiedene Grafikkarten trotzdem die Möglichkeit, hardwarenahen optimierten Code zur Laufzeit auf die Karte zu laden. Das ist dann aber eine spezielle Codesprache für den Prozessortypen der Grafikkarte. Dieser Code ersetzt dann ggf. fest verdrahtete Routinen auf der Karte. Nur müßte man dann für alle Grafikkarten verschiedener Chipfamilien gesonderten Code entwickeln und testen. Grausam für Entwickler und Kunden zugleich.

Ich vermute mal, Egosoft wird einen Teufel tun und irgendwas in Assembler programmieren, wenn es nicht unbedingt sein muß. So ein Game wie X² ist auch so schon äußerst komplex und will auch noch gewartet werden. Der nächste Patch kommt nach dem ersten Release ganz bestimmt und könnte dazu führen, das einige Programmteile neu geschrieben werden müssten. Wehe, da waren dann auch noch "handverlesene" Assemblercodes drin und halten den ganzen Laden auf... Dann gibt's aber von Cheffe was auf die Rübe wenn nur deswegen der Patch

1. lange auf sich warten ließe
2. oder verbuggter ist, als das Release zuvor

Und das habt Ihr doch wohl bei Egosoft noch nie erlebt - oder?


Gruß
-Octavius-

[HeadKill]

Ihr habt ja recht,
ein Komplexes Programm soll ja nicht noch komplexer werden.

Ich will um GOTTESWILLEN nichts das EGOSOFT daran schaden nehmen sollte.
Ich bin aber auch der Meinung das eine Angepasste Prozessroutine die entscheidend Auswirkung auf die Geschwindigkeit der 3D Engine haben könnte doch kleine Modifikationen, ein wenig bringen könnte.

Aber jeder hat seine Meinung zu dieser Angelegenheit, der eine Vertraut auf Software und deren Optimierungen und der Andere schaut sich die Optimierung genau an, und entscheidet dann.

So nebenbei hat id-software auch solche kleinen modis vorgenommen.
Aber genaue Infos habe ich auf die schnelle auch nicht gefunden.

Naja, wie auch immer ich denke Egosoft macht auf jeden fall das Richtige

also bis denn denn