SWITCH - Spieleankündigungen und Gerüchte
Moderatoren: Moderatoren, Redakteure
Re: SWITCH - Spieleankündigungen und Gerüchte
Ich bezweifle mal stark dass das Spiel weltweit mehr als 100k absetzen würde... und das ist noch optimistisch
[img]http://img253.imageshack.us/img253/4290/xenobanner3.jpg[/img]
Wii Besitzer sind bereits seit über 3 Jahren Ehrlicher und Aktueller Informiert
viewtopic.php?t=38131
Die LAST GEN begann für PSWii60 am 18.11.2012
Wii Besitzer sind bereits seit über 3 Jahren Ehrlicher und Aktueller Informiert
viewtopic.php?t=38131 Die LAST GEN begann für PSWii60 am 18.11.2012
Re: SWITCH - Spieleankündigungen und Gerüchte
Es geht darum, dass UE4 in C++ läuft. Diese Sprachen haben wiederrum Bytewandler, also können Bytes auslesen und daraus eigenen Code bilden.
Dies ist eine recht gute Möglichkeit um eine Schnittstelle zwischen Sprachen herzustellen, oder aber auch, um Code teilweise umzuwandeln, von einer in eine andere Sprache.
Re: SWITCH - Spieleankündigungen und Gerüchte
Ich bin nun seit 15 Jahren Entwickler... Habe die Waisheit weiß FSM nicht mit dem Löffel gefressen...
Aber ich glaube nicht, dass soetwas auch nur entfernt praktikabel für die Portierung einer sehr komplexen Echtzeitanwendung ist.
(das Reimwerfen von irgendwelchen Programmiersprachen hilft nicht gerade dabei, dass das irgendwie glaubhaft ist)
Aber ich glaube nicht, dass soetwas auch nur entfernt praktikabel für die Portierung einer sehr komplexen Echtzeitanwendung ist.
(das Reimwerfen von irgendwelchen Programmiersprachen hilft nicht gerade dabei, dass das irgendwie glaubhaft ist)
Re: SWITCH - Spieleankündigungen und Gerüchte
Woah. Da mixt aber einer gehörig was durcheinander. Ich weiß gar nicht, ob ich jetzt in einem Post alles erschlagen kann... aber vielleicht die wichtigsten Dinge:
Ein Byte ist eine Informationsmenge, heute üblicherweise 8 Bit (ja, es gab tatsächlich Architekturen wo das nicht so war, wie die PDPs, aber ich schweife ab). Ein Byte hat an sich also erstmal nicht per se was mit Programmcode zu tun.
Was du meinst ist wahrscheinlich der Begriff Bytecode. So bezeichnet man in Java den Zwischencode den der Java-Compiler aus dem Programmtext erzeugt, und der auf der Zielmaschine erst bei der Ausführung von der Java Virtual Machine „zuendeübersetzt“ wird. Die JVM macht das, weil man beim Kompilieren noch gar nicht weiß, was die CPU für Befehle versteht, denn Java-Programme sind maschinenunabhängig ausführbar („compile once, run everywhere“). Entsprechend ist es sinnvoll beim Kompilieren erstmal die Schritte vorwegzunehmen, die für alle Architekturen gleich sind (Schleifen durch JMP-Opcodes ersetzen etc.). Diesen Bytecode, der eine Art Maschinensprache für einen theoretischen Prozessor darstellt, übersetzt man dann auf der Zielmaschine bei der Ausführung in den benötigten Maschinencode, den der jeweilige Prozessor versteht. Daher ist ein bestimmtes Java-Executable (meist .jar, was nichts anderes ist als ein Haufen .class-Bytecode-Files in einem umbenannten .zip) auf allen Systemen ausführbar, für die es eine JVM gibt, egal ob x86, ARM, Sparc oder PowerPC, etc.
Darüberhinaus legt Java Wert darauf, den Programmierer von hässlichen Details wie der Speicherverwaltung fernzuhalten, indem es selbst über seine Objekte durch Referenzzählung Buch führt und diese, falls nicht mehr benötigt, löscht (Garbage Collection). Das führt dazu, dass es a) keine Memory Leaks mehr geben kann, aber b) keiner so genau weiß, wann Java das denn tut, d.h. der Speicherbedarf kann sich auch mal etwas aufblähen.
Für zeitkritische Echtzeitanwendungen ist sowas in den seltensten Fällen geeignet. Es gibt zwar Spiele in Java (bestimmte Minecraft-Versionen z.B.), aber eine Spielengine für eine Konsole oder vergleichbares würde man so nicht entwickeln.
Unreal 4 hat *vermutlich* (ich habe mit UE4 selbst keine Erfahrungen, nur mit Unity/C#) eine eigene Skriptsprache, die mit ähnlichen Methoden arbeitet. Skripte werden meist zur Automatisierung von Spielobjekten eingesetzt (Spieler erreicht Punkt a, Ereignis b wird ausgelöst, etc.), weil sie in der Entwicklung simpler handhabbar sind. Das ist meist nicht-typsicherer Code, der während der Ausführung interpretiert wird, oder eben auch in einer Art Bytecode vorübersetzt vorliegt. Sowas haben die meisten Engines. Viele binden auch einfach vorhandene Sprachinterpreter ein und legen entsprechende Schnittstellen für den Skriptentwickler offen. World of Warcraft und viele andere Spiele nutzen z.B. Lua.
Unreal 4 „läuft“ auch nicht in C++. Tatsächlich kann man bei den kompilierten Sprachen wie C/C++/Fortran etc. gar nicht sagen, dass es „in der Sprache“ läuft, so wie Java in einer JVM laufen muss. Denn im Unterschied dazu sind Programme, die mit einer dieser voll-kompilierten Sprachen erstellt werden vollständiger Maschinencode. D.h. der Compiler übersetzt den Quellcode (ein Textfile) in Befehle, die mehr oder weniger durchnummeriert sind. So lautet der Befehl für den Z80 (Master System, Gameboy, etc.) das Register B um eins zu erhöhen schlicht „04“ (Achtung, hexadezimal), ist also genau ein Byte groß. Man könnte diese Befehle auch alle von Hand schreiben (und bei der Assemblerprogrammierung macht man das fast, denn da werden diesen nackten „Befehlsbytes“ schlicht Namen gegeben), aber damit lassen sich keine komplexeren Strukturen bilden, und genau deshalb gibt es überhaupt Programmiersprachen und Compiler, die das alles aus einer für den Menschen gut lesbaren Form für die Maschine übersetzen. Java und C# mit ihren Zwischencodes sind quasi schon der nächste Sprung in der Abstraktion, noch weiter Weg von der Maschine als C/C++.
So. Das erstmal zur Klarstellung. Jetzt zur Idee mit der WiiU.
Der „WiiU-Code“ (genauer: PowerPC-ISA Maschinencode) ist - wie für Maschinencode eben üblich - hochgradig optimiert für genau diese Architektur. Den übersetzt man nicht mal einfach in irgendeinen Bytecode. Wenn überhaupt, dann geht man vom Sourcecode aus und lässt den von einem C++-ARM-Compiler für die ARM-Architektur der Switch übersetzen. Das wäre - wenn man nicht gerade irgendwas verwendet hat, was es eben nur speziell beim PowerPC gibt - noch relativ straightforward, aber spätestens wenn man (Software-) Betriebssystemschnittstellen ansprechen will (und das will man in einem Spiel immer, denn man will Grafik ausgeben), funktioniert das nicht mehr, denn die sind auf der Switch alle komplett anders. Das funktioniert normalerweise nur für simpelste Textkonsolenanwenwendungen.
Was man machen kann wäre, manche Schnittstellen durch eine Zwischenschicht anzusprechen. D.h. man entwickelt eine Softwareschnittstelle, die für den Originalcode aussieht wie die Betriebssystemschnittstelle der WiiU, einen sog. Wrapper. Statt die Funktionen darin selbst zu implementieren würde dieser Wrapper die Befehle an das Switch-OS weiterleiten. Das ist aber etwas, das macht man nicht mal eben mit den performancekritischen Teilen des Codes, also z.B. der Grafik. Das kann man sich eher bei Sound, I/O oder Controller vorstellen. Das wäre aber weiter alles Maschinencode. Bytecode hat nur Vorteile, wenn du beim Kompilieren nicht weißt, auf welcher Maschine dein Kunde den Code benutzen will.
Sorry für das ganze Offtopic-Chinesisch, aber da waren jetzt ein paar Punkte aufgelaufen, die ich so nicht stehen lassen wollte.
Ein Byte ist eine Informationsmenge, heute üblicherweise 8 Bit (ja, es gab tatsächlich Architekturen wo das nicht so war, wie die PDPs, aber ich schweife ab). Ein Byte hat an sich also erstmal nicht per se was mit Programmcode zu tun.
Was du meinst ist wahrscheinlich der Begriff Bytecode. So bezeichnet man in Java den Zwischencode den der Java-Compiler aus dem Programmtext erzeugt, und der auf der Zielmaschine erst bei der Ausführung von der Java Virtual Machine „zuendeübersetzt“ wird. Die JVM macht das, weil man beim Kompilieren noch gar nicht weiß, was die CPU für Befehle versteht, denn Java-Programme sind maschinenunabhängig ausführbar („compile once, run everywhere“). Entsprechend ist es sinnvoll beim Kompilieren erstmal die Schritte vorwegzunehmen, die für alle Architekturen gleich sind (Schleifen durch JMP-Opcodes ersetzen etc.). Diesen Bytecode, der eine Art Maschinensprache für einen theoretischen Prozessor darstellt, übersetzt man dann auf der Zielmaschine bei der Ausführung in den benötigten Maschinencode, den der jeweilige Prozessor versteht. Daher ist ein bestimmtes Java-Executable (meist .jar, was nichts anderes ist als ein Haufen .class-Bytecode-Files in einem umbenannten .zip) auf allen Systemen ausführbar, für die es eine JVM gibt, egal ob x86, ARM, Sparc oder PowerPC, etc.
Darüberhinaus legt Java Wert darauf, den Programmierer von hässlichen Details wie der Speicherverwaltung fernzuhalten, indem es selbst über seine Objekte durch Referenzzählung Buch führt und diese, falls nicht mehr benötigt, löscht (Garbage Collection). Das führt dazu, dass es a) keine Memory Leaks mehr geben kann, aber b) keiner so genau weiß, wann Java das denn tut, d.h. der Speicherbedarf kann sich auch mal etwas aufblähen.
Für zeitkritische Echtzeitanwendungen ist sowas in den seltensten Fällen geeignet. Es gibt zwar Spiele in Java (bestimmte Minecraft-Versionen z.B.), aber eine Spielengine für eine Konsole oder vergleichbares würde man so nicht entwickeln.
Unreal 4 hat *vermutlich* (ich habe mit UE4 selbst keine Erfahrungen, nur mit Unity/C#) eine eigene Skriptsprache, die mit ähnlichen Methoden arbeitet. Skripte werden meist zur Automatisierung von Spielobjekten eingesetzt (Spieler erreicht Punkt a, Ereignis b wird ausgelöst, etc.), weil sie in der Entwicklung simpler handhabbar sind. Das ist meist nicht-typsicherer Code, der während der Ausführung interpretiert wird, oder eben auch in einer Art Bytecode vorübersetzt vorliegt. Sowas haben die meisten Engines. Viele binden auch einfach vorhandene Sprachinterpreter ein und legen entsprechende Schnittstellen für den Skriptentwickler offen. World of Warcraft und viele andere Spiele nutzen z.B. Lua.
Unreal 4 „läuft“ auch nicht in C++. Tatsächlich kann man bei den kompilierten Sprachen wie C/C++/Fortran etc. gar nicht sagen, dass es „in der Sprache“ läuft, so wie Java in einer JVM laufen muss. Denn im Unterschied dazu sind Programme, die mit einer dieser voll-kompilierten Sprachen erstellt werden vollständiger Maschinencode. D.h. der Compiler übersetzt den Quellcode (ein Textfile) in Befehle, die mehr oder weniger durchnummeriert sind. So lautet der Befehl für den Z80 (Master System, Gameboy, etc.) das Register B um eins zu erhöhen schlicht „04“ (Achtung, hexadezimal), ist also genau ein Byte groß. Man könnte diese Befehle auch alle von Hand schreiben (und bei der Assemblerprogrammierung macht man das fast, denn da werden diesen nackten „Befehlsbytes“ schlicht Namen gegeben), aber damit lassen sich keine komplexeren Strukturen bilden, und genau deshalb gibt es überhaupt Programmiersprachen und Compiler, die das alles aus einer für den Menschen gut lesbaren Form für die Maschine übersetzen. Java und C# mit ihren Zwischencodes sind quasi schon der nächste Sprung in der Abstraktion, noch weiter Weg von der Maschine als C/C++.
So. Das erstmal zur Klarstellung. Jetzt zur Idee mit der WiiU.
Der „WiiU-Code“ (genauer: PowerPC-ISA Maschinencode) ist - wie für Maschinencode eben üblich - hochgradig optimiert für genau diese Architektur. Den übersetzt man nicht mal einfach in irgendeinen Bytecode. Wenn überhaupt, dann geht man vom Sourcecode aus und lässt den von einem C++-ARM-Compiler für die ARM-Architektur der Switch übersetzen. Das wäre - wenn man nicht gerade irgendwas verwendet hat, was es eben nur speziell beim PowerPC gibt - noch relativ straightforward, aber spätestens wenn man (Software-) Betriebssystemschnittstellen ansprechen will (und das will man in einem Spiel immer, denn man will Grafik ausgeben), funktioniert das nicht mehr, denn die sind auf der Switch alle komplett anders. Das funktioniert normalerweise nur für simpelste Textkonsolenanwenwendungen.
Was man machen kann wäre, manche Schnittstellen durch eine Zwischenschicht anzusprechen. D.h. man entwickelt eine Softwareschnittstelle, die für den Originalcode aussieht wie die Betriebssystemschnittstelle der WiiU, einen sog. Wrapper. Statt die Funktionen darin selbst zu implementieren würde dieser Wrapper die Befehle an das Switch-OS weiterleiten. Das ist aber etwas, das macht man nicht mal eben mit den performancekritischen Teilen des Codes, also z.B. der Grafik. Das kann man sich eher bei Sound, I/O oder Controller vorstellen. Das wäre aber weiter alles Maschinencode. Bytecode hat nur Vorteile, wenn du beim Kompilieren nicht weißt, auf welcher Maschine dein Kunde den Code benutzen will.
Sorry für das ganze Offtopic-Chinesisch, aber da waren jetzt ein paar Punkte aufgelaufen, die ich so nicht stehen lassen wollte.
Re: SWITCH - Spieleankündigungen und Gerüchte
Ahh gut. Und ich dachte, irgend nen neuer heißer scheiß Namens "Bytes" sei schon wieder an mir vorbei gegangen..
Re: SWITCH - Spieleankündigungen und Gerüchte
Ich nehm jetzt zumindest mal an dass das gemeint war. Ansonsten macht der Begriff in Zusammenhang mit Sprachen und Compilern wenig Sinn. Ich weiß auch gar nicht warum das bei Java Bytecode heißt, ehrlich gesagt. Bei .Net/C# isses glaub ich common intermediate language, was sperrig, aber genauer ist. Ist halt Zwischencode. Nickeligkeiten wie Just-in-time-Compiler oder adaptive Optimierung hab ich jetzt mal rausgelassen...
Re: SWITCH - Spieleankündigungen und Gerüchte
Stimmt. Der Z80-Beispiel-Opcode 04 oben müsste sowas sein wie 00000100.
Re: SWITCH - Spieleankündigungen und Gerüchte
Mit Byte-Parse meint man eigentlich Ausgeben des Byte-Wertes (also im 8bit-Format) eines Strings z.B., um die dann in einem Byte-Array im Speicher abzulegen. Dabei wird aber nichts "umgewandelt", schon gar nicht eine Programmiersprache. Zu UE4 in C++ hat yopparai schon es passend zusammgefasst.
Re: SWITCH - Spieleankündigungen und Gerüchte
Danke für die Erklärung. Ich bin aufgrund meiner rudimentären Kenntnisse mit Java und eben dem bytecode und dem was ich bisher über C# und dem ebenfalls dort vorhandenen Bytecode oder Zwischencode davon ausgegangen, dass man hierfür Programme schreiben kann, die eben diese zu wandeln. natürlich wäre dass hochgradig unoptimiert und müsste nochmal massiv angepasst werden, würde sich also eben nicht für die komplexen Teile eignen.
Aber je nachdem wie eine Sprache geschrieben ist in einer Engine liegen ja auch sehr viele Ähnlichkeiten im Code vor, diese können dann zumindest interpretiert werden.
Und ja, ein Wrapper (oder ein paar mehr davon) wäre dafür dann auf jeden Fall von Nöten.
Aber danke für die ausführliche Darstellung
Aber je nachdem wie eine Sprache geschrieben ist in einer Engine liegen ja auch sehr viele Ähnlichkeiten im Code vor, diese können dann zumindest interpretiert werden.
Und ja, ein Wrapper (oder ein paar mehr davon) wäre dafür dann auf jeden Fall von Nöten.
Aber danke für die ausführliche Darstellung
Re: SWITCH - Spieleankündigungen und Gerüchte
Ich frage mich, wofür du überhaupt auf eine andere Sprache portieren möchtest in deinem Gedankengang Oo.
Re: SWITCH - Spieleankündigungen und Gerüchte
@Alanthir: Wenn du Lust hast dir mal richtiges Grundlagenwissen in dem Bereich anzueignen und zu vertiefen, dann empfehl ich dir einen einfachen, nackten C-Compiler (nicht C++), den zugehörigen Debugger, einen simplen Texteditor und die Kommandozeile. C ist keine sehr komplexe Sprache, manch einer nennt sie auch liebevoll „High Level Assembler“. Die hat man schnell gelernt. C++ und Java sind um Größenordnungen komplexer. Dazu ein paar gute Tutorials oder ein vernünftiges Buch (vielleicht sogar eins über Hacking), und du lernst mehr über CPUs und Speicherverwaltung als dir lieb ist. Auch wenn du danach nie wieder C anfasst - die dabei gelernten Grundlagen helfen ungemein, auch in gemanageten Sprachen wie Java und C#.
_______________________
Mal was zum Thema: http://www.nintendolife.com/news/2019/0 ... ccessories
Switch Mini Zubehör beim spanischen Zweig von GAME aufgetaucht... also langsam wird‘s albern
_______________________
Mal was zum Thema: http://www.nintendolife.com/news/2019/0 ... ccessories
Switch Mini Zubehör beim spanischen Zweig von GAME aufgetaucht... also langsam wird‘s albern
Re: SWITCH - Spieleankündigungen und Gerüchte
What remains of Edith finch kommt:
https://ec.nintendo.com/JP/ja/titles/70010000019334
Die Info ist neu, oder?
https://ec.nintendo.com/JP/ja/titles/70010000019334
Die Info ist neu, oder?
Re: SWITCH - Spieleankündigungen und Gerüchte
Hab ich mich auch gefragt, als ich gestern drüber gestolpert bin. Aber ich hab komplett den Überblick verloren ^^
Sagen wir einfach mal das ist neu
Sagen wir einfach mal das ist neu
Re: SWITCH - Spieleankündigungen und Gerüchte
http://www.nintendolife.com/news/2019/0 ... w_hardware
Nintendo reagiert auf eine direkte Nachfrage bzgl. Switch Mini ausweichend.
Keine große Überraschung, allerdings ist das sogar noch weniger ein Dementi als das übliche „Wir kommentieren keine Gerüchte“... da damit von der Katze quasi nur noch die Schwanzspitze im Sack steckt würde ich mich nicht über eine sehr baldige Ankündigung wundern. Wenn sie das zu lange hinziehen wird das sonst irgendwann auch negative Auswirkungen auf die Verkaufszahlen haben durch Interessenten, die lieber abwarten.
Ich könnte momentan auch niemandem ernsthaft zum Kauf des aktuellen Modells raten, solange das neue nicht vorgestellt ist.
Nintendo reagiert auf eine direkte Nachfrage bzgl. Switch Mini ausweichend.
Keine große Überraschung, allerdings ist das sogar noch weniger ein Dementi als das übliche „Wir kommentieren keine Gerüchte“... da damit von der Katze quasi nur noch die Schwanzspitze im Sack steckt würde ich mich nicht über eine sehr baldige Ankündigung wundern. Wenn sie das zu lange hinziehen wird das sonst irgendwann auch negative Auswirkungen auf die Verkaufszahlen haben durch Interessenten, die lieber abwarten.
Ich könnte momentan auch niemandem ernsthaft zum Kauf des aktuellen Modells raten, solange das neue nicht vorgestellt ist.