Moin,

ich habe vor mein Projekt (Tuxbomber) auf Linux zu portieren. Das Problem dabei ist nur, dass ich wenig bis keine Erfahrung mit Linux habe. Dafür zu Programmieren schon garnicht.
Deswegen hoffe ich, dass ihr ein bisschen Erfahrung damit habt und mir sagen könnt, was ich beachten sollte/muss.

Welche IDE ist zu empfehlen? Ich habe schon was von FPC gehört, das ist aber wohl eher ein Compiler?! Von Lazarus hab ich auch schon gehört.

Nun zu den Sachen, die in meinem Code Windowsabhängig sind.

- Der QueryPerformanceCounter - ist wohl nicht Windows-only, aber die Deklaration ist in der windows.pas
- Die VLC (nur für TForm)
- GetAsyncKeyState
- Unterstützung von Bitmaps (ist jedenfalls auch in der windows.pas)
- VirtualKeyCodes
- TServerSocket / TClientSocket basierend auf der Winsock-API

Manche Sachen davon haben sicher eine einfache Entsprechung, aber wenn ich an unseren Netcode denke, wird mir jetzt schon schlecht (was die Portierung angeht).
Welche libs/Methoden kann ich also dafür benutzen?

Wenn es sonst noch Tipps gibt, nur her damit

Markus

Jap, Freepascal ist ein Compiler.
Eine IDE wäre Lazarus. Ich persönlich kann nicht gut mit ihr arbeiten und bevorzuge deswegen meistens einen kleinen Editor mit Syntaxhighlighting und ein paar Extras, aber du solltest dir Lazarus zumindest mal anschauen, denke ich.



SDL!
Das Fenster lässt sich mit SDL erzeugen.
QueryPerformanceCounter lässt sich durch GetTicks ersetzen.
Mit SDL lassen sich Events abfragen, unter anderem ob ein eine Taste gedrückt bzw. losgelassen wurde (natürlich von allen Tasten)
Bitmaps müssten sich auch mit SDL laden lassen, wenn nicht gibt es noch glBitmap und falls das auch nicht in Frage kommt kann man immer noch schnell selbst einen kleinen Loader schreiben - zumindest normale 24bit-Bitmaps lassen sich sehr einfach laden.


edit: komplett vergessen, für die Netzwerkunterstützung gibts ja noch SDL_Net

SDL_image ist für das Laden, wenn du nicht die glBitmap benutzen willst (wobei ich nicht weiss, inwiefern die ohne die LCL/VCL klar kommt), eigentlich perfekt. Ich lege dir an dieser Stelle auch mal das Tutorial_SDL_RWops ans herz, wenn du deine Dateien lieber als Streams vorher lädst oder ein VFS benutzt.

Lazarus solltest du auf jeden Fall mal ausprobieren, die werden auch mit jeder Version besser

Gruß Lord Horazont

_________________
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

Wenn ihr auf SDL switched, habt ihr den Vorteil, dass ihr den Code nur einmal schreiben müsst, da SDL die Abstraktionsebene bereitstellt.
Alternativ müsstet ihr den Code selbst abstrahieren, und dann mit Compilerschalter, für die Verschiedenen OS kompilieren. Da habt ihr den vollen Zugriff aufs OS, aber auch deutlich mehr Aufwand.
Ich denke, SDL ist die Richtige Wahl.
Falls ihr die Sprache zur Diskussion stellt, wäre auch Java eine Alternative, allerdings wäre das ein, meiner Meinung nach, zu massiver Schritt.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Hallo Markus,
Das ist echt witzig, dass Du das grade jetzt schreibst. Von Ende Oktober vorigen Jahres bis jetzt war ich mit der Linux-Portierung meines Projekts (die glPasGUI) beschäftigt. Vor etwa zwei Stunden bin ich mit damit fertig geworden. Das feiere ich grade: Prost! Allerdings hatte ich es ein wenig schwerer als der Rest der Welt, denn ich bin stur: ich verwende kein SDL.

Was erwartet Dich in Linux, wenn Du Pascal verwendest:

Es gibt zwar GnuPascal, aber ich habe noch niemand getroffen, der das verwendet. Lazarus dagegen hat eine relativ große Fan-Gemeinde. Der Compiler hierbei ist immer FreePascal. Und FreePascal ist wirklich gut. Es braucht sich vor dem Delphi-Compiler bestimmt nicht zu verstecken, im Gegenteil. Free Pascal kann man wirklich ohne Wenn und Aber weiter empfehlen.

Aber ein Compiler allein macht noch keinen Sommer. Man braucht auch ein paar zusätzliche Hilfsmittel: einen Editor, einen Ersatz für die VCL, einen Debugger, und so weiter, eben eine richtige IDE: das liefert Lazarus. Er hat sogar einen Delphimodus, der dem Delphi7 ziemlich ähnlich ist, und ein paar nützliche Tools, um Delphi-Programme nach Lazarus zu portieren. Wenn man von Delphi kommt, ist die Lazarus-IDE gewöhnungsbedürftig, aber wenn man mal in die Pedale gekommen ist, kommt einem Delphi ganz fremd vor, wenn man wieder mal was drin zu tun hat. Hat also offensichtlich was mit Gewöhnung zu tun. Meine anfänglichen Vorurteile habe ich aufgegeben: nüchtern betrachtet gibt man was auf, aber man kriegt auch eine Menge dafür, zum Beispiel die Freiheit, ein anderes Betriebssystem zu wählen. Kommt eben drauf an, wie wichtig Dir das ist. Ich bin inzwischen der Meinung, dass man als Pascalianer was versäumt, wenn man Lazarus nicht getestet hat. Es ist dort ein wenig hemdsärmeliger als im „gestreamlineten“ Delphi, aber ich mag das. Die aktuellste stabile Version von Lazarus ist 0.9.26. Versuchs mal. Es kostet Dich nur ein wenig Zeit.

Wozu braucht man dann in drei Teufels Namen eigentlich SDL? Nun, Windows liefert neben seinen Betriebssystemfunktionen auch die Funktionen einer GUI. Die VCL baut auf den Windowskomponenten auf. Und wir sind verwöhnt: wir nehmen unseren OpenGL-Header im OnCreate eines Formulars in Betrieb. In Windows kann man unseren OpenGL-Header in Lazarus genauso verwenden wie in Delphi, denn Lazarus verwendet standardmäßig auch die Windows-GUI als „WidgetSet“ unter Windows und unser Header arbeitet mit der Windows-API zusammen. Leider gilt das nicht für Linux, denn Linux liefert standardmäßig *KEINE* GUI mit.

Diese Funktion wird von verschiedenen Bibliotheken übernommen, hauptsächlich GTK2 (GIMP, OpenSource) und QT(TrollTech, auch OpenSource, aber trotzdem proprietär). Unter Linux und Lazarus kann man sich z.B. entscheiden, welches WidgetSet man gerne haben möchte. Sowohl GTK als auch QT haben ihre eigenen Rendering Contexts gekapselt. Daher kann man in Linux nicht so einfach unseren OpenGL-Header zum Erzeugen des Rendering Contexts benutzen wie in Windows. Und selbst wenn man auf GTK/QT verzichten möchte, braucht man für Linux die GLX-Funktionen, das Pendant der WGL-Funktionen in Windows. Die grundlegenden GLX-Funktionen sind in unserem OpenGL-Header nicht enthalten, weil praktisch alle SDL verwenden. Und SDL nimmt einem wirklich einen Haufen Arbeit ab: den Rendering Context erzeugen, ein Fenster aufmachen, Bilder laden, Schriften bereitstellen, Events herankarren, und so weiter.
Deshalb wird hauptsächlich SDL verwendet. SDL hat aber nicht nur Vorteile: siehe z.B. hier: http://www.delphigl.com/forum/viewtopic.php?t=6135, und dann noch die Tatsache, dass mit SDL nur ein Fenster geöffnet werden kann. Muss man eben abwägen, was wichtiger ist.

Ach ja: wenn der RC mal erzeugt ist, ist der DGL-Header wieder einsatzfähig, genauso wie unter Windows.

Was ich Dir nicht verschweigen will: wenn Du ein Debugger-Fan bist, musst Du bei Lazarus mit einem Rückschritt rechnen. Lazarus verwendet den GNU-Debugger, und der ist nur teilweise für Pascal angepasst. Aber er arbeitet in der Zwischenzeit halbwegs so, dass man seinen Fehlern auf die Spur kommen kann.

Lazarus selber hat auch eine OpenGL-Komponente, also eine Komponente, die einen OpenGL-Rendering Context innerhalb eines Formulars zur Verfügung stellt. Allerdings kann man nicht beeinflussen, wie dieser Rendering Context erstellt wird. Ob das für Dich geeignet ist, musst Du selber prüfen.

Kurz zu Deinem Windows-abhängigen Code:

- Der QueryPerformanceCounter: so etwas müsste SDL haben, denke ich

- Die VLC (nur für TForm) : Lazarus hat so etwas, könnte man nutzen, wenn man die Lazarus OpenGL-Komponente nimmt

- GetAsyncKeyState : das ist ein Window-Spezifikum. Ich weiß nicht einmal, ob es so etwas in Linux gibt. Kommt jetzt drauf an, was Du damit bezweckst. Man müsste mal in Lazarus abtauchen und schauen, wie dort das „OnKeyPressed“ erzeugt wird

- Unterstützung von Bitmaps (ist jedenfalls auch in der windows.pas): Lazarus hat ein Äquivalent für Bitmaps, ist aber für OpenGL m.E. ungeeignet; empfehlenswert sind sowohl die glBitmap als auch SDL-Image

- VirtualKeyCodes : dasselbe in Grün gibts für Linux auch, heißt hier nur ein wenig anders; wie das ganze in SDL oder auch in Lazarus heißt, weiß ich leider nicht.

- TServerSocket / TClientSocket basierend auf der Winsock-API: Tja, da musst Du auf plattform-unabhängige Komponenten ausweichen; es gibt z.B. die Indy-Komponenten.

Ich hoffe, ich habe nichts vergessen.
Traude


PS: die glBitmap braucht weder die LCL noch die VCL und arbeitet unter Linux ganz ausgezeichnet.

Für die Sockets hätte ich vor einigen Monaten noch SDL_net empfohlen. Das implementiert zwar TCP und UDP Sockets Plattformunabhängig, hat aber einige große Nachteile (man kann sich nicht per Callback benachrichtigen lassen, wenn neue Daten eintreffen, alle funktionen sind Blocking (d.h. man muss auf das beenden der Ausführung warten). Diese Mankos auszugleichen bedarf einiges Threadentwickelns.

SDL hat soetwas wie VKs und sogar sowas wie GetAsyncKeystate, wenn ich mich recht erinnere. Schau dir dazu im Wiki mal die SDL_GetKeyState funktion an. Das dürfte das ersetzen. Du fragst die dinger halt mit SDLK_*-Konstanten an, die eine verdächtige Ähnlichkeit zu den VKs haben

Indys funktionieren mit Lazarus nicht zu 100% soweit ich mich erinnere. Außerdem sind sie auch recht komplex.

Der Performance counter ist mit SDL allein nicht zugreifbar. Man hat nur SDL_GetTicks, und das arbeitet nur mit 1/1000 sekunden, also wie GetTickCount.

Gruß Lord Horazont

_________________
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

Da muss ich mal korrigierend eingreifen. QT ist propritär, aber nicht OpenSource. Das Toolkit Qt ist OpenSource, aber nicht propritär. Dies war es vor langer Zeit einmal, ist es aber nicht mehr. Das etwas im kommerziellen Bereich kostet, macht es nicht propritär.

Genau die Argumentation mit den unterschiedlichen Platformen ist normalerweise das Killerargument für SDL, da es eben ähnlich wie DirectX verschiedene Funktionen bereit stellt, um eine Portierung auf mehrere Systeme vorzunehmen. Kodiert man sauber kann man ohne Probleme unter Windows entwickeln und anschließend nur noch unter Linux kodieren ohne einen Mehraufwand an Arbeit auf sich zu nehmen. Insbesondere da es einem viel vom Platformspezifischen Initalisieren wie mit WGL und GLX abnehmen kann. SDL_Net funktioniert eigentlich auch recht prima, kann stellenweise allerdings ein wenig abschrecken.

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

Und seit kurzem ist Qt unter der LGPL, was es für den kommerziellen Bereich auch kostenfrei macht, solange man es dynamisch linkt.
http://www.heise.de/newsticker/Qt-Toolk ... ung/121584

Phobeus schrieb:

Das stimmt natürlich. Trotzdem ist ein junger Mann, der sich seine ersten Sporen im Bereich Grafikprogrammierung verdient, gut beraten, wenn er für seine erste ernstgemeinte Veröffentlichung nicht mit Lizenzkosten zu rechnen hat.

Der oben zitierte Heise-Artikel stellt die LGPL für QT erst für März in Aussicht. Das ist also noch nicht über die Bühne gegangen. Und es könnte sein - da bin ich nicht sicher - dass die Lazarus-Widgetsets statisch gelinkt sind. Das kann man sich also möglicherweise garnicht aussuchen, ob statisch oder dynamisch gelinkt.

Allerdings ist die ganz Diskussion nur akademisch, weil bei Verwendung von SDL ginz sicherlich kein QT verwendet wird.


Ich sehe das genau umgekehrt, grade die Plattformunabhängigkeit ist doch der große Pluspunkt von SDL. Und dass DirectX eine Portierung auf mehrere Systeme bereitstellt, kannst Du nicht ernst meinen - oder ich verstehe Dich falsch.

Hallo,

vielen Dank schonmal für eure Antworten. Ich habe jetzt erstmal das ganze Windowszeugs auf SDL umgestellt. Das einzige, was noch fehlt ist der Netcode.
Kann man die Units Types, SysUtils, Classes und ähnliche, die nicht direkt was mit Windows zu tun haben auch mit FPC kompilieren?

Welche Units, die man "normalerweise" so beim Programmieren benutz muss man weglassen?

Markus

JA.

Eigentlich nur die Unit Windows.

@Traude: Normalerweise verwendet Phobeus tatsächlich hin und wieder Wörter in "kreativer" Weise. Das Wort Totschlagargument (siehe Wikipedia) nutzt er hier aber korrekt. D.h. du hast ihn falsch verstanden.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Dann hätte er sich aber ein wenig präziser ausdrücken können.
Traude

Hallo,

ich hab mir grad mal Linux auf ner zweiten HDD installiert und Lazarus runtergeladen. Schon beim starten bringt er mir nen Fehler von wegen der FPC-Include Ordner wäre nicht angegeben. Alle versuche den in den Optionen einzustellen sind mit ner Warnung der Ordner würde nicht richtig sein, gescheitert.

Danach wollte ich erstma das Projekt kompilieren, natürlich tausende von Warnungen und Fehlern. Units wie pthreads würden nicht gefunden werden, obwohl ich den Ordner der Datei im Includepfad angegeben habe...

Der erste Eindruck ist äußerst schlecht, fängt schon damit an, dass man nichtmal ein leeres Projekt compilen kann, dass mit File/New angelegt wurde. Wird wohl ein wenig dauern, bis ich die ganzen Probleme gelöst habe.

Markus

@Traude: Du bist über das "Killerargument" gestolpert? Beim Zweiten durchlesen ist mir der letzte Nebensatz eher bitter aufgestossen, da es wirklich so klingt als würde ich DirectX alspPlatformunabhängig bezeichnen. Zwar könnte ich mich rausreden in dem ich die X360 als Platform bezeichne, aber das nicht meine Absicht... war keine Empfehlung für DirectX Was ich meinte ist, dass das Argument schlechthin für SDL ist, dass es platformunabhängig ist, jedoch vom Funktionsumfang DirectX ähnelt. Immerhin kommt man mit einem Toolkit nicht wirklich weiter, da doch grundlegende Funktionen fehlen, die bei einer typischen SDL-Anwendung benötigt werden. Wer ein Spiel oder eine Vollbild-Anwendung schreibt wird mit SDL die erste Wahl haben.

Schreibt man eine "echte" Anwendung, wird man sich vermutlich schwer damit tun, da ein echtes Toolkit wesentlich mehr Funktionen bzgl. typischer Komponenten bietet. Aber auch hier würde ich als Linux-Nutzer sehr stark Qt empfehlen, dass meiner Meinung nach wesentlich intuitiver zu nutzen ist als gtk. (zumindest als OOPler).

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