Unreal Engine 4

Schwer was dazu zu sagen, ohne den Code gesehen zu haben. Aber wenn die vorhandene Linux-Portierung sauber ist, sollte sich der Aufwand für eine FreeBSD-Portierung sehr in Grenzen halten. Selbst bei fast allen Nicht-SDL-Spielen, die ich bisher unter den Fingern hatte, beschränkte es sich meist auf vier Dinge:
- /proc und /sys auf sysctl umbauen.
- Einige standardinkonforme pthread-Aufrufe ersetzen.
- Das Sound-Backend anpassen. Wenn kein OpenAL genutzt wird, der mit Abstand größte Brocken.
- Dem Netzwerkcode die Linuxiszmen austreiben.
Also mit einer oder zwei Wochen Zeit und ein wenig Bastelleidenschaft eventuell zu machen.
 
Das geht ja potentiell mit einem Playstation 4 Port recht Hand in Hand, oder? Also so, dass man dann erwarten kann, dass sich die beiden Communities recht ergänzen würden was die Stabilität auf diesen Plattformen angeht. Das nimmt vielleicht die Scheu, wenn man weiß, dass man nicht der einzige Dev ist, der da was macht.

PS: Zahlen, dass man programmieren darf ist irgendwie ein ganz witziges Konzept.
 
Mit dem PS4 Port hat das nicht viel am Hut denke ich.
Er bezieht sich vermutlich darauf, dass als OS ist der PS4 ein FreeBSD9 verwendet wird. Ich denke aber auch, dass dies nicht wirklich hilft. Auf dem PC brauchst du einen weiteren Layer wie OpenGL oder Direct3D. Auf einer Konsole ist das nicht nötig und man verwendet eine sehr nahen Hardwarelayer. Mit Mantle versucht AMD so etwas auch auf dem PC. Läuft aber nur mit AMD/ATI Karten und Nvidia scheisst drauf.
 
Ich dachte eher an die Dinge, die Yamagi sonst noch aufgelistet hat. Leider gibt's da aber auch wenig Infos (oder ich finde sie blos nicht), was das betrifft. Ich gehe mal nicht davon aus, dass die procfs verwenden, Grund haben an den pthreads viel zu ändern oder gar am Netzwekstack groß rumzutüfteln.

Seid ihr euch bei OpenGL so sicher? Mich wundert das teilweise, weil das ja eigentlich auch die Portierung von Engines schwieriger macht (andererseits hat man da ja auch Vorteile - klar). Würde aber grundsätzlich schon denken, dass das da zur Verfügung steht. Immerhin verwenden die dort Cairo, aber auch diverse andere Dinge (Webkit, etc.) wo das ganz gut wäre. Natürlich hat das nicht so viel mit der Unreal Engine zu tun. Naja, vielleicht nimmt sich ja jemand hier mal ein Abo und kann berichten, wie gut/schlecht es da für FreeBSD (vielleicht auch andere BSDs) aussieht und ob es sich da auszahlt zu abonnieren und mitzuprogrammieren.
 
Die PS4 bietet selbst, soweit ich das noch in Erinnerung habe, auch OpenGL ES Support. Das ist hauptsächlich für die ganze Reihe an Indie-Titeln oder sonstigen Ports (à la Minecraft und Co.). Die API ist aber selbst nur als Fallback anzusehen.

Die Playstations hatten seit jeher eigentlich eine Low-Level API (Stichwort libGCM), womit die meisten Entwickler gearbeitet haben werden. Das kann man alles im Stil von Mantle ansehen, da Mantle nichts anderes ist, als eine "Konsolen API" für den PC. Nicht portabel und potentiell hardwareabhängig.

Ansonsten bringt ein PS4-Spiel für FreeBSD direkt nichts. Kein Spieleentwickler wird direkt gegen einen Kernel oder bestimmte Userland-Sachen programmieren. Da gibt es ein spezifisches SDK von Sony und das war's.

Viel besser für FreeBSD wäre es imo, wenn die Spiele etwas mehr auf "Standards" setzen würden. Also sowas wie C++11 und SDL2. womit dann schon ein gewaltiges Stück Portabilität geschaffen wurde. Hier ist dann nur noch das OpenGL Treiberchaos die Bremse. Darum bieten auch unter Linux Steam die Spiele meist nur Support für NVidia.
 
Das kann man alles im Stil von Mantle ansehen, da Mantle nichts anderes ist, als eine "Konsolen API" für den PC. Nicht portabel und potentiell hardwareabhängig.
Das stimmt nicht ganz. Es gab schon eine Antwort für Linux aber dies sei noch nicht spruchreif und auch Nvidia ist herzlich eingeladen, sich an Mantle zu beteiligen.

Die API der PS4 nennt sich GNM. "The PlayStation 4 features two graphics APIs, a low level API named GNM and a high level API named GNMX"
 
Das stimmt nicht ganz. Es gab schon eine Antwort für Linux aber dies sei noch nicht spruchreif und auch Nvidia ist herzlich eingeladen, sich an Mantle zu beteiligen.

Das Problem ist, dass Mantle rund um die momentane Architektur der AMD Grafikchips aufgebaut ist. Es gibt nicht wenig Stimmen, die behaupten, dass selbst wenn NVidia wollen würde, es einfach nicht klappen würde (das sagt sogar AMD selbst), da Mantle halt eben so hardwarenah ist. Und wenn die Hardware nicht so arbeitet, wie Mantle es vorsieht, ist jeglicher Vorteil dahin.

Man braucht auch nicht erwarten, dass Mantle eine strahlende Zukunft hat. Die Nachteile sind einfach zu groß. Zum Einen hilft Mantle nur bei schwachen CPUs in Kombi mit starker GPU. Zum Anderen wird Mantle sich dauernd ändern. Jetzt läuft Mantle noch "hardwarenah". Wenn AMD seine kommende Architektur mal großartig umbauen sollte, wird Mantle nur noch emuliert (oder gleich gesagt, man solle wieder DX/OGL nehmen) und es wird ein neues Mantle, mit anderer API geben.

Es gibt nicht umsonst APIs mit mehr Overhead. ;) Hardwarenah und Portabel beißt sich halt.
 
Zurück
Oben