4. DirectX Managed oder nicht?

DirectX Managed oder nicht?

  • G

    Nun, da ist das Problem.
    Ich kann beides, C# ist nur angenehmer. Setze aber auf Geschwindigkeit. Musste C# aus beruflichen Gründen lernen. Jetzt finde ich es eigentlich sehr angenehm. Wollte aber erst nicht... 🙂

    Nun, dann eben doch wieder C++. Muss mal einen direkten Vergleich schreiben zwischen C# und C++ oder gibts da schon irgendwo ne Tabelle für einen Vergleich?

    Gruß
    Sven

    0
  • R
    Mod

    vergleich von was, und was willst du dadurch erreichen?

    0
  • G

    Nun, es geht um die Geschwindigkeit... ergo einen Geschwindigkeitsvergleich.
    Was ich damit erreichen will? Vielleicht die Bekanntheit eines Faktors?

    Gruß
    Sven

    0
  • S

    Ich weis ja nicht was du vor hast in DirectX und warum es so Zeitkritisch ist aber meiner Meinung werden die Geschwindigkeitsvergleiche zwischen Java/C# vs. C++/C bei vielen Maßlos übertrieben/Überschätzt.
    Da würde ich eher sagen, wenn du C# besser kannst als C++ wird dein C# Projekt schneller laufen weil du "sauberen" Code schreibst.

    schirrmie

    0
  • R
    Mod

    stimm ich zu, wenn man c++ nicht sauber coden kann, wird man keinen unterschied merken. da macht der benchmark wenig sinn, er zeigt am ende nur die faehigkeiten des coders, nicht der sprache. wenn man dann richtig schlecht ist, findet man sogar raus dass c# viel schneller ist, siehe: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=384922

    Aber leute die so nen thread erstellen sollten eh c# nutzen 😉

    0
  • ?

    Hallo

    Kannst bei managed ja auch XNA verwenden.

    chrische

    0
  • A

    Ich würd auf XNA2 warten. Habe xna,mdx und directx(c++) getestest.

    C++ ist leider sehr kompliziert und man macht nur langsam Fortschritte
    (nur meine Meinung).Was für c++ spricht, fast alles ist für c++ ausgelegt,
    die Umstellung auf managed geht leider nur langsam voran, es gibt nicht
    Sehr viele Managed Engines, wird sich aber ändern.

    XNA hab ich sehr schnell wieder verworfen, xna ist hauptsächlich NUR
    für x-box gemacht, was sich endlich mit XNA2 ändert wird.

    Mit MDX hab ich noch die besten Erfahrungen gemacht. Man kommt recht zügig
    voran, ist recht leicht verständlich, und es gibt viele webcasts dafür.
    Leider wurde mdx nicht weiter entwickelt.

    Nun warte ich auf XNA2 und hoffe auf das BESTE 🙂

    0
  • G

    Danke für die Infos,
    nur soviel, ich programmiere beruflich seit vielen Jahren C++. C# seit ca. einem Jahr. Somit sollte der Code doch einigermaßen sauber sein. 😉
    Mich interessiert einfach auch die Meinung anderer.

    Gruß
    Sven

    0
  • ?

    Hallo

    Wann soll denn xna2 kommen?

    chrische

    0
  • T

    Hallo,

    adonis schrieb:

    Ich würd auf XNA2 warten. Habe xna,mdx und directx(c++) getestest.

    C++ ist leider sehr kompliziert und man macht nur langsam Fortschritte
    (nur meine Meinung).Was für c++ spricht, fast alles ist für c++ ausgelegt,
    die Umstellung auf managed geht leider nur langsam voran, es gibt nicht
    Sehr viele Managed Engines, wird sich aber ändern.

    XNA hab ich sehr schnell wieder verworfen, xna ist hauptsächlich NUR
    für x-box gemacht, was sich endlich mit XNA2 ändert wird.

    Mit MDX hab ich noch die besten Erfahrungen gemacht. Man kommt recht zügig
    voran, ist recht leicht verständlich, und es gibt viele webcasts dafür.
    Leider wurde mdx nicht weiter entwickelt.

    Nun warte ich auf XNA2 und hoffe auf das BESTE 🙂

    Wie meinst du das XNA sei "nur" für XBox gemacht? Kann das nicht bestätigen. Schreibe grad meine Diplomarbeit und nutze dabei XNA für eine PC Anwendung - früher C++ - nun teste ich einmal C# und XNA. Bin eig. positiv überascht.
    Und was soll Deiner Meinung nach XNA2 - "XNA" zu einer besseren PC nutzung bewegen?

    MDX wirst du wohl abharken können, wird wohl nicht mehr weiterentwickelt und wurde auch im neuen DX SDK rausgenommen.

    Was geschwindigkeitsfragen angeht, ist doch immer das gleiche C++ ist schneller und C# ist ja soviel langsamer, etc. Naja viel liegt doch wohl am Programmierer selber und welche alten rechner musst du bediehnen, damit du wirklich C++ effektiv ausnutzt? Mit C# bist du halt viel schneller und in verbindung mit XNA kannst du Dich auf Dein Problem konzentrieren und musst dich nicht mit anderen Sachen aufhalten. Von daher ist die Frage eher - was habe ich, was will ich machen, wo soll es laufen und wann soll es laufen. Dann kann ich sagen ich nutze die und die Sprache.

    Ich persönlich stell jetzt nicht die Geschwindigkeits defizite fest. Kann mir aber gut vorstellen, dass es grad auf schlechteren Rechnern einbricht. XNA ist ja "fast" eine C++ Anwendung geworden, es wird vorher Compiliert und nicht Interpretiert und somit wurde auf Geschwindigkeit geachtet. Aber ein perfekter Vergleich wäre wohl nicht so einfach möglich, da es von zuvielen Faktoren abhängen würde.

    chrische5 schrieb:

    Hallo

    Wann soll denn xna2 kommen?

    chrische

    Geplant - ende dieses Jahres.

    0
  • R
    Mod

    T_R_o_u_B_L_E schrieb:

    Wie meinst du das XNA sei "nur" für XBox gemacht? Kann das nicht bestätigen.

    http://www.c-plusplus.net/forum/viewtopic-var-t-is-192831.html

    optimizer schrieb:

    Auf der anderen Seite XNA, was zwar (meiner Meinung nach) ein schönes, sauberes API hat, aber unflexibel ist wegen der XBox-Kompatibilität

    Was geschwindigkeitsfragen angeht, ist doch immer das gleiche C++ ist schneller und C# ist ja soviel langsamer, etc. Naja viel liegt doch wohl am Programmierer selber und welche alten rechner musst du bediehnen, damit du wirklich C++ effektiv ausnutzt?

    Du musst bedenken dass viele leute ein paar hundert euro mehr ausgeben um die 30% mehr leistung zu bekommen die du vielleicht mit der nutzung von c# wieder kompensierst. klar, ein pong macht in c# und c++ kein unterschied. wenn du aber mal lange optimierst sodass z.b. in inner-loops arrayzugriffe sehr schnell ablaufen und dann baut dir c# nen boundcheck ein der 5mal laenger dauert als du mit dem array machst, ist es schon deprimierend.

    Mit C# bist du halt viel schneller und in verbindung mit XNA kannst du Dich auf Dein Problem konzentrieren und musst dich nicht mit anderen Sachen aufhalten. Von daher ist die Frage eher - was habe ich, was will ich machen, wo soll es laufen und wann soll es laufen. Dann kann ich sagen ich nutze die und die Sprache.

    👍

    Ich persönlich stell jetzt nicht die Geschwindigkeits defizite fest. Kann mir aber gut vorstellen, dass es grad auf schlechteren Rechnern einbricht. XNA ist ja "fast" eine C++ Anwendung geworden, es wird vorher Compiliert und nicht Interpretiert und somit wurde auf Geschwindigkeit geachtet. Aber ein perfekter Vergleich wäre wohl nicht so einfach möglich, da es von zuvielen Faktoren abhängen würde.

    das stimmt schon, die meisten wissen nichtmal was der limitierende faktor ihrer anwendung ist, profilen nicht und optimieren ins blaue und hoffen dann, dass es was bringt... deswegen ist ein vergleich nicht einfach, denn einfach nur was schreiben und testen ist dumm. man muss analysieren wo die probleme dann liegen und es versuchen zu optimieren, erst dann kann man entscheiden wo man limitiert ist. aber mit so nem c't DAUvergleich ist das nicht getan. Java war am anfang auch interpretiert und bei den meisten anwendungen hat es kaum jemand gemerkt dass es faktor 10 langsammer ist/war als c++.

    0
  • ?

    Übrigens: Die Windows Forms Unterstützung für XNA 2.0 wurde abgeblasen. So wird es wohl auch weiterhin ein Krampf bleiben, zum Beispiel nen Editor zu schreiben.

    Wegen der Performance: Was kostet denn jetzt _bei der Grafikdarstellung_ effektiv CPU-Zeit? Bei mir sind es vor allem der Scene graph traversal, bei dem ein Matrix-Stack mitgeführt wird und Instanzen gleicher Geometrie zusammengefasst werden und dann die API calls.

    Beim scene graph traversal hat man mit .Net anscheinend wirklich noch nen Nachteil, weil der JIT-compiler fast nichts inlined. Das betrifft insbesondere die Matrix-Multiplikationen. Dann hab ich noch ein bisschen Intersect-Tests zwecks picking, aber ich muss schon insgesamt sagen, ich habe dort keine Probleme.

    Die API calls sind bei mir der größere Posten und den muss ich immer zahlen, egal welche Sprache. Da ich aber bald Hardware Instancing nutzen werde, ist das Rennen noch offen. 🙂

    0
  • T

    zu
    http://www.c-plusplus.net/forum/viewtopic-var-t-is-192831.html

    Also die erwähnte gekoppelte Einschränkung von PC zu XBox durch XNA. Das meiste kann ich dennoch nicht bestätigen.

    Zur Content pipeline - klar, wird benötigt wegen Crossplatform. Aber wer benötigt bitte Inhalte nicht vor der Laufzeit? Was bringt mir eine Ressource zur laufzeit? Also Inhalt hinzufügen und fertig ist der stress, kann jetzt nicht verstehen wie mich das jetzt einschränkt, gegenüber GDI oder was auch immer ..
    Wer Kreisbilder zur Laufzeit laden will, bitte schön - wenn das nicht vorher geht

    Auch erwähnte Direct3D-API-Funktionen werden weiterhin unterstützt. Die Grundlegende Entwicklung war doch so: DirectX C++ - MDX - XNA. Nun wird MDX nicht mehr weiterentwickelt weil XNA ablösung da ist. XNA ist in Mehreren schichten aufgebaut, möchte jetzt nicht auf den kompletten aufbau eingehen, aber da enthalten ist MDX und MDX hat wiederum auch die DirectX API Funktionen aus C++ zeiten, warum sollten sie die verwerfen? Irrgenwo muss ja die einfachheit von XNA herkommen .. dort enthalten auch die Intersects Tests sowie auch neue sachen. Sachen die das leben erheblich vereinfachen. Quaternions etc.

    Bzw. wie dort angedeutet gibts für die Dynamik massig möglichkeiten, auch mit wenig aufwand - plus .NET unterstützung, was mit nochmehr aufwand erspart.

    In XNA 2.0 kommt doch jetzt "nur" als hammer neuerung die XBox life unterstützung hinzu und das ich endlich auf allen VS 2005 entwickeln DARF - was nicht heißt das es nicht vorher shcon ging. Vlt. paar Funktionsverbesserungen, man darf gespannt sein.

    Optimizer schrieb:

    Übrigens: Die Windows Forms Unterstützung für XNA 2.0 wurde abgeblasen. So wird es wohl auch weiterhin ein Krampf bleiben, zum Beispiel nen Editor zu schreiben.

    Jop. Habs mir jetzt noch nicht angesehen, aber kann mir ganz blauäugig nicht vorstellen, was jetzt daran so wild sein soll, manuell WinForms in mein XNA Projekt zu integrieren. OK bis auf nen schönen Formulars-Editor und "Point and Click adventure" muss ich halt selber mal coden .. aber sosnt dürfte es doch gehen, oder?

    Was auf jeden Fall eine Einschränkung ist - ist die XInput- Schnittstelle für die EIngabegeräte. kA was sich MS da gedacht hat, aber es werden NUR XBox Controller unterstützt. d.h. falls man PC-Lenkräder,Controller.. nutzen möchte muss ein Direct-Input wrapper her. Hab nie verstanden warum dann XInput und nicht Direct Input erweitert wurde ..

    Ich fand anfangs XNA auch nicht toll - wollte es aber mal ausprobieren, weil vorurteilig sein wollt ich auch nicht und man muss ja allem neuen mal eine Chance geben. Finds eig. ziemlich cool - vorallem da es langsam mal soetwas wie eine Gemeinschaft gibt und man nicht immer alles selber entwickeln muss, da es sehr viele Beispiele zu allen möglichen sachen gibt.. Einsteiger haben es auch sehr viel einfacher. Rundum könnte daraus echt viel mehr und viel schneller werden als noch mit DX mit C++. Aber Ob es jemals den Kommerziellen Markt bedienen wird, sei fraglich, C# wird da ja auch kaum eingesetzt außer für Tools etc.

    rapso schrieb:

    Was geschwindigkeitsfragen angeht, ist doch immer das gleiche C++ ist schneller und C# ist ja soviel langsamer, etc. Naja viel liegt doch wohl am Programmierer selber und welche alten rechner musst du bediehnen, damit du wirklich C++ effektiv ausnutzt?

    Du musst bedenken dass viele leute ein paar hundert euro mehr ausgeben um die 30% mehr leistung zu bekommen die du vielleicht mit der nutzung von c# wieder kompensierst. klar, ein pong macht in c# und c++ kein unterschied. wenn du aber mal lange optimierst sodass z.b. in inner-loops arrayzugriffe sehr schnell ablaufen und dann baut dir c# nen boundcheck ein der 5mal laenger dauert als du mit dem array machst, ist es schon deprimierend.

    Naja, wenn ich mir die rasende Entwicklung so anschaue, würde ich eine schneller und bequämere Entwicklung dem vorziehen. Ohne Grund sind Hochsprachen nicht entstanden. Aber kommt halt immer auf die Ressourcen an die man hat, um zu Entwickeln.. so pauschalisieren würde ich das auch nicht. Aber wenn was schnell fertig sein muss und das nicht gerade mit minimaler qualität, würde ich lieber den nutzer ein paar prozentchen rechenleistung abstreichen.

    0
  • ?

    T_R_o_u_B_L_E schrieb:

    Zur Content pipeline - klar, wird benötigt wegen Crossplatform. Aber wer benötigt bitte Inhalte nicht vor der Laufzeit? Was bringt mir eine Ressource zur laufzeit? Also Inhalt hinzufügen und fertig ist der stress, kann jetzt nicht verstehen wie mich das jetzt einschränkt, gegenüber GDI oder was auch immer ..
    Wer Kreisbilder zur Laufzeit laden will, bitte schön - wenn das nicht vorher geht

    Ja "bitteschön" - es ist aber nicht mehr genauso trivial wie es vorher war. Ich fand die GDI gelegentlich ganz praktisch um Resourcen zu erstellen und als Textur zu laden. XBox hat keine GDI -> XNA hat keine Schnittstelle zu GDI. Insbesondere bei den Schriften stört mich das bei meinen Experimenten mit XNA inzwischen krass. Selbst ne downgescalte Schrift sieht scheiße aus, zum Beispiel hier: http://firbach.dyndns.org/garbage/schrift.png
    Die Schrift-Textur hat hier genau die 4fache Größe wie die Schrift dann auf den Bildschirm konnt - und es schaut wirklich schlecht aus. In Originalgröße schaut es ganz ok aus, aber wie arbeitest du dann mit verschiedenen Auflösungen? Ich möchte jedenfalls nicht die Schrifttexturen in hundert Größen erstellen.

    Amsonsten finde ich die Content Pipeline ziemlich praktisch, ich hab auch schon eigene Prozessoren dafür geschrieben, aber manchen Content find ich besser dynamisch zu erzeugen.

    Auch erwähnte Direct3D-API-Funktionen werden weiterhin unterstützt. Die Grundlegende Entwicklung war doch so: DirectX C++ - MDX - XNA. Nun wird MDX nicht mehr weiterentwickelt weil XNA ablösung da ist. XNA ist in Mehreren schichten aufgebaut, möchte jetzt nicht auf den kompletten aufbau eingehen, aber da enthalten ist MDX und MDX hat wiederum auch die DirectX API Funktionen aus C++ zeiten, warum sollten sie die verwerfen? Irrgenwo muss ja die einfachheit von XNA herkommen .. dort enthalten auch die Intersects Tests sowie auch neue sachen. Sachen die das leben erheblich vereinfachen. Quaternions etc.

    Es fehlen halt einfach Funktionen wie das automatische generieren einer BoundingBox aus nem Mesh oder Polygongenaue Kollision -> muss man selber schreiben, in D3DX von Haus aus vorhanden. Ich gehöre nicht zu den Leuten, die das nicht auf die Reihe kriegen, aber irgendwie will ich in meiner begrenzten Freizeit lieber ein Spiel schreiben. BoundingSpheres sind nicht immer ein geeigneter Ersatz, ich habe halt auch recht unförmige Objekte, die nicht ungefähr rund sind.

    Bzw. wie dort angedeutet gibts für die Dynamik massig möglichkeiten, auch mit wenig aufwand - plus .NET unterstützung, was mit nochmehr aufwand erspart.

    Häh? Was willst du damit sagen?

    In XNA 2.0 kommt doch jetzt "nur" als hammer neuerung die XBox life unterstützung hinzu und das ich endlich auf allen VS 2005 entwickeln DARF - was nicht heißt das es nicht vorher shcon ging. Vlt. paar Funktionsverbesserungen, man darf gespannt sein.

    Zum Beispiel Parameter auf Content-Prozessoren, sehr nützlich und ein "virtualisiertes Device" - recht angenehm, aber wenn man jetzt auf Basis des Application Models das Device handling schon hat, kein so großer Gewinn mehr wie wenn man von vorne anfangen würde, IMHO.

    Optimizer schrieb:

    Übrigens: Die Windows Forms Unterstützung für XNA 2.0 wurde abgeblasen. So wird es wohl auch weiterhin ein Krampf bleiben, zum Beispiel nen Editor zu schreiben.

    Jop. Habs mir jetzt noch nicht angesehen, aber kann mir ganz blauäugig nicht vorstellen, was jetzt daran so wild sein soll, manuell WinForms in mein XNA Projekt zu integrieren.

    Offensichtlich hast du es halt noch nicht versucht. Sonst wärst du schon über Sachen gestolpert wie dass das KeyDown und KeyPress event unterdrückt werden. Das XNA Team benutzt die Winforms intern um das Fenster zu erzeugen und dann hacken sie noch eine Menge darauf rum. Und richtig gut benutzen kannst du dieses Form nicht, geschweige denn kannst du den Grafikkontext innerhalb einer Form haben (neben anderen Controls), außer du verzichtest auf das ganze application model, erstellst dein eigenes Form, verwaltest selber device reset usw. und dann verfrickeln sie dir dein Fenster wahrscheinlich immer noch.

    Was auf jeden Fall eine Einschränkung ist - ist die XInput- Schnittstelle für die EIngabegeräte. kA was sich MS da gedacht hat, aber es werden NUR XBox Controller unterstützt. d.h. falls man PC-Lenkräder,Controller.. nutzen möchte muss ein Direct-Input wrapper her. Hab nie verstanden warum dann XInput und nicht Direct Input erweitert wurde ..

    Und die Keyboard-Unterstützung suckt auch, weil sie nicht mehr event-basiert ist, sondern du pollen musst (hab ich schon erwähnt, dass die Events teilweise komisch unterdrückt werden, findet man auch in den XNA-Foren Threads dazu). Das ist weder für Editoren noch für RTS-Games wirklich ideal... Außerdem hab ich da im Moment ne Sache laufen, die in jedem Frage so ein komisches Keys-Arrays allokiert. GetPressedKeys() : Keys[] und das muss ich mir merken bis zum nächsten Frame, wieder alle GetPressedKeys() nehmen und vergleichen, was vielleicht losgelassen wurde oder neu gedrückt wurde. So eine Scheiße, nur weil das API so schlecht ist. Wenn man in nem Spiel ne Chat-Möglichkeit oder sowas einbaut gibt es halt leider nicht nur eine Handvoll Tasten, die man einzeln prüfen kann, sondern man braucht einfach alle States. Da hatten die Entwickler wohl nur ihre XBox-Controller im Kopf und haben dann gedacht "ja scheiße, Tastatur mach ma auch noch schnell"

    XNA ist schon nett und das Grafik-API und vor allem das Effect-Framework sehr sauber. Aber es leidet unter ein paar Krankheiten, die mich echt stören.

    0
  • R
    Mod

    T_R_o_u_B_L_E schrieb:

    rapso schrieb:

    Was geschwindigkeitsfragen angeht, ist doch immer das gleiche C++ ist schneller und C# ist ja soviel langsamer, etc. Naja viel liegt doch wohl am Programmierer selber und welche alten rechner musst du bediehnen, damit du wirklich C++ effektiv ausnutzt?

    Du musst bedenken dass viele leute ein paar hundert euro mehr ausgeben um die 30% mehr leistung zu bekommen die du vielleicht mit der nutzung von c# wieder kompensierst. klar, ein pong macht in c# und c++ kein unterschied. wenn du aber mal lange optimierst sodass z.b. in inner-loops arrayzugriffe sehr schnell ablaufen und dann baut dir c# nen boundcheck ein der 5mal laenger dauert als du mit dem array machst, ist es schon deprimierend.

    Naja, wenn ich mir die rasende Entwicklung so anschaue, würde ich eine schneller und bequämere Entwicklung dem vorziehen. Ohne Grund sind Hochsprachen nicht entstanden. Aber kommt halt immer auf die Ressourcen an die man hat, um zu Entwickeln.. so pauschalisieren würde ich das auch nicht. Aber wenn was schnell fertig sein muss und das nicht gerade mit minimaler qualität, würde ich lieber den nutzer ein paar prozentchen rechenleistung abstreichen.

    Klar, der grund ist eben die einfache Entwicklung ohne sonderlichen Anspruch an die programmierer. so war das schon immer und ist keine sonderlich neue geniale erfindung wie sie es als solche verkauft wird, auch vor 20jahren gab es hardcore assembler, und strukturierte sprachen und highlevel sprachen wie basic.
    MS hat nicht in einem jahr c# erfunden ;), sie haben sich auch nicht .NET mal eben ausgedacht. Es ist die normale Visual Basic runtime (die zu der zeit zufaellig verschwand und ein VB.NET rauskam 😉 😉 ), darauf deren c parser der nur das erlaubt was in VB moeglich war.
    Dann gab es ein paar "C# ist viel geiler als java"-marketingaktionen um sun den verlorenen rechtsstreit wegen java heimzuzahlen.

    aber wie gesagt, so war es schon immer und so wird es weiter sein. und ich finde es auch gut so. frueher wurde man geflamed wenn man hobbyprogrammieren oder lightweight-programmieren in firmen sagte sie sollen doch lieber VB benutzen. weil sich alle als n00b abgestempelt fuehlten.
    Heute hingegeben kann man ganz normal sagen "nimm lieber c#/java, damit faehrst du besser" und alle sind zufrieden. Optimizer trifft es auch ziemlich gut. Er ist nicht zu doof sich ne collisionlib zu basteln, er will schlichtweg nur nicht seine zeit dafuer verschwenden. Er hat auch kein problem damit nen matrixstack zu nutzen der die meiste performance zieht, wo es bei normalen engines kaum im profiler auftaucht. (edit: damit meine ich, dass es ihm nicht auf jede microsekunde ankommt wie z.b. bei mir auf der arbeit *Hehe*)

    nicht jeder faehrt ferrari.

    ich weine sicherlich auch nicht, dass ich keine zeit habe meine engines komplett in assembler zu coden und c++ compiler oft superdumm sind.

    0
  • T

    Jo bin aus ähnlichen Gründen zu C# gekommen. Anfangs war man zu stolz, "ich code alles selber" dann kam das Studium, die Zeit wurde knapper und irrgendwann ist sie so kostbar, dass man sich auf das problem konzentrieren will und nicht aus jedem scheiß prozente rausholen will. Aber es ist halt viel entspannter und angenehmer. Wenn man dann sein alter EGO überwunden hat, bemerkt man das dennoch Programmieraufwand zu bewältigen ist. In nem Spiel gibt es soviel zu tun, das einem arbeit abgenommen wird und wieder Arbeit entsteht .. zu tun gibt es immer. Und behauptet ja keiner das man es nicht auch alleine hinbekommt, aber wie gesagt es ist halt engenehmer ..

    Bzw. wie dort angedeutet gibts für die Dynamik massig möglichkeiten, auch mit wenig aufwand - plus .NET unterstützung, was mit nochmehr aufwand erspart.
    Häh? Was willst du damit sagen?

    Soll heißen du kannst auch ohne Contentpipeline oder auch mit eine gewisse dynamik wie "in alten Zeiten" gewährleisten. z.B. kannst du mit .NET auch ne GDI nutzen, ok wär jetzt dirty, aber immerhin 🕶
    bzw. man kann sich halt hinsetzen und überlegen wie es besser gelöst werden könnte, dynamischer ohne einschränkungen. Wenn es auf den PC laufen soll, ist eig. massig möglich.

    Ja "bitteschön" - es ist aber nicht mehr genauso trivial wie es vorher war.

    Hm bis auf das du den Inhalt ins Projekt integrieren muss - zwecks Compile vorgang, ist es doch noch flexibler als mit GDI, da du eine Schnittstelle für alle Contents hast und nur noch den name, sogar ohne dateiendung angeben musst. + die Möglichkeit eignen Contenprozessor zu implementieren um zusätzlioche Aufgaben zu erledigen was dir noch mehr flexibilität gewährleistet. Naja ist im ende fekt auch egal, jedem das seine. Klar wenn's perfekt wär, wärs auch scheiße, mal sehen wie sich das ganze weiterentwickelt.

    Zwecks XInput, wie gesagt - Direct-Input Wrapper. Da gibts einige gute, der hilft einem gegenüber der schlechten XInput lösung.

    0
  • A

    Optimizer schrieb:

    Übrigens: Die Windows Forms Unterstützung für XNA 2.0 wurde abgeblasen. So wird es wohl auch weiterhin ein Krampf bleiben, zum Beispiel nen Editor zu schreiben.

    Das geht eigendlich sehr einfach, ich hatte nen xna projekt erstellt,
    fast alles rausgelöscht und da ne windows form reinkopiert.

    Witzige war ,auf diese Weise ist es sogar möglich mit c#-express
    Windowsprogramme im release modus zu erstellen, war zwar sicher nich im
    Sinne des Erfinders, aber naja 🙂

    Wollte auch mal nen editor basteln, hatte dann nen schönes Fenster mit xna drin.

    0
Anmelden zum Antworten