Hi,

ich komme gleich mit einer Reihe von Fragen. Zuerst aber ein paar persönliche Anmerkungen, die möglicherweise das Antworten erleichtern.

Ich habe mehrere Jahre mit Delphi programmiert (auch größere Sachen), aber das ist schon eine Weile her. Dann wechselte ich zu Linux und werkelte eine Zeitlang mit Kylix herum. Der große Hit war's nicht, das Wine-basierte Kylix war träge und hatte einige Tücken. Als Borland dann Kylix aufgab, war es nur konsequent, von Pascal auf C bzw. C++ umzusteigen. Dabei begann ich auch meine ersten Schritte mit OpenGL, doch mit der heute obligatorischen Shader-Programmierung hatte das noch nichts zu tun. Ich interessierte mich nicht so sehr für die Feinheiten von OpenGL, sondern eher für die physikalischen Simulationsvorgänge.

Inzwischen gibt es so einige Projekte, die ich mit OpenGL realisieren möchte. Damit das Ganze nicht ausartet, habe ich mich monatelang um eine Reihe von Libraries gekümmert, die es unter C++ in Hülle und Fülle gibt. Doch in Wirklichkeit ist das gar nicht so günstig, wie es auf den ersten Blick aussieht. Das meiste ist viel zu speziell und für meine Zwecke untauglich. Unabdingaber für mich ist, dass alles unter Windows und Linux laufen muss, und da wird's schon enger. Ohne jetzt in Einzelheiten zu gehen: Ich musste feststellen, dass es oft viele Stunden Arbeit bedeutete, eine Library auf der jeweils anderen Plattform zum Laufen zu bringen - wenn's überhaupt klappte. So ganz üppig wie es scheint, ist die Situation in C++ also keineswegs.

Es kommt noch etwas hinzu, was mich immer mehr abstößt: Viele C++-Programmierer sind absolute Fundamentalisten, wenn es um den Programmierstil geht. Was da an unübersichtlichen Namespace-Hierarchien aufgebaut wird, ist sagenhaft. Oder wahre Template-Orgien, um ein anderes Beispiel zu bringen. Gerade die großen Libraries wie Irrlicht oder ganz besonders OGRE sind Brutstätten für Programmierstile, die eher zelebriert werden, als dass sie sich um Effektivität, Verständlichkeit und Anpassungsfähigkeit bemühen. Und dann noch das Selbstverständnis der Autoren. Fast jeder meint, sein Exponat sei das Zentrum des Programms und alles andere habe sich entsprechend anzupassen. Die Konflikte, die sich daraus ergeben, sind teilweise grotesk.

Nun ja, und da fällt mir wieder Delphi ein, mit dem ich seinerzeit rundum zufrieden war. Warum eigentlich nicht? Zumal nun ja Lazarus enorme Fortschritte gemacht zu haben scheint. Vor Jahren hatte ich's unter Linux mal installiert, aber da war Lazarus noch unvollständig, und es hakte vorne und hinten. Um ehrlich zu sein, ich hatte Lazarus damals noch nicht ernst genommen, irgendwie so ein läppischer Versuch von Enthusiasten, denen spätestens nach 3 Jahren die Luft ausgeht. Das war wohl ein Fehleinschätzung. Die Ausstattung und nicht zuletzt die Dokumentation sind inzwischen beeindruckend. Ob Lazarus robust genug für ein großes Programmprojekt ist, kann ich allerdings noch nicht sagen.

Und da setzen meine Fragen an:

1. Kann man guten Gewissens mit Lazarus ein größeres Projekt starten?

2. Wie erfolgt die Einbindung von OpenGL
a) unter Windows,
b) unter Linux?

3. Ist es vielleicht ratsam, das Projekt zunächst mit Delphi zu entwickeln (ich habe noch eine
Enterprise-Version von Delphi 7) und Lazarus nur zur Portierung auf Linux zu verwenden? Wenn ja,
gibt es da besondere Tücken?

4. Wie sieht es hier mit zusätzlichen Libraries aus, wobei vor allem eine Physik-Engine sehr wichtig ist? Aber
auch Sound, Truetype-Font-Unterstützung, Joystick-Ansteuerung usw. sind gefragt. Und nicht zuletzt die
Einbindung von animierten Charakteren, die z.B. mit Blender gebaut und geriggt werden.

Gruß
Erin

Kleiner Tipp am Rande: Wer Lazarus unter aktuellen Ubuntu-Versionen installiert, bekommt beim Schließen des Programms wahrscheinlich eine Fehlermeldung, und der Debugger muss von Hand beendet werden, eine lästige Sache. Grund sind die neuen Scrollbars in der Unity-Oberfläche. Da diese Scrolldinger ohnehin nichts taugen, sollte man zu den alten zurückkehren, was einfach durch Deinstallation der Pakete rund um "overlay-scrollbars" geht.

Einer der Gründe warum ich mit Pascal arbeite (edit: bevor ich geflamt werde: C++ ist auch ganz toll.. )

Ich selbst arbeite parallel mit Delphi 7 Enterprise, Lazarus und tlw. auch mit Delphi XE2, was dank SDL und der dglopengl.pas super klappt

Lazarus lässt sich vom Funktionsumfang am ehesten mit der Personal Version von Delphi 7 vergleichen, es fehlen einige der Komponenten von Delphi 7 Prof/Enterprise, ich persönlich hab die aber nie gebraucht

Wenn du mit OpenGL arbeiten willst, nimm SDL und OpenGL - plattformunabhängig, der Code sollte auf Windows/Linux ohne große Änderungen laufen

=>

OpenGL:
- Grafiktreiber
- dglOpenGL.pas: http://wiki.delphigl.com/index.php/DGLOpenGL.pas

SDL:
- libs: http://www.libsdl.org/download-1.2.php
- header: viewtopic.php?f=13&t=10752
(okay,okay das ist Werbung für mich... )



Physik - nimm die Newton-Delphi-Header von Sascha Willems http://www.saschawillems.de/?page_id=75
Sound - OpenAL müsste gehen, was ich nie ausprobiert habe wäre Audorra
TrueType-Font - TextSuite von Lossy http://www.dev-center.de/projects/textsuite
Joystick-Ansteuerung - geht mit SDL zm. einfach über das Event-System
Blender - du müsstest dich da nach Headern für das 3D-Format, das du nutzen willst, umschauen.

Für Fragen steht dir unser Forum natürlich offen

P.S.

Ich habe das Problem auf Ubuntu 12.10 VM nicht...

Aber da ist Ubuntu auch iwie etwas eigen, auf dem Notebook selbst krieg ich es nicht zum laufen...

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Ja, mit der Einschränkung das man für DLLs teilweise auch Header selber schreiben muss.


Ohne VCL sollte es keine Probleme geben, aber Delphi 7 ist uralt und Lazarus ist besser geworden. Daher schau dir direkt Lazarus an und arbeite damit.


Wenn es C-DLLs sind, musst du mit Pech eigene Header schreiben (s.o.), ansonsten hängt es davon ab, was du verwendest. Ist in C++ aber genauso.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Ich gebe auch mal ein Statement, ich denke dafür bin ich als langjähriger Lazarus-Nutzer und nun auf C++11 umgestiegener qualifiziert.

Also… Zu Lazarus. Der große Vorteil ist erstmal, dass du eine Sprache mit Objektorientierung hast. (Vorsicht, Hyperbel! Wer keine übertriebenen Statements verkraftet, überspringe die nächsten beiden Sätze) C++11 hat zwar sowas ähnliches, aber es fehlen doch einige elementare Features, deren weglassen in mindestens einem Fall sogar zu erheblicher Instabilität führen kann. So sind Klassen keine Frist-Class-Objekte, man kann also im Gegensatz zu FreePascal keine Pointer auf Klassen (nicht Objekte!) übergeben, weiterhin kann man keine virtuellen Methoden aus konstruktoren Aufrufen; man sollte nichtmal Pointer auf diese in einem Konstruktor holen, sonst raucht einem das ab⁽¹⁾. (Ende Hyperbel) Du hast außerdem eine riesige Standardbibliothek, die erstmal für die grundlegende Anwendungsentwicklung alles abdeckt was man so brauchen könnte. Mir persönlich gefallen die Streams von FP immer noch besser als die von C++, aber sowas ist ja schnell nachgebaut. Dann hast du natürlich eine sehr gut integrierte Entwicklungsumgebung, die viel von ihrer Sprache versteht. Du hast also die üblichen Refactor-Möglichkeiten zur Hand, was das Entwickeln erleichtert. Der Debugger ist inzwischen unter Linux in Pfaden ohne Leerzeichen (gerüchteweise gibts da noch Probleme, habe ich aber nicht nachvollziehen können) auch sehr gut verwendbar und gibt dir einen haufen Informationen.

Der Nachteil ist natürlich, dass es nicht viele native Pascal-Bibliotheken gibt. Viel wird aber von der Umfangreichen Standardbibliothek ausgeglichen, die schon viel länger als C++ Threads und ähnliches nativ unterstützt. Wenn du also auf externe Libraries z.B. für Bild- und Audioformate zurückgreifen willst, kann es recht schnell eng werden und du musst einen C-Header portieren. Dann wirds auch mit der Cross-Compatibility wieder lustig, insbesondere sobald 32/64-bit im Spiel ist. Da muss man dann mit den Datentypen sehr genau aufpassen, damit einem das nicht um die Ohren fliegt.

C++11 ist vorallem vielseitig und meiner Meinung nach kein Vergleich mit dem vorherigen C++03 Standard. Die GNU Compiler (4.7+) unterstützen C++11 auch schon hinreichend, um damit viel Spaß zu haben. Templates muss man sich mal anschauen, dann wird man sie Schätzen lernen. Die Macht die einem dieses Metaprogramming in die Hand gibt, ist nicht zu unterschätzen, man kann sehr schnell sehr komplexen Code in sehr wenigen Zeilen ausdrücken durch nette Features wie SFINAE und Variadic Templates. Aber man sollte die Komplexität nicht unterschätzen; es braucht natürlich Einarbeitungszeit. Objektorientierung hat man natürlich auch, wenn auch eher im Java-Flavour und weniger im SmallTalk-Flavour. Was Libraries angeht wird man bei C natürlich sehr schnell fündig, und da die C-Header in den meisten fällen mit C++-Compilern funktionieren, braucht man sich da dann auch keine gedanken zu machen. Mit C++11 hat man ein ziemlich mächtiges Werkzeug zur Hand und inzwischen ist das meine bevorzugte in Maschinencode kompilierte Sprache. Vorallem die Boost-Bibliothek sollte man sich übrigens anschauen. Diese sollte sowohl auf Windows als auch auf Linux problemlos kompilieren.

Das größere Problem ist das Portieren auf eine andere Plattform, da man hier, wenn man nicht auf Cygwin bzw. Mingw setzt, keinen einheitlichen Compiler hat. Mit Mingw/Cygwin soll man zwar einiges erreichen können, ausprobiert habe ich das aber noch nicht. C++ Compiler sind außerdem dafür bekannt, dass sie recht gut optimieren können.

grüße & viel spaß!

⁽¹⁾: Dazu eine kurze Geschichte für den interessierten. Ich debuggte neulich ein lustiges Problem, wo ich einen Thread im Konstruktor erzeugte, welcher in seiner loop mehrere virtuelle Methoden aufrief. Dummerweise hat C++ ja diese unschöne angewohnheit, die virtual method table bzw. die Pointer auf die vtable stück für stück zur fertigen Klasse aufzubauen. Wenn der Thread also früher als erwartet arbeit bekam, rief er vollkommen unklarerweise nicht die Überschriebene, sondern die Methode der Basisklasse auf. Helgrind stieß mich dann auf ein Data Race an der stelle des Vtable-Pointers. Darauf soll man erstmal kommen!

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Erst mal danke für die Hinweise. Über Lazarus wurde nur Positives gesagt, also werde ich's damit versuchen.

Was den Vergleich C/C++ mit Pascal betrifft: Beide sind leistungsstark, beide haben ihre Stärken und Schwächen. Ich habe mich lange genug in beiden Lagern herumgetrieben, so dass ich ganz gut vergleichen kann. Wer meint, die eine oder andere Sprache sei besser, zeigt damit eigentlich nur, dass der Tellerrand für ihn zu hoch ist.

Es stimmt, dass die Library-Situation in C/C++ deutlich üppiger ist. Die Gründe, die ich nicht weiter ausführen will, liegen auf der Hand. Doch zwischen Verhandensein und Verfügbarkeit klafft eine deutliche Lücke, und das hat nichts mit der Sprache an sich zu tun, sondern mit der Art und Weise, wie Autoren von Libraries damit umgehen. Der Autor von Lib A hat sein Werk natürlich (!) in konsequentem C++ Stil programmiert, alles und jedes ist in Klassen definiert. Wer A benutzen will, muss den Weg über abgeleitete Klassen gehen und sich erst mal in dem Dschungel der virtuellen Klassen orientieren. Mit demselben Anspruch tritt Lib B auf, und damit die beiden zusammenpassen, bringt B - eher lustlos, da gezwungenermaßen - einen sogenannten "Wrapper" heraus. Wenn A nun eine neue Version herausbringt, funktioniert der Wrapper von B auf einmal nicht mehr. Ich habe noch keinen funktionierenden Wrapper angetroffen, obwohl die sich beharrlich in den Dokumentationen halten. Interessant ist, dass Libraries, die in reinem C geschrieben sind (z.B. SDL), diesbezüglich überhaupt keine Probleme machen.

Ein anderes, ganz triviales Beispiel: Fast jede Lib benutzt in irgendeiner Form Vektoren. Und da die konsequente Einrichtung von Klassen eine heilige OOP-Kuh ist, kommt jede Lib mit eigenen Vektorklassen daher. Der einzige konkrete Vorteil, Vektoren als Klassen und nicht als simple Structs anzulegen, besteht in der Überladung von Operatoren. Ein Vorteil, der teuer erkauft wird, denn die Flexibilität von C++ bringt es mit sich, dass die Vektorklassen meistens nicht kompatibel sind. Den Kuddelmuddel bei der Parameterübergabe kann man sich leicht vorstellen. Lösungen gibt's natürlich für alles, aber der Code wird aufgedunsen und unübersichtlich - und damit fehleranfällig.

Kurz und gut: Nachdem ich mich mehr als ein Jahr lang mit derartigen Problemen herumgeschlagen habe und dabei das eigentliche Programmprojekt noch nicht mal begonnen habe, fragte ich mich, ob ich mir das noch antun soll. Schließlich programmiere ich nur zu meinem Vergnügen. Wie gesagt, ich erinnerte mich an meine Delphi-Zeit, als alles wesentlich freudvoller und erfolgreicher verlief. Kann sein, dass ich mit Lazarus ebenfalls auf der Strecke bleiben werde, aber ein Versuch ist's allemal wert.

Ach so, gleich noch eine Frage: Sind die Delphi-OpenGL-Header auch unter Lazarus verwendbar, oder bringt Lazarus eine eigene Open-Unterstützung mit?

Gruß
erin

Lazarus bringt, genau wie Delphi, auch einen OpenGL Header mit, dieser ist jedoch veraltet. Die dglOpenGl.pas ist auch unter Lazarus verwendbar(ohne irgendwelche Änderungen) und wird immer geupdated.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Selbst wenn es hier nebensächlich ist, sei erwähnt dass zwischen Structs und Klassen in C++ nur ein einziger Unterschied besteht: Nämlich ob Member per Default public (structs) oder private (classes) sind. Ansonsten werden sie exakt gleich behandelt.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ist das richtig, dass die letzte Version von 2008 ist? Hat sich seitdem nichts mehr getan, oder habe ich einfach den falschen Link erwischt?



Wirklich? Im Ernst, bist du sicher, dass du von C/C++ sprichst? Aber lassen wir's, es ist hier tatsächlich nebensächlich. Ich hatte es auch nur als Begründung für meinen Schwenk zurück nach Pascal erwähnt.

Ich bin mir sicher, dass ich von C++ rede, was eine vollständig andere Sprache ist als C, die nur ein Subset hat, welches mit C kompatibel ist. Das vergessen viele gerne, obwohl das ein sehr wichtiger Punkt ist. Hier der vollständigkeit halber noch eine Quelle für die struct/class-Sache. Wer's im Standard nachlesen möchte, einen der letzten Working Drafts gibts hier auf github.

Die aktuelle Version der dglOpenGL.pas-Unit solltest du hier im Wiki finden, und die wird auch aktiv gepflegt.

grüße

ps.: Die Unterscheidung, du eventuell treffen wolltest, ist die zwischen Plain-Old-Data-Classes und allen anderen. Plain-Old-Data wird häufig mit den C-Structs identifiziert: Man hat keine virtuellen Methoden und auch sonst ein „triviales“ Layout. Genau nachlesen kann man das auf cppreference.com. Als weitere Stufe auf dem Weg zu den Klassen, die das Potential vollständig ausschöpfen gibts noch die Klassifizierung Standard Layout, darüber ists dann eine Klasse, die die gesamte mögliche Komplexität erreicht hat.

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Nur um zu bekräftigen, dass man mit Lazarus auch größere Projekte schreiben kann:

Ich entwickle mit Lazarus seit ungefähr 3 Jahren ernsthaft eine Grafik-Engine. Sie besteht aus einer Library von derzeit rund 1.4MB, das sind 42 Units (durchschnittlich zwischen 1000 und 2000 Zeilen, es gibt aber auch einige größere Brocken dabei). Es hat so lange gedauert, weil ich im Prinzip alles selber schreibe, ich verwende z.B. auch kein SDL. Und außerdem muss ich dauernd dran herumbasteln - es ist ein Hobby-Projekt.

Keine Bugs derzeit und auch keine MemoryLeaks. Neuer Code bedingt immer auch neue Bugs, aber das Fehler finden ist in letzter Zeit immer kürzer geworden, einerseits durch bessere Lazarus-Features und wahrscheinlich auch durch ein wenig mehr Disziplin meinerseits.

Eigentlich bin ich sehr zufrieden. Der einzige Wehrmutstropfen sind die fehlenden Pascalheader. Aber da sollte man nicht jammern, sondern die Ärmel aufkrempeln und sich an die Arbeit machen. Ich finde, ein Projekt wie Lazarus verdient Unterstützung.

Viele Grüße
Traude

Es scheint also wirklich so zu sein, dass Lazarus das Erbe von Delphi übernimmt. Das ist beruhigend, sollte aber auch Anlass sein, die Ärmel hochzukrempeln und den Fokus, z.B. in den Tutorials, auf Lazarus zu richten. Statt der Diskussionen, die nach meinen Beobachtungen immer mehr auf Therotisches fixiert sind, wäre zu überlegen (ich formulier mal vorsichtig), konkrete Unterstützung für die Lazarus-Umgebung anzubieten.

@Lord Horazont
Ich glaube, wir bewegen uns in verschiedenen Landschaften. Ich habe mich nie um neueste Dialekte von C++ bemüht, sondern war immer konservativ eingestellt, auch aus der Erfahrung heraus, dass bewährter, zeitloser Code am sichersten zu handeln ist. Ich habe auch immer C-Elemente eingebunden, vor allem deshalb, weil ich wiederholt mit Programmen zu tun hatte, die in C geschrieben waren. Es ist eine Einstellungssache, aber ich halte nichts davon, mich strikt von C zu distanzieren, wie das vor allem von militanten C++-Anhängern gefordert wird. Also nicht OOP um jeden Preis, aber das hatte ich weiter oben schon angedeutet. Ich hoffe, ich habe in den bisherigen Beiträgen immer von C/C++ gesprochen und nicht von ausschließlichem C++.

Ja, und wenn man C weiter ins Kalkül zieht, dann ist ein Struct nichts anderes als das, was man in Pascal mit Record bezeichnet. Und dieses schlichte "C-Record" kann nach meiner Auffassung (und Erfahrung) in bestimmten Situationen effektiver sein als eine Klasse oder das, was C++11-Missionare als "Struct" auffassen.

Man sieht, auch Programmiersprachen sind lebendige Sprachen.

Nochmals danke für die Hinweise und Erfahrungsberichte

3) adding codetyphon to lazarus you can go easily cross platform too.
http://www.pilotlogic.com/sitejoom/index.php/codetyphon

_________________
http://3das.noeska.com - create adventure games without programming

Noeska, thank you very much for that extremely helpful hint. I've installed codetyphon on Windows XP als well as on Ubuntu 12.04. Codetyphon with Lazarus (current version included !), a lot of useful tools and its cross platform support seems to be very promising. Indeed, it's a huge package (almost 500 MB as zip file, more than 2 GB after istallation) but the installation is a cinch. I'm sure, that's my way of further development.

Danke für den CodeTyphon Tipp Noeska! Hab das mal auf der Arbeit und eben auch hier privat installiert und schon meine ersten CrossBuilds von Win32 auf andere Plattformen für Projekt Weltherrscher gemacht. Das Ding belegt zwar schon über 3 GB, ist aber richtig praktisch.

Hast du damit schonmal von Windows nach MacOSX (Darwin) cross-compiliert? Bei mir lässt sich da leider nichtmal die Toolchain für Kompilieren. Wenn das gehen würde wärs die perfekte Entwicklungsumgebung

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)