I hope I've remembered everyone who ought to be mentioned here. If your name should be included, my apologies, and please tell me so I can correct the oversight!
A.Cottrell (andrewc@dbworld.net.au).
Changed the grabber to use a more robust (locale-independent) date format.
Adrian Oboroc (doba@corefx.com).
Wrote the LBM loader.
Alex Demko (alex_demko@mbnet.mb.ca).
Suggested lots of improvements to the datafile system, and provided code
for handling the 8x16 BIOS font format.
Alessandro Monopoli (almonopo@tin.it).
Added the Italian translation of the system messages.
Andreas Kluge (bitland@aol.com).
Wrote the Ensoniq Soundscape driver and fixed division bugs in the fix
class.
Andrei 'old-boy' Ellman (ellman@xs4all.nl).
Contributed the polygon_z_normal() function.
Andrew Ellem (krand@ican.net).
Wrote the original version of the digital audio streaming code.
Andrew Geers (andy@geerswj.clara.net).
Added the -ppassword and -nosound options to the grabber, scrolling
support in the image viewer, and the flipped rotated sprite routines.
Andy Goth (andygoth@vetec.com).
Made the gfx_card config variable more flexible, added the 256x256
tweaked VGA mode, and wrote the d_text_list_proc() dialog object.
Angelo Mottola (a.mottola@libero.it).
Added the BeOS joystick, MIDI and windowed graphics drivers, added mouse
wheel, display switching and close button support for BeOS, and wrote the
DGA2 driver and close button support for X. Contributed a bfixicon
utility. Added triple buffering support to the BeOS port and added
fetch_mode_list() to the BeOS and DGA2 fullscreen drivers. And, oh,
contributed the QNX port too.
Annie Testes (email unknown).
Added font_height, render_char, char_length hooks to FONT_VTABLE.
Fixed several glitches in the unicode support. Added a pack_fdopen()
function. Caught a misordering in the X system shutdown. Found ASCII
strings that needed to be converted.
Antoine Mathys (mmathys@bluewin.ch).
Added the Swiss keyboard mapping.
Anton Ragnarsson (anton.ragnarsson@swipnet.se).
Contributed the Swedish keyboard mapping table.
Antti Haapala (ztane@lyseo.edu.ouka.fi).
Fixed the setup program to display the right frequency list for each type
of soundcard, and contributed the Finnish translation of the system
messages
Antti Haen _want_ to help you, let alone invest the amount of time it would take to read and understand such a huge mess of information. You must try to isolate a smaller chunk of code that demonstrates the trouble: the smaller you can make it, the more chance that someone will be able to help you with it. Remember that you are asking other people to do you a favour, so it is your responsibility to make this process as easy for them as you possibly can.
The most important thing is to include code that can be compiled and tested by the person reading your message. Don't just post your entire program: try to extract a small section that includes the specific lines causing your problem, or reproduces the trouble in a simpler way (you will often find that you can locate the error yourself in the process of making this simpler version, so it is a good exercise in itself). This code should be a small but complete program that can actually be compiled and run, because it is very hard to debug incomplete code fragments.
It is best to include the code directly in the text of your email message, because it is easier for people to read this than if they have to extract it from an attachment.
Ideally your example should avoid using any external graphics and data files. It is ok to include a small (max 2k) zip containing such information, or failing that a description of what other files it needs (eg. "put a 32x32 .pcx file called 'tile.pcx' into the same directory as the program). If there is no way that you can simplify things this far, you should upload the program and data to a website and then just post that URL in your message.
You should say what gcc command line you used to build the program, and this should include the -Wall switch.
Describe what you intended this program to do (it may not be instantly obvious to other people), and also what it really does when you run it. There is usually no need to post the actual crash traceback (other people can duplicate this for themselves as long as they are able to compile and run your code), but you should say whether you do get such a traceback, or a lockup, or just incorrect results (and if so, in exactly what way they differ from what you were expecting). It is useful to mark your source with a comment to show what line the crash traceback points to.
Any other information that you can include may also be useful. Most importantly a brief machine description, information about any relevant drivers, and your Allegro version (please don't just say "WIP", but give the exact date if you are using anything other than an official numbered release),
For reference, here is an example of what I would consider to be an ideal problem report:
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(); }