Zitat:
Original geschrieben von SeeksTheMoon
Früher hat man auch gesagt, C wäre viel zu langsam, nur Assemblerprogramme wären richtig gut. Bullshit, wie man heute sieht.
Wobei in bestimmten Gebieten immer noch Assembler eingesetzt wird.
DSP Codecs zum Beispiel.
Aber der Trend ist dort auch, dass man solche Module praktisch vom Hersteller des DSP kauft, bzw von einer darauf spezialisierten Drittfirma.
Zitat:
alle Bibliotheken müssen kostenlos verfügbar sein, sich aber für geheim gehaltenen Quellcode eignen und weiterhin entwickelt/supportet werden.
Sind wir ein kleiner Freeloader, hmm? :D
Zitat:
1. Man hat für 3D-Grafik die Wahl zwischen GL4Java und Java3D.
Hat schon jemand Erfahrungen mit den neuen GL Bindings von SGI (falls es die schon gibt)?
Zitat:
b) Die Plattformunabhängigkeit ist im Ar..., weil: J3D gibts nur für Windows und Solaris (wer benutzt Solaris?), die Linuxversion hinkt ein Stück hinterher und wird von Sun nicht supported. Eine Mac-Version gibts überhaupt nicht!
Sun ist leider sehr gut darin, sich selbst in den Fuß zu schiessen.
Das "böse" Linux wurde bewußt vernachlässigt, was keine so gute Idee war, weil dort doch viele Entwickler unterwegs sind und dadurch Java nicht gerade guten Ruf in der Zielgruppe bekommen hat.
Ein ähnliches Stiefkind bei den APIs ist das Java Media Framework.
Rick Ross, der JavaLobby Gründer schimpft da öfter :)
Zitat:
c) Wie bei allen Libs, muss man dieses Paket vom Anwender installieren lassen.
Nunja, das dürfte bei allen Sprachen so sein.
Zitat:
3. Video-Bibliotheken
Ich hab bis heute noch keine Lib gefunden, die divx oder sonstige Formate abspielt. Das hat wohl lizenztechnische Gründe.
Dazu muss man ein paar Postings von Rick Ross lesen :)
Eine der Ausweichlösungen die auch von ihm benutzt wird, ist eine Quicktime Bibliothek für Java, allerdings geht die wieder nicht unter Linux.
Zitat:
6. Kommerzielle Anwender wollen sich nicht in den Sourcecode schauen lassen
Also muss man den Java Bytecode durch einen Obfuscator jagen.
Diese ganze Obfusicator Sache ist mir immer höchstens suspekt.
Bei Bedarf kann man auch echten Maschinencode reverse-egninieeren, besser wäre es, die interessante Teile an Interessierte unter günstigen Konditionen zu lizensieren.
Zitat:
Eigentlich muss man sich schon eine eigene Engine schreiben, weil es keine fertigen gibt (s.u.), aber dann erstickt man in diesem Bibliotheken-Müll von dem keiner weiß ob diese zusammengeschusterte, fette Konfiguration auf anderen Rechnern läuft.
Wenn es etwas nicht gibt, aber Nachfrage danach besteht, nennt man das eine Marktlücke :)
Zitat:
Man braucht eine Bibliothekensammlung, die wirklich alles abdeckt.
Deswegen gibt es auch im Fahrwasser der Spieleindustrie eine große Anzahl von Bibliothekerzeugern, die dann Engines, Sounds- und Videobibliotheken machen.
Praktisch keine Spielefirma macht die selbst, das ist in Anbetracht von Time-To-Market keine gangbare Lösung.
Teilweise gibt es da aber große Kommunikationsschwierigkeiten, besondern was Angebot und Nachfrage betrifft.
Einige erinnern sich sicher an das Never Winter Nights Debakel, wo die Spiele Firma wochenlang nach einer Linux Alternative für ihre Soundlib gesucht hat, bis der Hersteller durch as Medienecho drauf gekommen ist und die Firma draufhinwies, dass es ohnehin auch eine Linuxversion gäbe.
Zitat:
Oder man fängt echt bei Adam und Eva an und baut sich ein komplett eigenes SDK aus komplett eigenen Grafik-, Sound-, Loader-, Video-Bibliotheken und dann ein Spiel das darauf basiert.
Gibt es eigentlich eine Java API zu SDL?
Zitat:
Die Spielefirmen haben teilweise andere Interessen; so interessiert sie die plattformunabhängigkeit nicht immer (dank Zielgruppenbestimmung und Marktanalyse)
Das ist glaub ich nicht so richtig, je nach Genre sind die Firmen durchaus daran interessiert, das Spiel auch auf diversen Konsolen anbieten zu können, bzw. einen Konsolentitel auch auf PCs.
Zitat:
und für eine eigene Engine, die genau auf die Bedürftnisse zurechtgemacht ist, muss man auch keine Lizenzen bezahlen oder fremden Support bemühen (sofern es ihn gibt).
Wobei man hier sieht, dass das zweite offensichtlich der bevorzugte Weg ist.
Ciao,
_