|
| Eine Bibliothek für Computer-Spiele-Programmierung | Sprachen: English español français 한국어 (Hangul) polski Italiano |
|
Was tun wenn ein Allegro-Programm nicht funktioniert?
Inhalt
EinführungWenn etwas nicht funktioniert, ist es oft eine gute Idee, andere um Hilfe zu bitten. Zum Glück für alle in dieser Situation gibt es viele (Allegro Entwickler sowie Anwender) die gerne Zeit damit verbringen, Anfragen dieser Art zu beantworten. Es gibt aber verschiedene Dinge, die man tun kann um diesen Prozess effizienter zu gestalten. Dieses Dokument beschreibt einige Schritte die man unternehmen kann, wann immer es ein Problem mit einem Allegro-Programm gibt - wie Methoden, um zu versuchen das Problem selbst zu lösen, und außerdem ein paar Tipps darüber wann/wie man um Hilfe fragen soll. Wenn diese Richtlinie befolgt werden, machen sie das Leben leichter sowohl für die, die helfen (sie bekommen die relevanten Informationen in einer prägnanten und verwertbaren Form), als auch für die, denen geholfen wird (sie bekommen eher eine rasche und präzise Antwort).
Teil 1 - Wer ist der Schuldige?Ist das Problem ein Fehler in Allegro, oder i, eigenen Code? Um das herauszufinden, sollte man versuchen, die Allegro Testprogramme auszuführen, besonders test.exe (für Probleme im Zusammenhang mit Graphikausgabe), play.exe (für Sound-Probleme), und auch die ganzen Programme im examples Verzeichnis (um festzustellen ob irgendetwas nicht funktioniert). Falls das Problem mit all diesen Programmen nicht reproduziert werden kann, ist es wahrscheinlich ein Fehler i, eigenen Programm. In diesem Fall kann Schritt 3 weiter unten übersprungen werden. Falls das Problem mit DOS Graphik-Modi zusammenhängt, sollte man sich eine Kopie des Display Doctor von http://www.scitechsoft.com/ besorgen. Falls das Problem damit gelöst wird, bedeutet es mit ziemlicher Sicherheit, dass das ursprüngliche Problem in einem fehlerhaften VESA-Treiber gelegen hat. Ich bin nicht daran interessiert, Berichte über Probleme dieser Art zu hören: Es gibt nichts was ich tun könnte um sie zu beheben. Ich fürchte, die einzige Option ist es, einen besseren VESA Treiber zu installieren, entweder indem man die Hersteller dazu bringt die Fehler zu korrigieren, oder indem man Display Doctor kauft, oder indem man einen FreeBE/AF Treiber für die Karte schreibt (siehe http://www.talula.demon.co.uk/freebe/).
Teil 2 - Wenn Allegro schuld istFalls Sie noch immer denken, dass das Problem bei Allegro liegt, schicken Sie einen Bericht mit einer Beschreibung des Problems, mit Information darüber welche Plattform Sie verwenden, welche Allegro-Version, unter welcher Hardware-Spezifikationen das Problem auftritt, und eine Liste der Programme mit denen das Problem reproduzierbar ist. (Es ist wichtig, nicht nur zu wissen, in welchen Programmen Fehler auftreten, sondern auch, in welchen sie nicht auftreten, falls es solche gibt). Falls das Problem mit einem DOS Grafik-Modus zusammenhängt, sollte man außerdem die Ausgabe der afinfo und vesainfo Programme (die Kurz-Version sollte ausreichen, außer man wird explizit aufgefordert die -v Option zu verwenden: Die Zusatzinformationen werden normalerweise nicht benötigt). Versuchen Sie, das Test-Programm mit verschiedenen Allegro-Treibern auszuführen (alle internen Treiber von denen Sie glauben, dass sie funktionieren könnten, VESA 2.0, und VESA 1.x), und in verschiedenen Video-Modi, und berichten genau welche Modi in welcher Farbtiefen Probleme verursachen. Falls überhaupt irgendwelche SVGA Modi verwendet werden können, starten sie das test Programm mit der Autodetect-Option und teilen den gesamten Text mit, der in der Mitte des Bildschirms dargestellt wird. Falls das Problem mit dem DOS Sound-System zusammenhängt, versuchen Sie das Setup-Programm zu benutzen, um die Karte manuell zu konfigurieren. Es kann notwendig sein, die Hardware-Parameter manuell einzustellen, und wenn die Karte ein SB-Klon ist, muss man vielleicht eine frühere SB Version einstellen als die, die entdeckt wird (SB Pro, SB 2.0, SB 1.0). Wenn noch immer nichts funktioniert, sollte der Bericht den Namen und eine Beschreibung der digitalen und MIDI-Treiber enthalten, die entdeckt werden (Diese Information wird in play.exe angezeigt).
Teil 3 - Wenn das Programm abstürztWenn ein djgpp-Programm abstürzt, wird normalerweise ein Stack-Trace ausgegeben, der ungefähr so aussieht:
Exiting due to signal SIGSEGV
General Protection Fault at eip=00001eca
[snip]
Call frame traceback EIPs:
0x00001eca
0x00001590
0x00001aea
Diese Information teilt einem mit, wo genau der Absturz passiert ist. Um
dem ganzen einen Sinn zu geben, sollte man das Programm mit
Debugging-Information kompilieren (mit der -g Option), und dann
"symify program.exe" ausführen, während der Stack-Trace noch am Bildschirm
sichtbar ist. Das wird ungefähr folgendes bewirken:
Call frame traceback EIPs:
0x00001eca _strcpy+14
0x00001590 _main+56, line 7 of t.c
0x00001aea ___crt1_startup+138
In diesem Fall kann man sehen, dass der Absturz innerhalb der strcpy()
Funktion stattgefunden hat, die in Zeile 7 der main() Funktion in der t.c
Quellcode-Datei aufgerufen wurde. Jetzt braucht man nur zu dieser Zeile
gehen, schauen was dort passiert, und den Fehler korrigieren :-)
Bemerkung: Falls der Absturz tief innerhalb einer Allegro-Funktion stattfindet, ist ein Stack-Trace meist nicht sehr nützlich. Wenn das passiert, kann man Allegro selbst mit Debugging-Information neu compilieren (in der readme Datei steht wie), und das Programm dann mit der Debug-Bibliothek linken. Bemerkung 2: Sogar wenn diese Stack-Traces auf eine Allegro-Funktion zeigen, heißt das nicht, dass diese Allegro Funktion fehlerhaft ist. Werden ungültige Parameter übergeben, kann jede Funktion einen Absturz verursachen. Solange das Problem also nicht in einem der Beispiel-Programme dupliziert werden kann, sollte man davon ausgehen, dass es ein Benutzer-Fehler ist und überprüfen, was genau an die Allegro-Funktion übergeben wird.
Teil 4 - Dinge die keiner macht (aber sollte)Einer der Haupt-Fehler, der von Programmierern gemacht wird, ist es, die Rückgabe-Werte von Funktionen zu ignorieren, die nicht erfolgreich sein könnten. So etwas kann oft zu unerwarteten und sehr ungewöhnlichen Fehlern führen, was das Debuggen zu einem Alptraum macht. In Allegro gibt es viele Funktionen, die funktionieren, oder auch nicht funktionieren können, je nach verschiedenen Umständen. Sie sind jedoch freundlich genug, einen wissen zu lassen ob sie erfolgreich waren oder nicht - mit dokumentierten Rückgabewerten. Wann immer man eine Funktion aufrufst, die versagen könnte (am wichtigsten set_gfx_mode(), install_sound, und alles das Daten aus dem Dateisystem lädt), ist es _essentiell wichtig_, den Rückgabewert zu überprüfen, und entsprechend darauf zu reagieren. Ein anderes oft vergessenes aber wichtiges Hilfsmittel ist es, strikte Warnungen für den Compiler einzuschalten (-Wall für gcc). Jede angezeigte Warnung weist mit ziemlicher Sicherheit auf einen Fehler im Programm hin, und sollte ausgebessert werden. Bei gcc ist es ein nützlicher Trick, gleichzeitig mit -O zu kompilieren, was gcc veranlasst, die Programmaktionen genauer zu untersuchen, wodurch genauere Warnungen ausgegeben werden. Normalerweise sollten Optimierungsoptionen während dem Debuggen aber ausgeschalten sein. Obwohl es bessere Warnungen zur Compile-Zeit gibt, könnte es Konflikte mit anderen Debugging-Tools verursachen, die man vielleicht später verwenden willst.
Teil 5 - Um Hilfe bittenOk, Sie haben also alles oben beschriebene versucht, und das Programm funktioniert noch immer nicht. Wenn Sie nicht mehr wissen, was Sie als nächstes tun sollen, ist es an der Zeit sich in die Obhut des Internets zu begeben, mit der Hoffnung, einen weisen Mann, einen Seher, oder ein Orakel zu finden, mit einer Antwort für Ihre Frage.. Der beste Platz ist die Allegro Mailing-Liste: lesen Sie readme.txt für Details. Bitte denken Sie daran, dass es eine Allegro-spezifische Liste ist. Probleme mit der C-Programmiersprache, oder mit dem DJGPP-Compiler, gehören in andere Foren (comp.lang.c oder comp.os.msdos.djgpp). Sowohl die Allegro als auch die djgpp Mailing-Listen haben Archive, und können von ihren Homepages aus durchsucht werden. Es ist sehr wahrscheinlich, dass Sie eine Lösung für das Problem finden, wenn Sie die Antworten auf alte Fragen durchsuchen, was Sie gänzlich davor bewahrt, eine neuen Frage stellen zu müssen. Im Einklang mit allgemeiner "Netiquette" kann man annehmen, dass jemand, wenn er/sie in ein Internet-Forum schreibst, zumindest zuvor die relevante Dokumentation gelesen hat, wenn nicht die ganze Dokumentation. Wenn es das Problem Wert ist, hunderte Leute um eine Antwort zu bitten, dann ist es es sicher auch wert, ein paar Minuten lang selber zu versuchen, es zu lösen. Allegro ist sehr durchgehend und genau dokumentiert, und es ist auch eine Voraussetzung, bevor man einen Beitrag abschickt, nicht nur den Text zu lesen, sondern auch die Beispiel-Programme zu untersuchen.
Teil 6 - Lerne aus meinen FehlernWas man nicht tun sollte, Teil Eins:
"Mein Programm stürzt ab. Warum?"
Ja, es gibt wirklich Leute die mir Fragen wie diese schicken :-) Trotz
Jahren der Übung ist es mir immer noch völlig unmöglich, Gedanken zu
lesen - deshalb ist es auch nicht sehr sinnvoll so eine Frage zu stellen.
Um Hilfe zu einem Problem zu erhalten, muss man es ausreichend detailliert
beschreiben, damit andere es verstehen und nachvollziehen können:
Normalerweise sollte man dazu einen Teil des Source-Codes beifügen.
Was man nicht tun sollte, Teil Zwei:
"Ich habe ein Problem mit meinem Programm. Ich füge eine 500k Zip-Datei
an, mit zehntausend Zeilen Sourcecode und allen meinen Grafik- und
Sounddaten: kannst du es bitte für mich debuggen und mir sagen, wo
das Problem liegt?"
Nach der vergeudeten Zeit und den vergeudeten Telefonkosten um eine so große Datei zu laden, ist es unwahrscheinlich, das irgendjemand überhaupt noch helfen _will_, geschweige denn die benötige Zeit investieren wird, um eine so große Informationsmenge zu lesen und zu verstehen. Man sollte versuchen, einen kleinen Code-Teil zu isolieren, der die Schwierigkeiten demonstriert: Je kleiner man ihn machen kannst, umso größer ist die Chance dass jemand helfen kann. Man sollte immer daran denken, dass man andere um einen Gefallen bittet. Es liegt alles in der eigenen Verantwortung, diesen Vorgang für die anderen so leicht wie möglich zu machen.
Teil 7 - Das Ansinnen in Worte fassenDas wichtigste ist es, Code beizufügen, der von der Person, die den Beitrag liest, kompiliert und getestet werden kann. Versenden Sie aber nicht einfach das ganzes Programm: Versuchen Sie, einen kleinen Teil zu extrahieren, der die relevanten Zeilen enthält, die das Problem verursachen, oder versuchen Sie das Problem auf eine einfachere Weise zu reproduzieren (Oft wird man den Fehler dabei selber entdecken, also ist es schon an sich eine gute Vorgehensweise). Dieser Code sollte ein kleines, aber komplettes Programm sein, das leicht kompiliert und ausgeführt werden kann, da es sehr schwer ist halb-fertigen Code oder Codefragmente zu debuggen. Am besten ist es den Code direkt in den Text des Mails einzufügen, weil es einfacher ist, ihn dort direkt zu lesen, als ein Attachment zu öffnen. Im Idealfall sollte das Beispiel keine externen Grafiken und Datafiles verwenden. Es ist aber in Ordnung, eine kleine (maximal 2k) Zip-Datei bereitzustellen, oder andernfalls eine Beschreibung, welche anderen Dateien benötigt werden (z.B. "Eine 32x32 .pcx Datei mit dem Namen 'tile.pcx' sollte im selben Verzeichnis als das Programm sein). Wenn es keine Möglichkeit gibt, das Programm so sehr zu vereinfachen, sollte man es auf eine Webseite stellen, und in der Nachricht nur die URL bekanntgeben. Man sollte immer angeben, welche Kommandozeile man verwendet hat, um das Programm mit gcc zu kompilieren, und das sollte immer -Wall enthalten. Man sollte auch beschreiben, was man mit dem Programm vorgehabt hat. (Es könnte sein, dass das für andere nicht sofort ersichtlich ist) - Und auch, was es dann tatsächlich tut, wenn man es ausführst. Es ist normalerweise nicht notwendig, einen tatsächlich Stack-Traceback einzufügen (andere können ihn selber duplizieren wenn sie das Programm kompilieren und ausführen), aber man sollte zumindest mitteilen, ob man einen solchen Stack-Traceback erhält, oder ob sich das System komplett "aufhängt", oder ob nur einfach das Ergebnis nicht korrekt ist (Falls das der Fall ist, gibt man auch an, worin genau sich das Ergebnis vom erwünschten unterscheidet). Es ist auch eine gute Idee, im Sourceode ein Kommentar an der Stelle einzufügen, die ein Programm-Absturz anzeigt. Auch jede andere Information, die man noch geben kann, könnte hilfreich sein. Am wichtigsten ist es, eine kurze Beschreibung des Computers, Informationen über relevante Treiber, und Ihre Allegro Version (Bitte nicht einfach WIP, sonder das genau Datum/Version, falls es sich nicht um eine offizielle Version handelt).
Teil 8 - Ein Modell zur PerfektionAls Vorlage ist hier ein Beispiel, wie ich mir einen idealen Problembericht vorstellen könnte (idealer Weise in Englisch):
I'm having some trouble using the hicolor video modes in my program,
although they work fine with the Allegro tests. I'm using Allegro 3.0
with djgpp 2.02 (gcc version 2.8.1) on a p166, running under win95 and
using the builtin VESA 2.0 driver, which the vesainfo program describes
as "Matrox Graphics Inc.".
This program is supposed to select a 640x480 16 bit resolution, draw a
blue rectangle near the top left corner of the screen, and then wait for
a keypress before quitting, but I just get a General Protection Fault
when I run it.
I compile it using "gcc -Wall t.c -o t.exe -lalleg", and don't get any
warnings.
--- cut here, t.c ---
#include <stdio.h>
#include <allegro.h>
void main()
{
BITMAP *bmp = screen;
install_keyboard();
if (set_gfx_mode(GFX_AUTODETECT, 640, 480, 0, 0) != 0) {
printf("Error setting video mode\n");
return;
}
set_color_depth(16);
/* crashes during this rectangle call! */
rectfill(bmp, 32, 32, 64, 64, 0x001F);
readkey();
}
|
| Zuletzt geändert: 8. April 2003, 21:58 (UTC). Mail an den Webmaster. |
