spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hab bis jetzt noch keine .NET D3D Prog programmiert. Aber ich denke der Performanceunterschied wird nicht so gravierend ausfallen. Ich glaub die 32FPS liegen woanders dran, z.B. wieviel Fläche das Objekt auf dem Bildschirm belegt.


Ich denke der größte Unterschied liegt an der Sprache, sondern am Compiler der die Sprach in CPU-Sprache übersetzt. Z.B. soll der Intel-Compiler sehr viel schnelleren Code erzeugen als der von VisualC++. Konnte es allerdings net testen da die Installation des Intel-Compilers meine VC++ Installation gefrackt hat.

Also ich proge c++ udn mein kumpel c#. Wir haben uns lange gestritten, wir haben lange diskutiert, wir haben viele testberichte gewälzt und wir haben rumgetestet und haben rausgefunden, dass die beiden in oop kaum unterschiede haben und c++ nur einen knappen vorsprung bei linearen programmen hat. C# hat den "Vorteil" das es plattformunabhängig ist und das es 100% auf jeden system funktioniert was das framework drauf hat. Die alternative ist C7 dieses ist nicht die c# an das .net gebunden. Also alles in allem ist es recht egal was man benutzt, solange man es richtig nutzt.

Zitat

immerhin spuckt der compiler doch windows-code aus.

AFAIK spuckt der compiler nen Java ähnlichen bytecode aus der eben portabel ist.

hm, ja, ich bin mir atm garnicht sicher ob der MSIL bytecode wirklich portabel ist. Man kann ihn denke ich aber portable machen. Wie weit portabel der code gemacht werden kann weiß ich allerdings nicht. Jedenfalls laufen "einfache" C# programme (durch mono und DotGNU) auch unter Linux. Naja, wie weit das noch portabler geht wird man ja noch sehen.

Zitat von »"Jumping Jack"«

hm, ja, ich bin mir atm garnicht sicher ob der MSIL bytecode wirklich portabel ist. Man kann ihn denke ich aber portable machen. Wie weit portabel der code gemacht werden kann weiß ich allerdings nicht. Jedenfalls laufen "einfache" C# programme (durch mono und DotGNU) auch unter Linux. Naja, wie weit das noch portabler geht wird man ja noch sehen.

Der Code an sich ist nicht das Problem. Die Frage ist nur, was nun schon alles in der Runtime Umgebung implementiert ist. Auf er Homepage des Mono-Projekts kann man genau nachschauen, welche Namespaces und Klassen bereits fertig sind, welche bekannten Bugs es noch gibt usw.
Vom Code her lässt sich aber eigentlich jedes Programm auf mono portieren.

Mich würde gerade mal interessieren, obs schon irgendwie ne OGL-Implementation mit dem Interface der Microsoft.DirectX.dlls gibt. Dann könnte ich meine C#-Engine auch mal auf Linux laufen lassen
Das wär klasse - man müsste sich um nichts mehr kümmern und könnte 3D-Apps für jedes Framworktaugliche Betriebssystem schreiben *grins*

@FPS-Rate:
Ich hab mein Partikelsystem + Spriteengine zuerst dynamisch aufgebaut, um keine Höchstanzahl an Partikeln/Sprites zu haben. Dazu hab ich eben System.ArrayList benutzt, in FrameMove und Render Listeneinträge geaddet und nach dem rendern die Liste wieder gecleared. Doch dieses ganze Dynamische Zeugs für Hunderte und Tausende von Partikeln ist einfach viel zu zeitaufwändig.
Fazit: Es kommt sehr darauf an, was man codet. Das Framwork bietet so herrliche Möglichkeiten (ja, ich liebe es! Das ist ein richtiges Wunderland ), doch *nicht alles* ist schnell genug für realtime 3D graphics.

bye
Klaus