Ja, das ist etwas, wo ich dir wirklich leider zustimmen muss. Ich finde es eine Schande, dass man mit Lazarus (unter Linux, Windows hat das Problem nicht) nicht sofort loslegen kann, sondern erst zigtausend Pfade finden und festlegen muss. Das tut man am besten in einer fpc.cfg, wo man die hinlegen kann findest du per Manpage oder Google raus (ich habs gerade nicht im Kopf, sonst würde ich es dir sagen. Was auf jeden Fall geht, ist dein Home-Verzeichniss und das Projektverzeichniss). Wenn du da nach Anleitung die Pfade reingeschrieben hast, dann sind die immer aktiv und du musst dir nicht mehr viele Gedanken machen.

Ich hoffe du versuchst es nochmal.

Gruß Lord Horazont
//Edit: wenn du, was das betrifft, noch Probleme hast, kannst du mich gerne (per PM) anschreiben. Ich werd dann mein möglichstes tun.

_________________
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

Ich musste keine Pfade angeben, bei mir hat Lazarus auf Anhieb funktioniert. Ich sage ja, die Distris sind verschieden. Ich bin auf Ubuntu, das ein Debian-Fork ist. Debian unterscheidet sich von den anderen dadurch, dass sie ein ausgeklügeltes Abhängigkeitssystem haben (welche Bibliotheken müssen installiert sein, damit die neue Bibliothek XY funktioniert?). Manchmal ist das mühsam, aber wenn man sich durch die Installationsprozedur gequält hat, gibts kaum mehr Probleme.

Wenn ich kann, helfe ich Dir gerne. Aber ein paar Angaben wären auch nicht schlecht: was für eine Linux-Distribution, welche Lazarus Version, woher installiert und so weiter.

Aber eins kann ich mir nicht verkneifen (unterdrückte Kritik führt zu Einschlafstörungen): Angenommen, ich hätte den legendären Stein der Weisen zur Verfügung. Er sieht nur ein wenig schlicht aus: er ist grau und unregelmäßig geformt. Um ihn wirklich benutzen zu können, muss man drei riesige Bücher gelesen haben. Wirfst Du dann auch einen Blick auf die ersten drei Seiten, stellst fest, dass Du ihn nicht in Betrieb nehmen kannst und sagst mir: "Macht aber einen schlechten Eindruck." ?

Ich will auch mal was zur Thematik los werden.
Erstmal halte ich die 3 Lösungen, SDL, GTK, QT alle sammt für sehr schlecht.
QT und GTK sind sehr unausgereift(teilweise fiese Fehler und Logik Probleme unter den Platformen), ziemlich groß(holla die Waldfee sind mal wieder 100MB Speicher für ein leeres Fenster weg), langsam(im vergleich zu kommenden Alternativen), schwer zu beherschen(Windows macht es einen sehr schwer und beide Systeme sind sehr umfangreich), viel gefriemmel bei der erst benutzung(Thematik config, Version, Theme, abhängigkeiten von Bibliotheken, Lizenz), häftige abhängigkeiten(schöne Grüße an FreeType, Jpeg, libxml, zlib, ...).
SDL ist da wesentlich vorteilhafter(wenn man nicht gerade sdl_mixer und co verwendet) aber hat auch seine fiesen Krankheiten.
Die schlimmsten sind folgende, nur ein einziges Fenster, der Timer ist auf millisekunden beschränkt(unter windows träge GetTicks), einige tiefgehenden Fenstersettings fehlen, Probleme mit dem OpenGL Context in verbindung mit Fenster Events Resize, minimieren/maximieren und Vollbild.
Das sind Problematiken, die bei hohen Ansprüchen greifen aber für einfache prototypen, Anfänger Applikationen eher keien rolle spielen und daher SDL sehr empfehlenswert macht. Anmerkung: Irgendwann, im nächsten Jahrhundert kommt dann auch endlich mal die neue SDL Version, welche die meisten Probleme beseitigt.

Die Ideale Lösung ist natürlich die Software für die einzelnen Platformen anzupassen.
Wenn ich dich richtig verstanden habe und darauf baut meine Empfehlung, dann benötigst du nur ein Fenster und keine Komponentenbilbiothek.
Daher wäre es wohl einfacher für Windows ganz normal die WindowsAPI oder VCL zu verwenden und unter Linux ein TForm zu erstellen, welches die 4-5 X11 Befehle kapselt. Das ist ne Arbeit von ca 30min und du hast dein Fenster mit OpenGL Context unter Linux, ohne dein Code großartig umstellen zu müssen(ne handvoll IFDEF verringert den Umfang der Änderungen). Vorrausgesetz man kennt die API oder man weiß, wo es Codeschnippsel gibt.
Hier mal ein bischen Code, wie sowas ausehen kann(allerdings mit einigen mehr an Features)
X11 Implementierung
Linux high resolution Timer Bei Linux gibt es nur ein High resolution Timer, für Low Resolution wird ledeglich die Genauigkeit runter konvertiert.
Windows high/low resolution Timer

Solltest du doch noch mehr als ein Fenster und ein OpenGL Context benötigen, dann würde ich immernoch von GTK und QT abraten und ehr wxVCL verwenden.
GTK ist ein disaster unter Windows und QT hat bei mir ganz schön rumgezickt(bei den ersten versuchen), beim erstellen von Binaries für Windows.
Sonnst ist QT sehr toll aber hat eine nicht so schöne Lizenzpolitik, deshalb bin ich dann zu wxWidget gewechselt.
wxWidget geht die Sache anders an und versucht die lokalen APIs zu verwenden und damit sehen die Formulare geringfügig anders aus aber sind aufs äusserste Performant. WxWidget ist allerdings auch kein fliegengewicht und auch recht umfangreich, bietet z.B. auch ein GUI Editor(wxFormBuilder) und es gibt Anbindungen für verschiedene Sprachen(LUA,Perl,Python,Pascal,C++,...), Bibliotheken(GTK(einheitlicher look),VCL,Linux,Windows,...) und Komponentenbiliothken von fremden Programmierern.
Die meisten Komponenten sind wie bei Delphi VCL nicht mehr aus der Windows API sondern werden über Canvas selber realisiert und sind dementsprechend unter den Plattformen im gleichen Verhalten und look.

Eigene Komponenten entwickelt, für Farben mit float/double Kanal präzision und 4 Farbkanälen.
wxFormBuilder Projekt wo ein Unbekanntes Widget(Karmarama Engine) in wxWidget integriert ist.
Binarie sieht unter Windows und Linux exakt gleich aus(ausser der Fensterrahmen, welcher Themebedingt vom OS gezeichnet wird).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich stell mich auch gerade auf Linux um.

Ich wollte auch versuchen Plattform unabhängig (Windows und Linux) zu bleiben und mir dabei wieder einmal C++ genauer anschauen.
Jetzt stellt sich die frage wie ich per API in Linux überhaupt ein Fenster hinbekomme... in Windows wärs mir schon klar, aber unter Linux?

Ein Programmier-Professor hat mir Qt empfohlen...
Da ich meistens Java programmiere wär Qt schon sehr angenehm wegen OOP.

Ob ich schlussendlich dann C++ verwende muss ich mir noch überlegen, da Java bei Plattformunabhängigkeit keine Probleme macht.
Der Code wär mit C++ nur um einiges schöner...

Die Grundlage für Fenster und Kommunikation ist der X11 Server: http://de.wikipedia.org/wiki/X_Window_System. Auf diesem System basieren alle Toolkits/WidgetSets und wie sie alle heißen mögen. Sowohl GTK als auch QT müssen sich an das XProtokoll halten. Ich bin darin nur ein Halbgebildeter und kann Dir auch keinen C++-Sourcecode zeigen, weil ich meine ganze Software in Pascal geschrieben habe. Aber wenn Du Google nach "X11" "Create Window" oder etwas Ähnlichem fragst, wirst Du wahrscheinlich ziemlich viel zurückkriegen. Z.B. so etwas: http://tronche.com/gui/x/xlib-tutorial/2nd-program-anatomy.html
Traude

Hallo,

vielen Dank für eure Hilfe! Ich glaube ich mache es so, wie TAK es gesagt hat. Ich verzichte auf SDL und sonstige Libs und mache es so ähnlich wie in deinem Beispielcode.
Da hab ich den Vorteil, dass ich viel flexibler bin und nicht von Limitierungen wie SDL_GetTicks geplagt werde.
Außerdem muss ich damit nicht viel an meinem bisherigen Code ändern, nur ein paar andere Includefiles.

Ich werde mich mal an die Arbeit machen und euch gnadenlos ausfragen, falls Probleme auftreten

Markus

Markus,
eigentlich warst Du in meinem Beitrag gar nicht gemeint. Ich meinte Andreas, weil ich finde, dass es immer nützlich ist, bestimmte Dinge mal gehört zu haben.

Wie soll ich es diplomatisch ausdrücken? Der Weg, den du da beschreiten willst, ist ein ungemein steiniger. Ich persönlich - wenn ich Dein Berater wäre - würde Dir so etwas eigentlich nicht empfehlen. Und ich weiß, wovon ich spreche, denn ich habe das ganze jetzt gerade hinter mir. Vor allem würde ich es Dir nicht empfehlen, wenn eine Portierung eines Spiels ansteht. Wenn Du mir jetzt sagtest, Du möchtest Dich ein wenig mehr mit Linux beschäftigen, damit Du es besser kennen lernst, dann wäre das kein so großes Malheur, sich den X11 Server anzusehen. Aber wenn Du ein Spiel in einer angemessenen Zeit portieren willst, ist das ungefähr so, als würde ich Dich über die Eiger Nordwand schicken, um einen Liter Milch einzukaufen. Mit Fug und Recht könntest Du mich in einem solchen Fall als Berater fristlos entlassen

Hallo,

naja, ich sehe das nicht als ein so großes Problem. Ich brauche ja nur ein Fenster mit OpenGL-Kontext und ein paar Events für Tasten/Maus, das wars.
Mit der Win-API braucht man dafür nichtmal 200 Zeilen, ich glaube nicht, dass es mit X11 viel schwerer wird (ich lasse mich aber auch eines besseren Belehren).

Aber wie gesagt - ich habe nur sehr wenig Linux-Erfahrung, kannst du mal bitte beschreiben, was an einem solchen Ansatz "steinig" werden kann (In Bezug auf meine
kleinen Ansprüche)?

Markus

Meiner Meinung nach - da kann nicht viel steinig werden - auf alle Fälle nichts was sich nicht lösen lassen würde.
Ich hätte dir zwar nicht von Anfang an dazu geraten dich damit auseinanderzusetzen, aber schlecht ist es nicht. Es ist imho sogar gut sowas mal selbst zu machen um zu sehen wie es funktioniert.
Viel Spaß beim Neuland betreten

Ich kann die Kritik an Qt, GTK und SDL nicht wirklich nachvollziehen. Software enthält Fehler und Speicher geht verloren... eine Qt-Anwendung frisst bei mir ca. 400kb, wo 100MB her kommen, ist mir ein Rätsel. Gerade unter Linux sind diese Libs ohnehin geladen und wäre so als würde man unter Windows die WinAPI neuschreiben. Eine Portierung auf unterster Ebene weil man eine Ticker-Funktion nicht nutzen will, erschaudert mich. Wir leben nun einmal in einer sehr komplexen Welt bei der man sich auf Fremdbibliotheken verlassen muss, aber eine platformabhängige Entwicklung macht IMAO nur wirklich Sinn, wenn man etwas lernen will. Kein Projekt unter Linux täte auf die Idee kommen sich dies wirklich selbst anzutun und gegen Änderungen am Basis-System vorzunehmen. Linux verändert sich kontinuerlich weiter, so dass eine Verweigerung gegen Schnittstellen zu entwickeln eine Sysiphus-Arbeit gleich kommt. Aus wirtschaftlicher Sicht IMAO völlig inakzeptabel wenn man nur ein Fenster mit Kontext will.

Will sicherlich nicht jemanden den Spass verderben, aber einfach mal schauen, was die bisherigen Lösungen unter Linux verwenden, da wird das Bild recht einseitig und dort ist einiges an Personal vertreten, die durchaus wissen, wieso sie sich entsprechend so entschieden haben. Qt und Java sind in der Tat eine sehr schöne Kombination, die Anfangs ein wenig gewöhnungsbedürftig ist. Allerdings ist Qt sehr mächtig und bei meinen bisherigen Projekten ist es definitiv das Toolkit, was am meisten "Spass" macht genutzt zu werden. Wie immer: Nicht um sich ein Kontext zu erzeugen, sondern um eine komplexe Applikation zu schreiben. Würde also auch nicht die Eiger Nordwand empfehlen...

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

@Markus: Du fragtest nach einer Portierung für ein Spiel. Normalerweise kriegt man dann die Standardlösung präsentiert, und die ist in Deinem Fall eben SDL. Standardlösungen haben gewaltige Vorteile: es gibt massenhaft Tutorials und Ressourcen im Netz.

Aber ich möchte jetzt auch mal kommentieren, was Tak oben gesagt hat: das mit den 100 MB für ein Fenster müsste Dir schon zeigen, dass man diese Aussagen überprüfen muss. Das KANN vielleicht mal irgendwo vorkommen, wenn sich der Programmierer ganz besonders dumm anstellt. Aber es ist keinesfalls eine Entscheidungsgrundlage, ob man jetzt QT nehmen soll oder nicht, denn es ist übertrieben dargestellt.

Und was den PerformanceCounter betrifft: ich selber habe den Performance Counter in Windows überprüft, und ich kann sagen, dass auf *meinem* System der ach so genaue PerformanceCounter auch nicht besser arbeitet als GetTickCount: es kommt nämlich das Gleiche heraus.

Phobeus schrieb:

Genau.

Unter solchen Umständen wäre ich geradezu verrückt, wenn ich Dir etwas anderes empfehle als SDL. Wenn Du ein Grundlagenforscher bist, ist das was anderes. solche Leute ziehen ihre eigenen Lösungen vor. Klarerweise haben sie es dann auch viel schwerer. Alles, was Dir bei SDL einfach in den Schoß fällt, musst Du Dir mühsam erarbeiten. Das dauert eben länger. Klar bist Du dann am Ende mehr über das System informiert. Die Frage ist eben, ob Dir das wichtig ist, und vor allem, ob Du die Zeit opfern willst. DIESE Entscheidung nimmt Dir keiner ab. Wir hier gehen davon aus, dass Du deinen Aufwand minimieren willst.

Wir machen das, weil wir fürchten, dass Du irgendwann das Handtuch wirfst. Denn jeder, der „über den Jordan“ kommt, ist für uns - insbesondere für mich - etwas total Tolles, ein echter Gewinn. Aber wenns Probleme gibt, können wir einem Grundlagenforscher wahrscheinlich nicht helfen. Dies ist ein OpenGL-Forum.

Moin,

ich muss mir das nochmal gründlich überlegen, beides hat Vorteile und Nachteile.

Bis dahin will ich mich aber erstmal in Lazarus einarbeiten. Klappt soweit auch ganz gut, nur habe ich ein dämliches Problem... Das erstellte
Programm wird immer im Projektordner gespeichert, das will ich aber nicht. Für die Unit-Ausgabe kann man ja einen Ordner angeben, aber für
die exe habe ich keine Einstellung gefunden. Gibt es die überhaupt?

Lazarus v0.9.26

Markus

Kompilierte Units und Exe-Dateien werden afaik gleich behandelt - sollte also eigentlich ausreichen, diesen Pfad zu setzen. Und wo liegt das problem, wenn das an der falschen stelle liegt? Notfalls trägst du halt bei den Anwendungen, die nach dem Kompilieren ausgeführt werden sollen einen Copy-Befehl ein.

So. Und jetzt zu SDL & Co.
Als ich hier mitgelesen habe, war ich irgendwann ziehmlich entsetzt. Mal abgesehen davon, dass Qt nicht mehr leben würde, wenn es wirklich gang und gebe wäre, 100MB pro Fenster zu brauchen. Wenn sich wer über die ungenauigkeit von SDL_Ticks aufregt (@Traude: der Performance-Counter ist in der regel aber genauer, liegt wahrscheinlich an deiner Hardware): Warum bitteschön schreibt man sich dann nicht eine eigene Funktion, die je nach Plattform die passende Methode aufruft? Es hindert mich doch nichts und niemand daran, SDL zu benutzen und anstatt einiger SDL-Funktionen doch was eigenes zu schreiben. Ich verwende doch auch dglOpenGL, obwohl SDL mir eine Funktion anbietet, um OpenGL-Methoden zu laden...

Es ist meiner Meinung nach einfach nur verschenkte Zeit. Und wer hat davon genug?
Für ein Spiel, mit deinen genannten Ansprüchen, eine eigene Schnittstelle zur jeweiligen Plattform zu schreiben, ist glatter Schwachsinn. Und vorallem, mit SDL bekommst du MacOS gleich dazugeschenkt, wobei du dich bei einer eigenen Implementation auch darum kümmern müsstest.

So, ich hoffe, ich habe jetzt niemanden verschreckt mit meinen stellenweise etwas harten Worten. Aber ich glaube, das musste mal sein.

Gruß Lord Horazont
(keep smiling)

_________________
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

Wobei das, wenn man es bei der Zeitmessung (SDL_Ticks hat zwar bisher für mich immer gereicht, aber das juckt ja grad nich wirklich), dem Fenster sowie dem UserInput machen würde SDL doch ziemlich überflüssig machen würde.



Ich würde mal tippen das die meisten Leute hier aus Spaß programmieren. Von daher kommt es nicht wirklich drauf an ob man ein paar Tage später oder früher fertig wird, solange es ihm Spaß macht.
Nach eurer Logik dürfte doch eigentlich niemand mehr einen TextureLoader schreiben, da es ja glBitmap und SDL_Image(kein richtiger Loader, aber es unterstützt einen doch immens) gibt, die einem eigentlich alle Wünsche erfüllen, die man nur haben kann. Trotzdem würde ich nie jemandem versuchen auszureden, das er sich seinen eigenen TextureLoader für sein Projekt schreibt, ganz einfach weil es Wissen ist das einem hilft einiges beser zu verstehen.
Genau das gleiche greift imho hier - warum jemandem ausreden etwas selbst zu programmieren. Er kann doch eigentlich nur an Erfahrung gewinnen. Und wenns nur die Erfahrung ist das SDL um einiges Einfacher gewesen wäre
Btw. hab ich keinerlei Erfahrung in Richtung X11, Qt und GTK - kann also nicht wirklich was dazu sagen wie kompliziert das ganze wäre. Aber er kam selbst zu dem Schluss das er es am Liebsten so haben will. Schließlich sind die Nachteile die Tak an SDL nennt nich wirklich von der Hand zu weisen...

So, nachdem ich grade mit Lazarus unter Windows ne einfache SDL-Anwendung mit der TextSuite geschrieben habe, wollte ich das ganze auch unter Linux
kompilieren. Mein System:

Ubuntu 8.10 x64
Lazarus 0.9.24
FPC 2.2.2

Alles in den Standardeinstellungen.
Erst musste ich die Include-Verzeichnisse anpassen, danach kommt aber dieser Fehler:

/usr/share/fpcsrc/2.2.2/packages/pthreads/src/pthreads.pp(49) Error: Can't create object file: /usr/share/fpcsrc/2.2.2/packages/pthreads/src/pthreads.o

Woran kann das liegen (die Datei existiert noch nicht)? Unter Windows musste ich Lazarus nur installieren und das wars.

Edit: Lag an den Zugriffsrechten für den Ordner..

Markus