Seite 2 von 5 ErsteErste 12345 LetzteLetzte
Ergebnis 16 bis 30 von 66

Thema: [FreeCol] Freeware-Variante von Colonization

  1. #16
    Registrierter Benutzer Avatar von bisonte
    Registriert seit
    01.06.05
    Beiträge
    220
    Zitat Zitat von Takamisakari Beitrag anzeigen
    Freecol ist langsam, schlecht programmiert und schlecht dem Original angepasst.
    Langsam ? Das liegt wohl an deinem Rechner...

    Schlecht Programmiert ?

    Das Ding ist OPEN SOURCE. D.h. da basteln etliche Leute dran... das hier und dort optimiert werden kann ist völlig normal. Aber schlecht programmiert... nicht wirklich. Schau dir doch den Quellcode mal an...

    Schlecht dem Original angepasst ?

    Also in meinen Augen kommt Freecol dichter an das originale Colonization als SidMeiers Neuauflage...

    Und wenn Du schon meinst, solch eine Aussage zu posten, wäre eine Begründung nie verkehrt. Ansonsten betreibst du ja Rufmord...
    Meine Projekte :
    Modmaker "Ghandi"
    ColonizationOne V1.6

    In Vorbereitung : NBMod_Extend

  2. #17
    Kohlkönig Avatar von vadus
    Registriert seit
    24.08.01
    Ort
    Berlin
    Beiträge
    1.554
    tja, ich wollte gar nicht näher drauf eingehen ..
    Der Quellcode ist super ! leicht verständlich und bestens dokumentiert. Sowas sieht man in der Wirtschaft selten !
    ... Earth!

    --- Civ5: Vadus World ---

  3. #18
    Registrierter Benutzer Avatar von bisonte
    Registriert seit
    01.06.05
    Beiträge
    220
    Zitat Zitat von vadus Beitrag anzeigen
    tja, ich wollte gar nicht näher drauf eingehen ..
    Der Quellcode ist super ! leicht verständlich und bestens dokumentiert. Sowas sieht man in der Wirtschaft selten !
    Selten ? NIE Das kostet extra Zeit... und wie sagt mein Chef immer... Zeit ist Geld und das hab ich nicht
    Meine Projekte :
    Modmaker "Ghandi"
    ColonizationOne V1.6

    In Vorbereitung : NBMod_Extend

  4. #19
    Trapper Avatar von hummelbummel
    Registriert seit
    28.09.08
    Beiträge
    29
    ich habe bei der version weder sound noch musik.

  5. #20
    Talking Bull Avatar von Writing Bull
    Registriert seit
    01.10.08
    Beiträge
    21.376
    Zitat Zitat von hummelbummel Beitrag anzeigen
    ich habe bei der version weder sound noch musik.
    bei welcher?

  6. #21
    Registrierter Benutzer Avatar von bisonte
    Registriert seit
    01.06.05
    Beiträge
    220
    sounds waren schon immer da. zumindest Schritte oder sowas.... (musst mal im Ordner Freecol schauen...) musik hingegen nur wenn man dieses .ogg file runterlädt, soweit ich das mitbekommen habe....
    Meine Projekte :
    Modmaker "Ghandi"
    ColonizationOne V1.6

    In Vorbereitung : NBMod_Extend

  7. #22
    Banned Avatar von Takamisakari
    Registriert seit
    14.11.06
    Ort
    Dresden
    Beiträge
    166
    Zitat Zitat von bisonte Beitrag anzeigen
    Langsam ? Das liegt wohl an deinem Rechner...

    Schlecht Programmiert ?

    Das Ding ist OPEN SOURCE. D.h. da basteln etliche Leute dran... das hier und dort optimiert werden kann ist völlig normal. Aber schlecht programmiert... nicht wirklich. Schau dir doch den Quellcode mal an...

    Schlecht dem Original angepasst ?

    Also in meinen Augen kommt Freecol dichter an das originale Colonization als SidMeiers Neuauflage...

    Und wenn Du schon meinst, solch eine Aussage zu posten, wäre eine Begründung nie verkehrt. Ansonsten betreibst du ja Rufmord...
    Naja, liegt wohl eher an dem scheiß Java was die Open Sourcer immer benutzen.
    Mal davon abgesehen, dass FreeCol völlig überflüssig und hässlich ist.Das Original und das Remake sind tausendmal besser. Kein Wunder dass das Remake besser ist, die haben immerhin Einblick in das Original.

  8. #23
    Registrierter Benutzer Avatar von SirRethcir
    Registriert seit
    18.11.05
    Beiträge
    460
    Zitat Zitat von Takamisakari Beitrag anzeigen
    Naja, liegt wohl eher an dem scheiß Java was die Open Sourcer immer benutzen.
    Erzähl mir mehr!
    Und die vielen Bugs in den Spielen liegen wohl eher an dem Scheiß C++ was die kommerziellen Programmierer benutzen.

  9. #24
    Registrierter Benutzer Avatar von bisonte
    Registriert seit
    01.06.05
    Beiträge
    220
    Zitat Zitat von Takamisakari Beitrag anzeigen
    Naja, liegt wohl eher an dem scheiß Java was die Open Sourcer immer benutzen.
    Mal davon abgesehen, dass FreeCol völlig überflüssig und hässlich ist.Das Original und das Remake sind tausendmal besser. Kein Wunder dass das Remake besser ist, die haben immerhin Einblick in das Original.
    Schon wieder ... Warum ist Java sch... ?
    Überflüssig ? Wieso hat es denn so eine grosse Fangemeinde ?
    Einblick ins Original ? Wäre mir neu, dass Spielehersteller ihre Quellcodes offenlegen, selbst wenn das Game noch so alt ist...
    Meine Projekte :
    Modmaker "Ghandi"
    ColonizationOne V1.6

    In Vorbereitung : NBMod_Extend

  10. #25
    Registrierter Benutzer
    Registriert seit
    29.01.03
    Beiträge
    4.909
    Nun, ich persönlich bin gegen Java, weil ich bis heute noch nie ein gut funktionierendes Javaprogramm gesehen habe. Zwar hat Java im Bereich des Look und Feel gewisse Fortschritte gemacht, aber man erkennt ein Javaprogramm dennoch sehr schnell an gewissen Unzulänglichkeiten.

    Das währen zum Beispiel die bei besonders hektischen Benutzeraktionen auftretende fehlerhafte Fensteraktualisierung. In vielen Editoren, welche auf Java basieren bleiben so Fragmente von Menüs oder ehemaligen Texten im Eingabebereich erhalten, bis genau diese Zeile durch z.B. scrollen aktualisiert wurde. Dann gibt es bei Javaprogrammen auch oft Probleme mit Tastenkombinationen die ansonsten nativ von Windows unterstützt werden, aber irgendwie nicht immer vom Java-Basierten Programmen. Darüber hinaus sind viele Javaprogramme eben etwas "träge" bzw. "zähflüssig" was die Bedienung angeht. Ich bin da sehr empfindlich, was diesen Punkt angeht. Wenn ich nicht das Gefühl habe, dass eine Aktion zeitnah mit meinem "Klick" durchgeführt wird, bekomme ich irgendwie ein schlechtes Gefühl bei der Bedienung. Im Übrigen hat die Phyton-Oberfläche von Civ4/Col2 genau das gleiche Problem, allerdings bei fortgeschrittenen Spielen noch viel stärker als bei gängigen Javaprogrammen.

    Das Problem von Java ist einfach das Interpreterkonzept. Programme, die interpretiert werden können prinzipiell nicht so schnell laufen wie nativ-compilierte Programme. Der große Vorteil von Java liegt in einer kürzeren Entwicklungszeit für den Programmierer als Beispielweise bei C++, und dass plattformunabhängiges Programmieren mit Java besonders einfach wird. Den Nachteil, des mangelnden Look and Feel von Javaprogrammen muss halt der kritische User ausbaden und daher verzichte ich, soweit es mir möglich ist, auf den Gebrauch von Javaprogrammen.

    Wie gesagt, ich möchte hier auf keinen Fall die Leistung von den Programmierern von FreeCol herunterreden. Ein Programm in Java zu entwickeln ist genauso anspruchsvoll wie in C/C++. Java entwickelt sich allerdings zunehmen (besonders im Bereich der Wirtschaftsinformatik) zu DER Programmiersprache schlechthin, was ich als Benutzer aus den oben genannten Gründen sehr kritisch sehe. Leider ist MS ebenfalls mit .net auf diese Schiene aufgesprungen und der Marktanteil von Programmen die interpretiert anstatt compiliert werden, wird leider Gottes weiter steigen.

  11. #26
    Registrierter Benutzer Avatar von SirRethcir
    Registriert seit
    18.11.05
    Beiträge
    460
    Zitat Zitat von Netbandit Beitrag anzeigen
    Das währen zum Beispiel die bei besonders hektischen Benutzeraktionen auftretende fehlerhafte Fensteraktualisierung. In vielen Editoren, welche auf Java basieren bleiben so Fragmente von Menüs oder ehemaligen Texten im Eingabebereich erhalten, bis genau diese Zeile durch z.B. scrollen aktualisiert wurde.
    Würde mich mal interessieren, wo du das gesehen hast.
    Allgemein gesagt ist dies ein Problem der GUI-Komponente und hat ja per se erstmal nichts mit der Programmiersprache zu tun. Möglicherweise tritt dieses Verhalten auch nur unter Microsoft-BS auf, dann wissen wir ja wer dran Schuld ist.

    Zitat Zitat von Netbandit Beitrag anzeigen
    Dann gibt es bei Javaprogrammen auch oft Probleme mit Tastenkombinationen die ansonsten nativ von Windows unterstützt werden, aber irgendwie nicht immer vom Java-Basierten Programmen.
    Ist eben kein Microsoft. Ansonsten den GUI-Komponenten Programmierer ansprechen.

    Zitat Zitat von Netbandit Beitrag anzeigen
    Das Problem von Java ist einfach das Interpreterkonzept. Programme, die interpretiert werden können prinzipiell nicht so schnell laufen wie nativ-compilierte Programme.
    Hm, mag sein, aber nur solange der Prozessor den Bytecode nicht nativ unterstützt.

    Zitat Zitat von Netbandit Beitrag anzeigen
    Der große Vorteil von Java liegt in einer kürzeren Entwicklungszeit für den Programmierer als Beispielweise bei C++, und dass plattformunabhängiges Programmieren mit Java besonders einfach wird.
    Warum die Entwicklungszeit kürzer sein soll weiß ich nicht. Der Vorteil ist die Plattformunabhängigkeit und die strikte Konzentration auf die Objektorientierte Prgrammierung.

    Zitat Zitat von Netbandit Beitrag anzeigen
    Den Nachteil, des mangelnden Look and Feel von Javaprogrammen muss halt der kritische User ausbaden und daher verzichte ich, soweit es mir möglich ist, auf den Gebrauch von Javaprogrammen.
    Hier gebrauchst du Look&Feel in einem anderen Zusammenhang als angedacht. Look&Feel beschreibt die Art und Weise wie sich eine Benutzeroberfläche verhält. Z.B. das Look&Feel von Microsoft XP, von Linux (hier gibt's ja zahlreiche GUI-Versionen) oder von MAC-Computern.

    Zitat Zitat von Netbandit Beitrag anzeigen
    Java entwickelt sich allerdings zunehmen (besonders im Bereich der Wirtschaftsinformatik) zu DER Programmiersprache schlechthin, was ich als Benutzer aus den oben genannten Gründen sehr kritisch sehe. Leider ist MS ebenfalls mit .net auf diese Schiene aufgesprungen und der Marktanteil von Programmen die interpretiert anstatt compiliert werden, wird leider Gottes weiter steigen.
    Zum Glück, sag ich da nur. So kann eine Firma viel leichter die Hardware erneuern. Es gibt ja viele Beispiele bei Firmen, wo noch Uralt-Rechner laufen, nur weil die alte Software auf anderen (neueren) Rechnern nicht läuft und eine Neuentwicklung der Software wäre sehr teuer.

  12. #27
    Kohlkönig Avatar von vadus
    Registriert seit
    24.08.01
    Ort
    Berlin
    Beiträge
    1.554
    Das Problem ist nicht die Programmiersprache sondern die Programmierung. Bei der Programmierung von Java Programmen wird in der Regel nicht viel auf Performance geachtet, weil es nicht der wichtigste Punkt in den Anforderungen ist. Trotzdem kann ich mit Java Desktopanwendungen schreiben, die C++ Programmen in Sachen Bedienbarkeit, zu der auch eine, für den User nicht unangenehm lang andauernde, Reaktionszeit zählt, in nichts nachstehen. Bestes Beispiel ist hier die Eclipse IDE. Ich finde bei der Bedienung keine Unterschiede zwischen Eclipse und Visual Studio.
    ... Earth!

    --- Civ5: Vadus World ---

  13. #28
    Registrierter Benutzer Avatar von SirRethcir
    Registriert seit
    18.11.05
    Beiträge
    460
    Zitat Zitat von vadus Beitrag anzeigen
    Trotzdem kann ich mit Java Desktopanwendungen schreiben, die C++ Programmen in Sachen Bedienbarkeit, zu der auch eine, für den User nicht unangenehm lang andauernde, Reaktionszeit zählt, in nichts nachstehen.
    Empfehlenswert unteranderem: Effective Java

  14. #29
    Registrierter Benutzer
    Registriert seit
    29.01.03
    Beiträge
    4.909
    Zitat Zitat von SirRethcir Beitrag anzeigen
    Würde mich mal interessieren, wo du das gesehen hast.
    Allgemein gesagt ist dies ein Problem der GUI-Komponente und hat ja per se erstmal nichts mit der Programmiersprache zu tun. Möglicherweise tritt dieses Verhalten auch nur unter Microsoft-BS auf, dann wissen wir ja wer dran Schuld ist.
    2006 habe ich das letzte mal bewusst und Java-Programm runtergeladen. Es war ein XML Editor, um für Civ4 was zu modifizieren. Hier waren die Probleme schon sehr krass. Leider ist es schon so lange her und ne Software die nur wenige Tage auf den Rechner war muss ich mir auch nicht merken
    Ähnliche Probleme hatte ich am Ende des selben Jahres mit Eclipse unter KDE 3. Ich suchte ne IDE für Perl und war sehr froh, dass Eclipse einen entsprechenden Port bot. Ich war ganz heiß auf diese IDE, da ich zuvor im Internet viel darüber gelesen hatte. Ich gebe zu, der Rechner war nicht besonders schnell aber die Zähflüssigkeit und Anzeigefehler von Eclipse waren ne Katastrophe. Die Software hat ca. eine Stunde auf meinem Rechner überlebt danach bin ich zum KDeveloper übergegangen, der zwar noch etwas unausgereift war, aber wenigstens konnte ich damit angenehm und flüssig arbeiten.

    Wie gesagt, wenn ein Programm träge reagiert, dann macht mich das auf dauer verrückt. Wenn es sich dabei noch um Arbeitsprogramme handeln, dann ist nicht mehr an ein vernünftiges Arbeiten zu denken.

    Zitat Zitat von SirRethcir Beitrag anzeigen
    Ist eben kein Microsoft. Ansonsten den GUI-Komponenten Programmierer ansprechen.
    Nun, ich als Anwender von Programmen interessiere mich reichlich wenig dafür, warum ein Programm nicht so funktioniert wie ich es erwarte. Wenn ein Programm meinen Erwartungen absolut nicht Gerecht werden kann fliegt es wieder von der Platte, egal wer daran Schuld ist. Überproportional sind in den letzten 10 Jahren bei mir Java-Programme von der Platte geflogen. Ich kann mir sehr gut vorstellen, dass es Anwender gibt, die da etwas toleranter sind als ich, die kein dumpfes Gefühl in der Magengegend bekommen, wenn ein Programm auf eine Benutzereingabe leicht verzögert reagiert oder hier und da der Bildschirmaufbau nicht korrekt aktualisiert wird. Vielleicht merken es diese Anwender nicht einmal... naja es gibt ja offensichtlich auch Programmierer die davon überzeugt sind, dass man mit dem vi effektiver Programmieren kann als mit einer ausgeklügelten IDE.

    Zitat Zitat von SirRethcir Beitrag anzeigen
    Hm, mag sein, aber nur solange der Prozessor den Bytecode nicht nativ unterstützt.
    Ursprüngliche Java-Programme kommen ja gar nicht auf diese Ebene. Die Javabefehle werden vorkompiliert also in eine Art Java-Maschinensprache übersetzt und dann interpretiert. Die Entscheidung ob und wie ein Java-Befehl an den Prozessor weiter gegeben werden muss, wird in jedem Fall vom Java-Interpreter getroffen und nicht vom Java-Programm selbst. Dies kostet Zeit, gegenüber einem Programm, welches direkt in Opcode für den entsprechenden Prozessor umgesetzt wird und wo nicht bei jedem Befehl oder jeder Befehlsgruppe ein anderes Programm (der Interpreter) den passenden Opcode erst bereitstellen muss.
    Dieser Umstand wurde ja auch von Sun selbst bemerkt und daher gibt es ja heute sogar Möglichkeiten Javaprogramme teilweise zu kompilieren um eben die Geschwindigkeit zu erhöhen. Doch damit geht dann auch der einzige große Vorteil von Java verloren: Die absolute Plattformunabhängigkeit.
    Aber auch mit diesem Konzept ist Java schlichtweg langsamer, weil es mehr Overhead produziert. Durch den Verzicht auf Zeiger kann man nicht direkt auf komplexe Speicherbereiche zugreifen. Der Zugriff Felder zum Beispiel findet in Java nur indirekt statt, was den Vorteil hat, dass man auch gleich eine Bereichsüberschreitung abfangen kann. Leider wird der dadurch entstehende Code nicht kürzer und benötigt mehr Zeit um ausgeführt zu werden.
    Es ist eben wie überall: Einen Tod muss mann sterben.

    Zitat Zitat von SirRethcir Beitrag anzeigen
    Warum die Entwicklungszeit kürzer sein soll weiß ich nicht. Der Vorteil ist die Plattformunabhängigkeit und die strikte Konzentration auf die Objektorientierte Prgrammierung.
    Du sagst es doch selbst: Die Konzentration auf totales OOP bewirkt durchaus eine Beschleunigung im Entwicklungsprozess. Teamarbeit und dezentrale Programmierung werden somit optimal gefördert. Bei C++ muss man sich ständig zusammen reißen alles strikt OO zu machen, da es ja auch die Möglichkeit der prozeduralen Programmierung gibt. Die entscheidenden Faktoren sind jedoch die Hardwareunabhängigkeit, die viel Entwicklungszeit einsparen kann und die Tatsache, dass völlig auf Zeiger verzichtet wurde, was die Entwicklung weniger Fehleranfällig macht.
    Ich würde mal behaupten, dass ein Großteil der Fehler bei C und C++ Programmen auf Zeiger zurückzuführen sind, welche im Wald stehen.

    Zitat Zitat von SirRethcir Beitrag anzeigen
    Hier gebrauchst du Look&Feel in einem anderen Zusammenhang als angedacht. Look&Feel beschreibt die Art und Weise wie sich eine Benutzeroberfläche verhält. Z.B. das Look&Feel von Microsoft XP, von Linux (hier gibt's ja zahlreiche GUI-Versionen) oder von MAC-Computern.
    Eben und genau das meine ich: Wenn sich ein Programm nicht ideal in das mir bekannte Look&Feel meines BS einfügt, also bestimmte Tastenkombinationen nicht funktionieren (die ansonsten betriebssystemweit unterstützt werden) oder eben die Anzeige nicht ganz zum Rest passt. Hier mal ein Beispiel:


    Diese GUI sieht nun einmal anders aus, als ich es von 99% meiner Software gewohnt bin. Das mag vielen vielleicht egal sein, ich störe mich an solchen Dingen. Es hindert mich am effektiven Arbeiten wenn sich Dinge nicht so verhalten wie erwartet oder anders aussehen als ich es gewohnt bin.

    Zitat Zitat von SirRethcir Beitrag anzeigen
    Zum Glück, sag ich da nur. So kann eine Firma viel leichter die Hardware erneuern. Es gibt ja viele Beispiele bei Firmen, wo noch Uralt-Rechner laufen, nur weil die alte Software auf anderen (neueren) Rechnern nicht läuft und eine Neuentwicklung der Software wäre sehr teuer.
    Es ist ein häufiger Fehler, dass man glaubt, dass Java die einzige Möglichkeit sei Plattformunabhängig zu programmieren. Es gibt Fällt, wo Java in der Tat große Vorteile hat und zwar dort wo der Entwickler definitiv nicht weiß auf welchen Systemen seine Software läuft. Also im Bereich von Internet-Applets oder bei Handyprogrammen. Bei PC Software ist das in der Regel anders. Hier weiß man auf welchen Systemen sein Programm zur Anwendung kommt z.B. auf Windows und Linux oder auf einem Mac. Es ist durchaus Möglich, mit C++ Programme plattformaunabhängig zu programmieren. Sie müssen nur noch für die entsprechende Plattform kompiliert werden. Was aber bei 3 möglichen Plattformen keine Hürde darstellt. Projekte wie Code::Blocks, OpenTTD, FreeCiv und viele mehr beweisen es.
    Der Unterschied ist halt: Es ist aufwendiger und verlangt mehr Disziplin ein C++ Programm zu erstellen, welches auf jeder der drei Plattformen ohne Anpassungen kompeliert werden kann. Der Gewinner ist aber in jedem Fall der User der nun eine sehr schnelle und schlanke Software besitzt. In Zeiten von Klimawandel und teurer Energie, sollte man es sich durchaus überlegen, ob man Rechenzeit und damit Energie für an sich überflüssige Programme wie einen Java-Interpreter ausgeben möchte.

    Ich gebe zu, Java ist halt eine Modesprache und wer heute in der Branche zu tun hat, kommt leider nicht mehr drum herum.

    Edit: Ich möchte hier im übrigen eigentlich keinen Krieg der Programmier/Scriptsprachen anführen. Ich denke, dass jede Sprache da ihre ganz eigenen Vorzüge hat und daher auch ihren eigenen Anwendungsbereich. Java sehe ich zum Beispiel ungeschlagen bei den Internetapplets, PHP und perl sind dafür die besten wenn es um dynamische Webseiten geht und bei großen Projekten, wo es auch auf Performance ankommt sehe ich persönlich C++ weit vorne. Es ist eben wichtig, dass man vor einem Projekt die Vor- und Nachteile richtig abwägt und dann konsequent mit der Sprache programmiert für die man sich entschieden hat. Diese Entscheidung ist meiner Meinung nach bei Col2 und Civ4 bezüglich dem Phytonscript Oberflächen eindeutig falsch ausgefallen und wir Spieler müssen nun darunter "leiden". Bei FreeCol ist diese Entscheidung ja auch irgendwann einmal getroffen worden und damals hat man sich vor Java entschieden. Was dazu geführt hat, ja keine Ahnung, aber nun ist es nun einmal so. Ob es die falsche Entscheidung war wird sich spätestens dann herausstellen, wenn in fortgeschrittenen Spielen mit viel Ki und Automatisierung auf der Karte auch viele Berechnungen gemacht werden müssen. Davon ist FreeCol ja im Moment noch ein Stück entfernt und die Zeit wird zeigen wer hier recht behält.

    Meine Sorge ist jedoch, dass in Zukunft weniger über solche Entscheidungen nachgedacht wird. Sprachen wie Java und C# haben nun einmal eine sehr geringe Einstiegsschwelle im Gegensatz zu C++ oder gar C. Viele Hobbyprogrammierer lernen halt nur noch diese Sprachen und sogar an Hochschulen gibt es Studiengänge wo nur noch solche Sprachen gelehrt werden. Dies wird in Zukunft immer mehr dazu führen, dass eine Entscheidung über die zu verwendende Programmiersprache nicht mehr danach gefällt wird, ob die Programmiersprache besonders gut zu den Anforderungen passt sondern eher ob das zur Verfügung stehende Personal damit schon Programmiererfahrungen hat.
    Geändert von Netbandit (15. November 2008 um 10:36 Uhr)

  15. #30
    Registrierter Benutzer Avatar von SirRethcir
    Registriert seit
    18.11.05
    Beiträge
    460
    Zitat Zitat von Netbandit Beitrag anzeigen
    Edit: Ich möchte hier im übrigen eigentlich keinen Krieg der Programmier/Scriptsprachen anführen.
    Ja und deswegen hören wir jetzt auch damit auf.

Seite 2 von 5 ErsteErste 12345 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •