Die meisten TKs, die zwischen Windows und Linux gut funktionieren scheitern an OS X, weil sie da X als Grafikserver voraussetzen - was bei OS X nur als Unterprogramm realisiert ist, sich nicht mit dem normalen OS X-Look-and-feel integriert und vergleichsweise häßlich aussieht. Keine Ahnung, wie's mit wxW aussieht.
...
Das haette ich zum Beispiel garnicht gewusst Fragt sich nur, was man dagegen tun kann ^^;
Zitat
Ah, stimmt. OGRE gehört natürlich in eine gute Engineliste.
...
Zitat
Denke ich auch, wir gewinnen nichts, wenn wir es closed machen. Aber manche Leute sind ja der Meinung, daß niemand jemals ihren Code sehen darf...
...
Das sind dann aber definitiv nicht die Leute, die wir suchen
Zitat
Wahr. Ich würde vorschlagen, daß wir eine Skriptsprache integrieren und den Usern erlauben, über ein Point-and-Click-Interface wie bei den Makern einfach Code zu erstellen, wobei sie Zugriff auf alle nötigen Grundfunktionen haben. Man könnte den so erstellten Code als Metacode speichern (beispielsweise als XML) und dann vor der Ausführung in den richtigen Code übersetzen. So können die User grundsätzlich im grafischen Interface bleiben (wenn wir gleich zu richtigem Code übersetzen könnte die Rückübersetzung Probleme machen, wenn man per GUI was ändern will) und wir haben intern trotzdem alles in einer Sprache.
...
Solange wir es schaffen, alle Features des Makers in ein Point-and-Click Interface zu bringen, ohne, dass es all zu kompliziert wird, ist das wohl die beste Idee. Allerdings sollten wir sehr genau ueber die Variablen nachdenken. Ich fand es immer extrem nervig, im RM2K alle Variablenoperationen ueber ein extra Dialogfenster zu regeln =_=
Zitat
Lua ist eine Idee; Ruby wäre eine andere. Ich weiß nicht, wie es mit dem C(++)-Binding aussieht, aber Ruby hat natürlich den Vorteil, daß es einfach und mächtig ist.
...
Ich habe mich mit Ruby nie befasst und kann daher dazu nichts sagen. Aber wenn es einfach an C++ anzubinden ist, steht einer Verwendung ja an sich nichts im Wege
Zitat
Auch wahr. 3D würde das Programm sowohl in der Programmierung als auch in der Verwendung wesentlich komplizierter machen.
Allenfalls 2D-Maps mit einer Heightmap und Sprites drauf könnte ich mir gut vorstellen.
...
Da muesste man dann allerdings aufpassen, ob die Tiles nicht verzerrt werden und ganz graesslich aussehen ^^;
Zitat
Wenn wir dann noch die zlib oder LZO mit reinnehmen hätten wir plattformübergreifend komprimiertes XML, das Platz spart (allerdings auch etwas langsamer ist). Für die Maps müßten wir mal sehen, wie wir das machen. Da wäre alles möglich, von einem eigenen Binärformat bis hin zu einem Metaformat wie es von OpenOffice verwendet wird (mehrere Dateien in einem Archiv; so könnten wir binäre Mapdaten (vielleicht als 8-bittige PNGs?) und Skriptdaten zusammen speichern).
...
Ein Metaformat ist sicher eine gute Idee. Allerdings wuerde man bei der Verwendung von 8-bit PNGs fuer die Mapdaten vorraussetzen, dass es nur 1 Tileset mit maximal 255 Tiles gibt. Da muesste man dann ueberlegen, ob das reicht.
*freut sich auf Jack Daniels (mit gekauftem Eis und eventuell Cola) und Password: Swordfish (laeuft heute im japanischen Fernsehen XD)*
--
Bin zur Zeit in Japan und habe deswegen keinen PC zu Hause
Das haette ich zum Beispiel garnicht gewusst :D Fragt sich nur, was man dagegen tun kann ^^;
...
Hmm, offenbar gibt es für Qt und GTK Ports, die auf Cocoa (OS X-Toolkit) aufbauen und sich besser integrieren. Das Problem ist, daß die meisten Leute nicht-native Versionen installiert haben, um Abhängigkeiten zu befriedigen. Man müßte da also entweder die Bibliothek doppelt installieren oder Inkompatibilitäten riskieren oder mit schlechtem Fook-and-Feel leben.
Die mangelnde Einbindung von X zeigt sich vor Allem darin, daß jedes X-Programm seine eigene Menüleiste hat und nicht das OS X-Aussehen übernimmt. Das beißt sich schon arg mit dem Rest des Interfaces.
Zitat
Das sind dann aber definitiv nicht die Leute, die wir suchen ;D
...
Das sind die Leute, die alle bisherigen Makerklone gebastelt haben. :/
Zitat
Solange wir es schaffen, alle Features des Makers in ein Point-and-Click Interface zu bringen, ohne, dass es all zu kompliziert wird, ist das wohl die beste Idee. Allerdings sollten wir sehr genau ueber die Variablen nachdenken. Ich fand es immer extrem nervig, im RM2K alle Variablenoperationen ueber ein extra Dialogfenster zu regeln =_=
...
Das Variablenmanagement der Maker-Serie ist allgemein grottig. Ich denke schon, daß Zuweisungen á la $blubb = $foo + $bar - (4 / $quux) machbar sein sollten.
Die gesamte Funktionalität werden wir wohl nicht in ein PnC-Interface packen können, aber die wichtigsten Sachen schon. Wenn wir eine komplette OOP-fähige Skriptsprache wie Ruby unter dem Kasten haben können wir viel Funktionalität in ihr implementieren, was den Usern die Möglichkeit gibt, Subklassen von unserem Kram anzulegen und damit ihren Spaß zu haben. Der RMXP hat mit RGSS genau das und es gefällt mir... Für Point-and-Click ist es natürlich etwas zu heftig, aber das wird die meisten User wohl auch nicht stören.
Zitat
Ich habe mich mit Ruby nie befasst und kann daher dazu nichts sagen. Aber wenn es einfach an C++ anzubinden ist, steht einer Verwendung ja an sich nichts im Wege ;)
...
Ich hatte Ruby bisher nur als eigenständige Skriptsprache; es gibt ein C++-Binding namens C++Ruby. Außerdem könnte man auf SWIG zurückgreifen.
Ruby ist eine sehr bequeme Sprache mit konsequentem OOP - alles ist ein Objekt. Das erlaubt Konstrukte wie folgendes:
Zitat
Da muesste man dann allerdings aufpassen, ob die Tiles nicht verzerrt werden und ganz graesslich aussehen ^^;
...
Yup. Wie gesagt, das ist das dreidimensionalste,was ich mir vorstellen könnte.
Zitat
Ein Metaformat ist sicher eine gute Idee. Allerdings wuerde man bei der Verwendung von 8-bit PNGs fuer die Mapdaten vorraussetzen, dass es nur 1 Tileset mit maximal 255 Tiles gibt. Da muesste man dann ueberlegen, ob das reicht.
...
Kommt drauf an... Mehrere Ebenen würde ich ohnehin dadurch realisieren, daß im Archiv mehrere PNGs sind - dann könnte man auch jeder PNG ein Tileset zuweisen. Mit 8 Bits ist ein Tileset zwar auf 256 Tiles beschränkt, alles darüber würde aber IMO entweder zu unübersichtlich großen Tilesets führen (65536 Tiles pro Set?), die Mapdateien ineffizient oder die Verwendung von PNG unmöglich machen - und damit würden wir uns ein gutes, verlustfrei komprimiertes Bitmapformat durch die Lappen gehen lassen.
Man könnte natürlich sehen, ob man nicht n Bit zur Speicherung des Tile-Indexes und den Rest zur Speicherung sonstiger Daten nimmt. So könnte man ein 16-bittiges PNG verwenden, in dem 10 Bits für den Tile-Index (1024 Tiles) und 6 Bits für sonstige Informationen wie Passierberkeit stehen.
Zitat
*freut sich auf Jack Daniels (mit gekauftem Eis und eventuell Cola) und Password: Swordfish (laeuft heute im japanischen Fernsehen XD)*
...
Du Sau! Was empfängst du Glückspilz japanisches Fernsehen? Daß du in Japan bist ist keine Entschuldigung! *g*
Zitat von Jesus_666
Fragt sich nur, was man dagegen tun kann ^^;
Zitieren
