DOS Spieleprojekt mit DJGPP

Diskussion zum Thema Programmierung unter DOS (Intel x86)
GMBigB
Norton Commander
Beiträge: 141
Registriert: Fr 5. Mär 2010, 13:30

DOS Spieleprojekt mit DJGPP

Beitrag von GMBigB »

Ich habe gerade ein verlängertes DOS-Programmierwochenende hinter mir und weiß nicht, wo ich eigentlich stehe...

Mein langfristiges Ziel ist es Spiel fertigzustellen, für das bereits 90% Grafik und Sound fertig sind. Es war ursprünglich mal für WIndows geplant und ist dort auch schon spielbar, aber mir macht die Entwicklung für Windows keinen Spaß mehr. Auf die Idee das Spiel für DOS neu aufzusetzen bin ich durch emDosBox gekommen, wodurch die DosBox nun auch im Browser läuft. Und ein DOS-Spiel, was man dank DosBox überall spielen kann... und nun sogar im Browser - klingt irgendwie verlockend.

Als Compiler kommt nur DJGPP in Frage - seit dem 30.August sogar in neuer Version. Das erste Problem ist der Sound. Die vorhandene Musik ist überwiegend im Trackerformat (ImpulseTracker IT). Bei der Suche nach einer Library zum Abspielen bin ich zunächst auf DUMB gestoßen (http://dumb.sourceforge.net/). Bringt leider keine eigenen "Soundtreiber" mit, sondern braucht dafür Allegro. Also das letzte Allegro für DOS mal runtergeladen und natürlich hat das Buildscript nicht funktioniert... ich habe es auch nach Stunden nicht repariert bekommen. Ich habe dann einfach mal alle notwendigen Source-Dateien zusammengeschmissen und nach vielen weiteren Stunden konnte ich via Dumb die IT-Dateien abspielen. Der Klang war sehr gut, aber die Geschwindigkeit eine mittlere Katastrophe. Zugegeben sind 25 Kanäle auch ein bisschen Arbeit für den Mixer, aber die DosBox hat's in simulierter 486/66 Geschwindigkeit nicht mehr geschafft. Also ab damit in die Tonne!

Nächster Versuch: MikMod. Bringt eigenen "Soundtreiber" mit - ein großer Vorteil, da ich Allegro eigentlich nicht nutzen möchte. Einfach zu kompilieren und siehe da - die IT-Dateien werden abgespielt, klingen hervorragend und das Ding ist sogar richtig flott. Aber bisher hatte ich nur die DosBox zum Testen genommen... jetzt war der echte Dos-Rechner dran (486DX4-100). Und da lief nicht viel zusammen... nach stundemlangen Debuggen bin ich mir ziemlich sicher, dass der "Soundtreiber" für die GUS nicht funktioniert. Eine SB16 wird sogar gar nicht erkannt. SB-kompatible Soundkarten machen auch Probleme. Einzig die AWE32 und AWE64 funktionieren einwandfrei. Doof ist, dass in der DosBox alles funktioniert - sowohl SB wie auch GUS. Wahrscheinlich ist der Code auch nur damit getestet worden...

Frustrierend ist, dass man im Netz praktisch nichts mehr zur DOS-Entwicklung für DJGPP findet. Ich habe noch nie so viele tote Links angeklickt wie in den letzten 3 Tagen. Die letzte Version von MikMod ist zwar erst ein Jahr alt, aber die Mailingliste ist leer und ein Forum gibt es nicht. Ich schätze ich werde da selbst die Bugs fixen müssen... Ich vermute ich bin der erste Menschen seit mindestens 5 Jahren, der sich damit beschäftigt.

Dann wartet noch die Grafik. Das Vesa-Gefrickel kenne ich noch von früher. Aber hier macht mit FreeBasic ein wenig Hoffnung - das ist ein Compiler, der auch 32Bit DOS-Programme erstellen kann. Ich vermute die FreeBasic-Sourcen werden in C übersetzt und dann mit DJGPP kompiliert. Zumindest kann man ganz einfach Libraries, die man mit DJGPP erstellt hat, in Freebasic verwenden. Nur die Header-Dateien muss man natürlich umschreiben. Aber ich konnte MikMod auch für FreeBasic verwenden. Zwar crashen FreeBasic-Programme beim Beenden immer, aber die ganzen VESA-Routinen sind recht stabil und vor allem recht frisch. Hier scheint es noch ein paar aktive Entwickler zu geben, die den Compiler pflegen. Zum Prototyping von Grafikroutinen ist der Compiler - nicht zuletzt dank Inline-Assembler - wirklich prima.

Aber von diesem kleinen Hoffnungsschimmer abgesehen ist die Frustration schon groß. Ein Forum für DOS-Entwickler habe ich nicht gefunden. Deswegen kotze ich mich auch hier ein bisschen aus. :) Es ist schade zu sehen wie viel Wissen verloren gegangen ist. Vor 15 Jahren hätte mir wahrscheinlich jeder Mensch auf der Welt helfen können - heute weiß niemand mehr, wovon ich eigentlich rede. Ich werde das Forum hier ein bisschen auf dem Laufenden halten. Vielleicht mache ich ja nächstes Wochenende mehr Fortschritte.
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: DOS Spieleprojekt mit DJGPP

Beitrag von DOSferatu »

Cool. Ein Programmierer. Und sogar Spieleprogrammierung.
Ich programmiere zwar nicht mit DJGPP - aber unter und für DOS (auf einem 486er).
Und ebenfall Spiele.
Ich freue mich immer, mal einen "Kollegen" oder "Quasi-Kollegen" zu treffen.
Benutzeravatar
matze79
DOS-Gott
Beiträge: 7910
Registriert: So 9. Sep 2012, 20:48

Re: DOS Spieleprojekt mit DJGPP

Beitrag von matze79 »

FreeBasic hab ich auch rumprobiert, wegen der Software zum Firmware Update des PS/2 Converters.
Leider wird die DOS Version nicht mehr aktiv weiterentwickelt.
An sich ist es aber eine schöne alternative.
Leider funktioniert es aber nur unter DOS 7.1 / FreeDOS Korrekt (Lange Dateinamen...)
https://www.shadowcircuit.de - Die kleine Community rund um Retro Computing
https://www.retroianer.de
Benutzeravatar
philscomputerlab
DOS-Übermensch
Beiträge: 1273
Registriert: Fr 1. Okt 2010, 10:40
Wohnort: Australien
Kontaktdaten:

Re: DOS Spieleprojekt mit DJGPP

Beitrag von philscomputerlab »

Auf was fuer einem Rechner wuerde die Loesung mit Alegro funktionieren? Viele von uns haben schnellere Rechner wie einen Pentium II oder III und DOSBox kann auch schneller werken als ein DX2.
GMBigB
Norton Commander
Beiträge: 141
Registriert: Fr 5. Mär 2010, 13:30

Re: DOS Spieleprojekt mit DJGPP

Beitrag von GMBigB »

So, ich bin ein ganzes Stück weiter. Allegro kann ich endlich kompilieren. Man muss sich nur die Tools in den richtigen Versionen dafür zusammensuchen. Mit dem 5er GCC geht es nicht, daher verwende ich nun die 4.7.3. Und Allegro funktioniert recht gut und kann zuverlässig alle Grafikmodi verwenden. Ich habe diverse Grafikkarten ausprobiert und war überrascht. Die ganzen Zeichenfunktionen brauche ich nicht - da habe ich bessere. Und Allegro bringt viel Ballast mit, aber das schmeiße ich alles raus. Für das Setzen des Grafikmodus ist Allegro aber erste Wahl. Da werde ich nichts eigenes bauen. Erstaunlicherweise funktioniert das Warten auf den Vertical Retrace sogar in Vesa-Modi.

Mit dem Sound haben sich einige Probleme erledigt. MikMod mag es nicht, wenn die Soundkarte DMA 0 verwendet. Nur 1 und 3 funktionieren zuverlässig. Wenn man das beachtet, funktionieren auch SB-kompatible Karten. Die GUS macht immer noch Probleme. Hier muss ich definitiv patchen, aber das hat erstmal keine Priorität. Ich habe allerdings auch noch Sound als WAV hier. Momentan weiß ich nicht, wie ich den codieren soll. Als WAV zu groß, als MP3 in niedrigen Bitraten wird es qualitativ zu schlecht. Als OGG klingt er selbst bei 25kbit/sec (16 Bit 22050Khz) noch ganz anständig, allerdings verschlingt das Decodieren auf dem DX4/100 schon praktisch die ganze CPU-Power. MP3 ist da viel schneller. Ich brauche also irgendeinen anderen Codec. Ich werde mal mit ADPCM herumexperimentieren.

Ich möchte auf jeden Fall, dass das Spiel auf einem DX4/100 funktioniert. Das wird die minimale Systemanforderung sein. Der Sound (It-Files mit 16 Kanälen) verschlingt hier in niedriger Qualität ca. 20% Rechenleistung. Bei schnelleren PCs kann man eine höhere Auflösung und bessere Soundqualität wählen.

Technisch läuft also mittlerweile alles rund. Was die Entwicklung betrifft, gibt es zwei Dinge, die mich nerven: DosBox hat einen wahnwitzigen Bus-Durchsatz bei. Wenn ich mit XVesa den Durchsatz zur Grafikkarten messe, habe ich bei meinem DX4/100 ca. 15 MB/s. DosBox hat mal eben 600 MB/s... Das Schicken von Buffern an die Grafikkarte kostet auf einem echten DOS PC einen guten Teil der Rechenleistung. Bei der DosBox ist es quasi umsonst. Ich komme also nicht herum, auch mal auf einem echten DOS PC zu entwickeln. Rhide ist eine tolle IDE und macht Spaß - aber der GCC ist so wahnwitzig langsam, dass man eigentlich nur den Kopf schütteln kann. Selbst das Kompiliere und Linken von "Hello World" braucht auf einem DX4/100 fast eine Minute. Sobald man ein paar Libraries dazulinkt, dauert es noch länger. Ein einfaches Testprogramm mit Allegro und MikMod braucht für das Kompilieren und Linken auf einem K6-3 mit 400 Mhz fast 20 Sekunden. Ich gehe jede Wette ein, dass der Open Watcom mindestens um den Faktor 10 schneller ist...
Benutzeravatar
matze79
DOS-Gott
Beiträge: 7910
Registriert: So 9. Sep 2012, 20:48

Re: DOS Spieleprojekt mit DJGPP

Beitrag von matze79 »

Schon mal an MP2 gedacht ? muss ja nicht MP3 sein :)

Dosbox ist für gcc und Konsorten nicht wirklich geeignet.
Würde eher qemu einsetzen für solche Spielereien.

Lade unbedingt smartdrv wenn du gcc unter DOS benutzt! oder einen anderen Diskcache.
https://www.shadowcircuit.de - Die kleine Community rund um Retro Computing
https://www.retroianer.de
GMBigB
Norton Commander
Beiträge: 141
Registriert: Fr 5. Mär 2010, 13:30

Re: DOS Spieleprojekt mit DJGPP

Beitrag von GMBigB »

MP2 ist tatsächlich die Lösung. Nach ein wenig Gefrickel mit ADPCM und eher enttäuschender Qualität habe ich mich weiter auf die Suche gemacht und Musepack gefunden - ein an MP2 angelehnter Codec. Dekodierung von 32Khz Mono Sound kostet auf einem DX4/100 exakt 25% CPU-Power. Das ist gerade noch gerade noch so akzeptabel. Die Zeit ist dabei unabhängig von der Bitrate. So ab 80kbit/sec klingt das schon ganz anständig. Der nächste Schritt ist nun den Decoder in MikMod einzubauen.
GMBigB
Norton Commander
Beiträge: 141
Registriert: Fr 5. Mär 2010, 13:30

Re: DOS Spieleprojekt mit DJGPP

Beitrag von GMBigB »

Vielleicht mal ein kleines Update. Zur Zeit "übesetze" ich die Musepack Library in lesbares C++. Von Haus aus ist das Ding in Hardcore-C-Code geschrieben, voll von defines, typedefs, structs mit Funktionspointern, Variablennamen aus einem Buchstaben und ganz klassisch komplett unkommentiert. Das hat natürlich den Vorteil, dass es komplett plattformunabhängig ist, aber es ist ziemlich unmöglich da irgendwas hinzuzufügen oder rauszuziehen. Ich gehe nicht davon aus, dass ich Performance verliere, da die Bitfrickeleien ohne Big Endian Support auf jeden Fall schneller werden. Es ist immer die Gefahr bei einem großen Projekt vom Hundersten ins Tausendste abzudriften, aber in diesem Fall muss ich in den sauren Apfel beißen. Letztlich ist der Code für das Decoding nur ca. 3000 Zeilen groß. Das ist also überschaubar.

MikMod habe ich dahingehend erweitert, dass man die Möglichkeit hat selbst den DMA Buffer wieder zu füllen und dass das nicht - wie das derzeit der Fall ist - ausschließlich während des Interrupts passiert. Das machte das Debuggen (und das ist leider nötig bei den ganzen Bugs...) nämlich unmöglich.

Insgesamt macht der Sound mehr Probleme als er sollte, aber ich glaube dennoch auf einem guten Weg zu sein.
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: DOS Spieleprojekt mit DJGPP

Beitrag von DOSferatu »

GMBigB hat geschrieben:MikMod habe ich dahingehend erweitert, dass man die Möglichkeit hat selbst den DMA Buffer wieder zu füllen und dass das nicht - wie das derzeit der Fall ist - ausschließlich während des Interrupts passiert. Das machte das Debuggen (und das ist leider nötig bei den ganzen Bugs...) nämlich unmöglich.
Naja, ich nehme an, Double Buffering (oder wenn man will Triple) wäre die Lösung.
Ich lasse den Interrupt nur ein Flag setzen (bzw eigentlich einen Counter erhöhen) und in der Hauptschleife wird dann mal kurz die Soundgeneratorsubroutine aufgerufen um Counter*Teilpuffergröße den (die) nächsten Puffer zu füllen (nur sobald Counter <>0 ist natürlich).
Für 4-stimmigen Sound braucht mein 486er mit meiner Routine ca. 1 ms für 1kByte Puffer. (Die Routine kann max. 16 Stimmen, das Ganze skaliert aber nahezu linear (etwas weniger), d.h. für 16 Stimmen wären es etwas unter 4 ms bei 1kByte.)
Vielleicht ist es mit Soundblaster noch etwas schneller - momentan lasse ich das Ganze währenddessen "digital" (also mit dem "PWM-Trick") auf dem PC-Speaker mit 14 Khz ausgeben.
Natürlich ist die Qualität nicht mit "echter" Musik zu vergleichen - aber ich hatte ohnehin nie vor, fertige Musikstücke als WAV, VOC, MPx o.ä. zu verwenden - schon aus Gründen des Speichers. Mein Zeug ist nur digitale Klangsynthese.
GMBigB
Norton Commander
Beiträge: 141
Registriert: Fr 5. Mär 2010, 13:30

Re: DOS Spieleprojekt mit DJGPP

Beitrag von GMBigB »

Mal das nächste Update... um nicht den Eindruck zu erwecken, dass dies einer der zahlreichen Projekte ist, die irgendwann starben.

Mittlerweile ist der Musepack-Decoder in lesbares C++ konvertiert. Ein paar Optimierungen sind dazugekommen und die Codemenge für den Decoder hat sich um satte 30% reduziert. Dazu waren nur einige wenige Änderungen am Dateiformat nötig. Insbesondere habe ich jede Menge Bitgefrickel entfernt, so dass die Audio-Dateien zwar ca. 1% größer werden, aber schneller und einfacher decodiert werden können. Den Decoder habe ich mittlerweile auch mit MikMod verschmolzen, so dass ich jetzt tatsächlich MP2 unter DOS abspielen kann - und bei belieben mit anderen Samples oder Tracker-Dateien mischen kann. Das ist schon irgendwie ein Erlebnis zu sehen wie ein DX4 so ohne Mühe glasklaren Sound abspielt... Was noch komplett fehlt ist das loopen von großen Audio-Dateien.

Mit der Geschwindigkeit bin ich auch noch nicht ganz zufrieden. Ich habe hier den GCC in Verdacht... und werde mal andere Versionen und auch mal den Watcom Compiler ausprobieren. Zur Zeit nehme ich den GCC 4.7.3.

Momentan juckt es mir auch noch unter den Fingern... diese Huffman-Gefrickel in den Audio-Dateien sagt mir gar nicht zu. Ich bin eher ein Freund des kurzen und knappen Codes. Der Huffman-Decoder ist quasi unmöglich zu debuggen und die handerstellten Huffman-Tabellen ein Klotz am Bein. Immerhin 20% braucht der Decoder allein für die Huffman-Decodierung. Wenn ich stattdessen aber die Quantiesierungdaten mit einem simplen LZ-Algorithmus komprimiere, werden die Dateien gleich 60% größer. Die 20% für die Huffman-Decodierung sinken dann aber auf 1%.... Man bräuchte einen schönen LZ-Algorithmus, der auf diese Eingangsdaten optimiert ist. So 30-40% größere Dateien würden ich für 20% Geschwindigkeitsgewinn schon in Kauf nehmen.
go32
Kommandozeilenfetischist
Beiträge: 174
Registriert: Sa 24. Okt 2015, 22:51

Re: DOS Spieleprojekt mit DJGPP

Beitrag von go32 »

Hallo,

gibt es die DOS Version der Allegro noch irgendwo. Ich suche aber die letzte Pascal Version, die noch für DOS übersetzbar war.

Wo gibt es die noch und wo gibt es die dazu passende liballeg.a?

Reicht die liballeg.a aus oder braucht es noch mehr Bibliotheken, um die Pascal Version für DOS übersetzen zu können.

Ich weill die Allegro dann mit FPC 2.6.4 und der kürzlich erschienenen Version 3.0.0 für DOS übersetzen. Kann aber sein, dass ich dann Eure Hilfe brauche, falls der Übersetzungsvorgang fehlschlägt.
GMBigB
Norton Commander
Beiträge: 141
Registriert: Fr 5. Mär 2010, 13:30

Re: DOS Spieleprojekt mit DJGPP

Beitrag von GMBigB »

go32 hat geschrieben:Hallo,

gibt es die DOS Version der Allegro noch irgendwo. Ich suche aber die letzte Pascal Version, die noch für DOS übersetzbar war.

Wo gibt es die noch und wo gibt es die dazu passende liballeg.a?

Reicht die liballeg.a aus oder braucht es noch mehr Bibliotheken, um die Pascal Version für DOS übersetzen zu können.

Ich weill die Allegro dann mit FPC 2.6.4 und der kürzlich erschienenen Version 3.0.0 für DOS übersetzen. Kann aber sein, dass ich dann Eure Hilfe brauche, falls der Übersetzungsvorgang fehlschlägt.
Mit Pascal kenne ich mich überhaupt nicht aus, daher muss ich ein paar blöde Fragen stellen. Hast du so etwas wie einer Header-Datei? Ohne die dürftest dir weder eine statische (.a) noch dynamische Bibliothek (.dll) helfen. Ich kann dir selbstverständlich eine aus jeder beliebigen Allegro-Version bauen - ich muss nur wissen, welche.
GMBigB
Norton Commander
Beiträge: 141
Registriert: Fr 5. Mär 2010, 13:30

Re: DOS Spieleprojekt mit DJGPP

Beitrag von GMBigB »

Und wo ich gerade hier bin noch ein Update... in habe den letzten Monat nicht ganz soviel Zeit gefunden und bin noch mit der Integration meines Musepack-Forks in MikMod beschäftigt. Die ganze Huffman-Codierung ist aus Musepack entfernt und durch eine sehr simple, aber effektive andere Kompression ersetzt. Ergebnis: ca. 10% größere Dateien, 15% schnellere Dekodierung, 50% weniger Codezeilen. Ein guter Tausch wie ich finde. Dazu gibt es nun ein handvoll verschiedener Qualitäts-Modi beim Dekodieren. Das war so simpel, dass ich mir den anderen Kram eigentlich hätte sparen können... und ich mich frage, warum die Entwickler das nicht selbst eingebaut haben. Bei niedrigster Dekoder-Qualität holt man nochmal 50% an Geschwindigkeit raus. Ich selbst höre keinen Unterschied zur bestmöglichen Dekodierung, aber bin auch nur mit mittelmäßigem Gehör schlechten Boxen ausgestattet. Das Dekodieren (44Khz Mono 16 Bit) frisst damit auf einem 486DX4-100 weniger als 20% Rechenleistung. Damit kann man arbeiten.
go32
Kommandozeilenfetischist
Beiträge: 174
Registriert: Sa 24. Okt 2015, 22:51

Re: DOS Spieleprojekt mit DJGPP

Beitrag von go32 »

[quote=""GMBigB"]
Mit Pascal kenne ich mich überhaupt nicht aus, daher muss ich ein paar blöde Fragen stellen. Hast du so etwas wie einer Header-Datei? Ohne die dürftest dir weder eine statische (.a) noch dynamische Bibliothek (.dll) helfen. Ich kann dir selbstverständlich eine aus jeder beliebigen Allegro-Version bauen - ich muss nur wissen, welche.[/quote]

In Pascal git es gar keine Headerdateien. Das gibt es neben dem Hauptprogramm so genannte Units.

Syntax sieht so aus:

Code: Alles auswählen

unit meinecodes;  //meinecodes ist der Name der Unit, der beliebig vergeben werden kann

interface

{$LINKLIB liballeg.a}
//Mit so einer Compileroption lassen sich C/C++ Module in Pascal einbinden
//Hier muss ich noch lernen. Es kann auch so
{$LINKLIB alleg}
//heißen

//Da muss ich das Freepascal Team fragen, wie die richtige Schreibweise lautet, ich weiß nur, dass das Präfix "lib" 
//zwingend ist

//Unter DOS erlaubt Freepascal ausschließlich statische Bibliotheken (für go32, wwas nach meinem Wissen mit djgpp 
//kompatibel ist

uses
   System,  .... //und weitere vorkompilierte Mudule (Units)
   ;//Hineter der letzten Unit muss ein Semikolon stehen, die Units dazwischen sind durch Semikolon getrennt.

//Hier stehen Konstantenwerte, Typen, Variablen und Funktionsköpfe.
//Beispiel für eine Konstante:

const
   MAX_STRING_LENGTH = 255;

//Beispiel für einen Typ:

type
  l_short = shortint;
  TPoint = record
     x,y: Integer;
  end;

//Beisipel für eine Funktion

function CopyString(source, dest: String): String;
function CompareString(S1: String; S2: String; StrLen: Integer): Integer;

//Beispiel für eine Funktion ohne Rückgabewert (void in C/C++)

procedure InitMem; //Könnte ach Prameter enthalten, wie obige Funktion
//Die Reihenfolge Variable und ihr Typ ist umgekehrt im Vergleich zu C/C++. Zuerst die Variable, durch Doppelpunkt
//von deren Typ getrennt.
//Megerere Parameter entweder wie in Funktion CopyString, bei gleichem Typ oder wie in CompareString, dann durch Semikolon getrennt.

function allegro_meine_funktion_davon(mitparam1: PARMTYP; param2: PARAMTYP; ...): Rückgabewert; external;
//Beim statischen Linken wird die Bibliotheksfunktion nicht benannt.

//Es könnte auch eine UNit "allegro:pas' geschrieben werden, in der die C/C++ Module mit {$Linklib ...} eingebunden
//werden und dann genauso die exportierten Funktionen als external Definitionen übernommen werden. Was hier auch erforderlich ist. 
implementation

function CopyString(source,dest: String): String;
begin
  //hier steht der Code zur Implementation der Funktion
end;

function CompareString(S1: String; S2: String; StrLen: Integer): Integer;
begin
end;

procedure InitMem;
begin
end;

end.  //Ende der Unit

Als Pascal Version gibt es die Allegro-Pas-4.4.5, leider aber nur noch für Windows. Da aber hier schon Pascal Units existieren, wäre es wohl am günstigsten, die C/C++ Bibliotheken auch für diese Version für DOS zu übersetzen, es sei denn, dass die Pascal Units dann nicjt für DOS funktionieren. Ein Versuch ist es aber allemal wert.
go32
Kommandozeilenfetischist
Beiträge: 174
Registriert: Sa 24. Okt 2015, 22:51

Re: DOS Spieleprojekt mit DJGPP

Beitrag von go32 »

[quote=""GMBigB"]
Mit Pascal kenne ich mich überhaupt nicht aus, daher muss ich ein paar blöde Fragen stellen. Hast du so etwas wie einer Header-Datei? Ohne die dürftest dir weder eine statische (.a) noch dynamische Bibliothek (.dll) helfen. Ich kann dir selbstverständlich eine aus jeder beliebigen Allegro-Version bauen - ich muss nur wissen, welche.[/quote]

In Pascal git es gar keine Headerdateien. Das gibt es neben dem Hauptprogramm so genannte Units.

Syntax sieht so aus:

Code: Alles auswählen

unit meinecodes;  //meinecodes ist der Name der Unit, der beliebig vergeben werden kann

interface

{$LINKLIB liballeg.a}
//Mit so einer Compileroption lassen sich C/C++ Module in Pascal einbinden
//Hier muss ich noch lernen. Es kann auch so
{$LINKLIB alleg}
//heißen

//Da muss ich das Freepascal Team fragen, wie die richtige Schreibweise lautet, ich weiß nur, dass das Präfix "lib" 
//zwingend ist

//Unter DOS erlaubt Freepascal ausschließlich statische Bibliotheken (für go32, wwas nach meinem Wissen mit djgpp 
//kompatibel ist

uses
   System,  .... //und weitere vorkompilierte Mudule (Units)
   ;//Hineter der letzten Unit muss ein Semikolon stehen, die Units dazwischen sind durch Semikolon getrennt.

//Hier stehen Konstantenwerte, Typen, Variablen und Funktionsköpfe.
//Beispiel für eine Konstante:

const
   MAX_STRING_LENGTH = 255;

//Beispiel für einen Typ:

type
  l_short = shortint;
  TPoint = record
     x,y: Integer;
  end;

//Beisipel für eine Funktion

function CopyString(source, dest: String): String;
function CompareString(S1: String; S2: String; StrLen: Integer): Integer;

//Beispiel für eine Funktion ohne Rückgabewert (void in C/C++)

procedure InitMem; //Könnte ach Prameter enthalten, wie obige Funktion
//Die Reihenfolge Variable und ihr Typ ist umgekehrt im Vergleich zu C/C++. Zuerst die Variable, durch Doppelpunkt
//von deren Typ getrennt.
//Megerere Parameter entweder wie in Funktion CopyString, bei gleichem Typ oder wie in CompareString, dann durch Semikolon getrennt.

function allegro_meine_funktion_davon(mitparam1: PARMTYP; param2: PARAMTYP; ...): Rückgabewert; external;
//Beim statischen Linken wird die Bibliotheksfunktion nicht benannt.

//Es könnte auch eine UNit "allegro:pas' geschrieben werden, in der die C/C++ Module mit {$Linklib ...} eingebunden
//werden und dann genauso die exportierten Funktionen als external Definitionen übernommen werden. Was hier auch erforderlich ist. 
implementation

function CopyString(source,dest: String): String;
begin
  //hier steht der Code zur Implementation der Funktion
end;

function CompareString(S1: String; S2: String; StrLen: Integer): Integer;
begin
end;

procedure InitMem;
begin
end;

end.  //Ende der Unit

Als Pascal Version gibt es die Allegro-Pas-4.4.5, leider aber nur noch für Windows. Da aber hier schon Pascal Units existieren, wäre es wohl am günstigsten, die C/C++ Bibliotheken auch für diese Version für DOS zu übersetzen, es sei denn, dass die Pascal Units dann nicjt für DOS funktionieren. Ein Versuch ist es aber allemal wert.
Antworten