Si la réponse n'est pas ici, demandez et elle sera ajoutée...
Lisez readme.txt.
Depuis n'importe quel miroir SimTel, dans le répertoire gnu/djgpp/v2tk/, ou à partir du site web d'Allegro, http://www.talula.demon.co.uk/allegro/.
Lisez allegro.txt.
Make fait partie de la distribution standard de djgpp, dans le fichier v2gnu/mak*b.zip (quel que soit le dernier numéro de version). Vous pouvez le récupérer à partir de http://www.delorie.com/djgpp/.
Etes-vous sûr d'avoir installé djgpp correctement ? Vérifiez les instructions dans le fichier readme.1st de DJGPP, et en particulier vérifiez que vous avez défini la variable d'environnement DJGPP et ajouté le répertoire djgpp\bin à votre path.
Etes-vous sûr de bien utiliser le programme make de GNU, et pas une autre version comme celle de Borland ? En cas de doute, tapez "make -v" et vérifiez que le message de copyright GNU s'affiche.
Vous ne devez pas lancer make à partir de l'explorateur de Windows ! Ouvrez une fenêtre DOS, allez dans votre répertoire Allegro, et tapez "make" sur la ligne de commande.
Etes-vous sûr que l'heure et la date système sont correctes ?
Comme le message d'erreur l'indique, vous devez fournir plus de mémoire au compilateur. Le programme go32-v2 vous indiquera la quantité de mémoire disponible actuellement. Si vous êtes sous DOS, essayez de libérer un peu plus d'espace disque pour l'utilisation comme fichier de swap. Si vous utilisez win95, augmentez la limite de mémoire DPMI pour votre session DOS jusqu'à 65535 (vous allez devoir saisir cette valeur à la main, parce que la liste déroulante ne va pas au delà de 16384).
Cela semble être un problème avec le linker de remplacement du package RSXNTDJ. Utilisez le linker djgpp standard, ou enlevez le flag "-s" du makefile d'Allegro. Si quelqu'un sait pourquoi çà arrive, et comment l'éviter, j'aimerais bien le savoir !
Vous n'avez pas lu les docs, si ? :-) Vous devez lier votre programme avec le fichier de la librairie liballeg.a. D'abord, assurez vous que vous avez tout installé correctement (lancer make devrait faire çà pour vous). Ensuite, si vous compilez à partir de la ligne de command ou d'un makefile, ajoutez -lalleg à la fin de votre ligne de commande gcc, ou si vous utilisez Rhide, allez dans le menu Options/Libraries, tapez 'alleg' dans le premier champ vide, et assurez vous que la boîte juste à côté est cochée.
Non, désolé. Pour débuter, liballeg.a fait à peu près 450k, mais vous voudrez aussi probablement divers utilitaires comme le grabber, le setup, etc. Et pourquoi pas tous les programmes d'exemple ? Si j'inclus les versions compilées de l'ensemble, une distribution binaire ferait plus de 7 megas: beaucoup trop gros dans la pratique ! Plus sérieusement, il n'y a aucune raison pour que ne vous le compiliez pas vous-même. La compilation est un processus déterministe : avec un fichier d'entrée et une ligne de commande donnés, çà produira toujours la même sortie. Si çà ne marche pas, soit vous n'avez pas les bons fichiers d'entrée (ie. votre copie d'Allegro a eu un problème quelconque), ou pas la bonne ligne de commande (c'est difficile de voir comment çà pourrait arriver, étant donné que tout ce que vous avez à faire est de taper "make"...) ou votre compilateur a un problème, ie. vous n'avez pas installé djgpp correctement. Vous devez trouver et corriger le problème, et pas juste le balayer sous le tapis en faisant compiler Allegro par quelqu'un d'autre pour vous...
Les outils GNU écrivent leurs messages d'erreur vers le flux d'erreur standard, stderr. Malheureusement, command.com est trop stupide pour savoir comment les rediriger, mais DJ a été assez astucieux pour corriger çà. Vous pouvez utiliser son programme redir pour capturer les messages de sortie, par exemple "redir -eo make > logfile.txt".
C'est variable. Certaines personnes ont rapporté des problèmes, alors que d'autres disent que çà marche bien. Je n'ai pas accès à NT moi-même, donc il n'y a rien que je puisse dire à ce propos, et pour être honnête, çà m'est un peu égal. Utilisez la version Windows d'Allegro si vous voulez créér des programmes Windows. Si vous voulez lancer des programmes DOS, utilisez DOS !
Oui, mais avec un peu de paramétrage. Si vous utilisez la version OpenDOS de EMM386, vous devez désactiver leur implémentation DPMI (spécifiez DPMI=OFF dans la ligne device EMM386.EXE de votre config.sys). Vous devez aussi vous assurer que le flag PIC est désactivé (PIC=OFF), mais c'est le cas par défaut donc ce ne sera pas un problème si vous ne l'avez pas spécifiquement activé.
Vous ne pouvez pas. Cette limite est imposée par le hardware VGA, pas par Allegro. Pour accéder à plus de 256 Ko de mémoire vidéo vous devez utiliser un mode SVGA, ce qui veut dire soit switcher vers une résolution plus élevée, soit récupérer une copie de SciTech Display Doctor, qui fournit plusieurs modes SVGA en basse résolution.
Cà marche pour certains, et pour d'autres pas. Le problème est que Creative Labs refuse de fournir ses spécifications, donc nous ne savons pas comment écrire un driver pour cette carte. Plaignez-vous directement à eux, ou achetez une autre carte d'un revendeur plus raisonnable.
Cà peut être du au fait que vous avez fixé le volume a un niveau très bas. Essayez de le changer dans le programme de setup. Allegro mixe plusieurs sons en un seul buffer de sortie, contrairement au lecteur de sons de Windows qui ne joue qu'un échantillon à la fois, donc chaque son individuel ne peut utiliser qu'un petit pourcentage du volume total de sortie. C'est juste le prix à payer pour avoir plusieurs canaux de sortie. Si vous n'aimez pas çà, utilisez le programme de setup pour changer le nombre de canaux : çà peut être n'importe quelle puissance de deux inférieure ou égale à 64, et plus ce nombre sera petit, plus le son sera fort.
Essayez d'utiliser un driver FreeBE/AF (http://www.talula.demon.co.uk/freebe/), ou le produit commercial SciTech Display Doctor (http://www.scitechsoft.com). Si çà ne marche toujours pas, postez une description de votre problème sur la liste de diffusion Allegro, avec une copie de la sortie de l'éxecution des programmes afinfo et vesainfo.
L'interface VBE/AF supporte déjà ce système pour les drivers vidéos : jetez un oeil au projet FreeBE/AF à http://www.talula.demon.co.uk/freebe/. Pour des choses plus générales comme le son, VESA, et les routines en mode-X, ce serait assez difficile à faire car les drivers dépendent d'un tas de fonctions de la librairie de base. Le format djgpp DXE n'est pas assez flexible pour permettre ce genre de choses, et je ne veux pas rendre Allegro dépendant d'autres packages de librairies dynamiques.
Vous devez vous mettre à jour avec une version plus récente du SDK DirectX, que vous pouvez récupérer à partir du site de Microsoft.
Vous devez écrire END_OF_MAIN() juste après votre fonction main(). Allegro l'utilise, avec quelques commandes pré-processeur, pour transformer une fonction main() normale en un point d'entrée Windows WinMain().
Oui euh, vous devez augmenter la taille de votre environement alors :-) Vous pouvez le faire en modifiant le paramétrage de votre boîte Dos (cliquez sur le menu système et sélectionnez Propriétés), ou au démarrage dans votre fichier config.sys (eg. "shell=c:\command.com /e:8192").
Vous devez écrire END_OF_MAIN() juste après votre fonction main(). Allegro l'utilise, avec quelques commandes pré-processeur, pour récupérer une copie de vos paramètres argv[] (il en a besoin pour certaines choses en interne).
Vous devez rediriger stderr vers un fichier, pour pouvoir les visualiser plus tard. La méthode pour le faire dépend de votre shell : si vous utilisez un shell style Bourne comme bash, essayez "make 2> logfile.txt".
Le grabber doit être linké avec le code de datedit.c. Mais vous n'avez pas à la faire à la main : lancez seulement "make" et tout se compilera automatiquement.
Pas tant que <X> n'est pas mentionné dans le readme.txt comme étant une plate-forme supportée. Vous pouvez le porter vous-même, mais çà nécessite généralement un travail important. Si <X> est un compilateur DOS 16 bits comme Borland C, vous feriez mieux de carrément oublier cette idée :-)
WIP signifie "work in progress" ou "version en cours de développement", et fait référence à tous les changements qui sont plus récents que la dernière distribution officielle. Les versions WIP de la libraire sont disponibles sous la forme de patches à partir du site d'Allegro (http://www.talula.demon.co.uk/allegro/), et sont généralement assez stables, bien qu'évidemment pas aussi bien testées que des versions stables.
Avez-vous une copie de patch.exe ? Si ce n'est pas le cas, récupérez le à partir du même endroit que celui où vous avez récupéré le reste de djgpp : c'est un outil standard de la distribution du compilateur. Si vous avez le programme patch.exe mais qu'il ne fonctionne pas correctement, assurez vous que vous installez le patch sur une copie non modifiée de la version d'Allegro que vous voulez mettre à jour (ce sera généralement la version officielle la plus récente avant que les WIP existent, mais vérifiez dans le fichier texte que vous trouverez dans la WIP pour être sûr).
C'est simplement de cette façon que fonctionne le hardware vidéo : il ne peut y avoir qu'une palette utilisée à un moment donné. Essayez soit de convertir vos images pour qu'elles utilisent toutes la même palette, soit de changer votre mode graphique vers un mode trucolor.
Jetez un oeil aux utilitaires sur le site d'Allegro (http://www.talula.demon.co.uk/allegro/) comme par exemple FixPal et Smacker.
Le hardware VGA utilise seulement 6 bits pour chaque composante de couleur, ce qui signifie que les valeurs de rouge, vert et bleu dans la palette vont de 0 à 63, et pas jusqu'à 255. Cela vous donne un accès théorique à 2^18 = 262144 couleurs différentes, ou 64 niveaux de gris. Si vous en voulez plus vous pouvez essayer d'utiliser la fonction VESA 0x4F08 pour sélectionner un DAC de 8 bits, mais Allegro ne le supporte pas directement et je ne sais pas à quel point c'est fiable sur différents hardware.
Quand vous êtes dans un mode 256 couleurs, la carte VGA affiche la couleur #0 autour de la bordure de la zone d'affichage (dans les modes truecolor çà affiche du noir). Votre couleur bizarre disparaîtra si vous modifiez la palette pour que la couleur #0 soit le noir.
Avec beaucoup de difficultés :-) Il n'y a pas d'astuce aussi simple que de juste modifier la palette, donc vous devrez redessiner l'image plusieurs fois sous une forme plus claire ou plus foncée. Vous pourriez dessiner des rectangles noirs translucides par dessus l'écran pour l'assombrir, ou utiliser draw_lit_sprite() pour teinter un bitmap pendant que vous le copiez vers l'écran, mais sachez que ces opérations sont lourdes et nécessitent un PC rapide !
Jetez un oeil aux utilitaires sur le site d'Allegro (http://www.talula.demon.co.uk/allegro/) comme par exemple DTA et Smacker.
Dans votre programme de dessin favori, modifiez la couleur en mode RVB en faisant en sorte que les valeurs pour le rouge et le bleu soient au maximum (généralement 255, mais çà dépend des unités utilisées par votre logiciel), et que la valeur du vert soit à zéro. Le résultat est une teinte spéciale de rose clair, qu'on appelle aussi magenta.
Un des objets GUI a modifié la configuration de text_mode() alors qu'il était en train de se dessiner lui-même. Appelez text_mode() de nouveau pour sélectionner la couleur de fond que vous voulez utiliser.
Rappelez-vous que les positions des sommets sont stockées dans le format point fixe, donc vous devez utiliser la macro itofix() ou décaler vos coordonnées de 16 bits vers la gauche.
Rappelez-vous que les angles de rotation sont stockées dans le format point fixe, donc vous devez utiliser la macro itofix() ou décaler vos coordonnées de 16 bits vers la gauche. Par exemple, rotate_sprite(bmp, spr, x, y, itofix(32)) effectuera une rotation du graphique de 45 degrés.
Vous essayez probablement d'initialiser la structure du dialogue avec un pointeur sur votre bitmap, exact ? Cà ne marchera pas parce que le dialogue est créé à la compilation, mais le bitmap est seulement chargé à l'éxecution, donc le compilateur ne sait pas encore où il sera localisé. Vous devez affecter la structure du dialogue avec un pointeur NULL, puis ensuite copier le pointeur réel du bitmap dans le champ dp lors de l'initialisation de votre programme, après que vous ayez chargé le bitmap en mémoire.
Cà dépend de ce que vous faites exactement. Si vos images sont complètement opaques, il n'y a aucun avantage à utiliser des sprites RLE, et ce sera probablement plus rapîde d'utiliser des bitmaps classiques avec la fonction blit(). Si vos graphiques contiennent des zones masquées, un sprite RLE sera presque toujours plus petit et plus rapide que la fonction draw_sprite(). Les sprites compilés sont en général plus rapides que les deux autres pour les images masquées, et un peu plus rapide pour les images opaques, mais c'est beaucoup plus variable. Ils sont plus efficace avec des petits sprites, sur des machines plus anciennes et en mode-X, et peuvent être plus lent que blit() quand vous utilisez les modes SVGA sur un pentium (la grande taille des sprites compilés est très mauvaise pour la performance du cache).
Vous devez vous assurer que la logique du jeu est mise à jour à un rythme régulier, mais sauter le rafraîchissement écran de temps en temps si l'ordinateur est trop lent pour suivre. Cà peut être fait en installant un gestionnaire de timer qui va incrémenter une variable globale à la vitesse de la logique de votre jeu, càd :
volatile int speed_counter = 0;
void increment_speed_counter()
{
speed_counter++;
}
END_OF_FUNCTION(increment_speed_counter);
void play_the_game()
{
LOCK_VARIABLE(speed_counter);
LOCK_FUNCTION(increment_speed_counter);
install_int_ex(increment_speed_counter, BPS_TO_TIMER(60));
while (!game_over) {
while (speed_counter > 0) {
update_game_logic();
speed_counter--;
}
update_display();
}
}
Ajoutez un appel à save_bitmap() quelque part dans votre code. Lisez la documentation de save_bitmap() pour une discussion sur un piège classique dans ce type d'utilisation, et un code d'exemple.
Appelez srand(time(NULL)) au début de votre programme, et utilisez ensuite rand()%limit pour obtenir un nombre pseudo-aléatoire entre 0 et limit-1.
Il n'y en a pas besoin. Le linker va uniquement inclure les parties de la librairie que vous utilisez effectivement, donc si vous n'utilisez aucune des routines de texture mapping ou d'affichage de FLIC, par exemple, elles ne seront pas intégrées à votre exécutable. Cà ne marche pas parfaitement parce qu'une grande partie du code d'Allegro utilise des pointeurs sur des tables de fonctions qui font que certaines routines non nécessaires sont linkées, donc la majorité des fonctions graphiques seront intégrées dans chaque exécutable, mais j'ai essayé de le réduire au minimum. Lisez allegro.txt pour avoir des informations sur des moyens plus précis d'enlever quelques drivers graphiques et sonores.
Non. Je pense que cette sorte de support matériel serait plus utile dans une vraie librairie 3D, ce qu'Allegro n'est pas, et ne sera jamais. Si vous voulez travailler là-dessus, la librairie MESA (une implémentation libre d'OpenGL) est AMHA l'endroit où démarrer.
Il en existe déjà plusieurs qui sont très bien, par exemple le package JGMOD. Jetez un oeil aux liens sur le site web d'Allegro (http://www.talula.demon.co.uk/allegro/). Vous n'êtes pas autorisé à suggérer que l'une de ces librairies soit intégrée à Allegro, parce que ce sujet a déjà été abordé et abandonné dans la liste de diffusion et que je suis fatigué d'en entendre parler.
Ce serait un gros travail, et je n'ai pas le temps de m'en occuper moi-même. Il existe déjà plusieurs packages réseau actuellement en développement ou se balladant sur le net, et à mon avis, ce genre de code est plus utile en tant que librairie externe qu'il ne le serait en étant intégré à Allegro.
Unisys dispose d'un brevet sur l'algorithme de compression LZW qui est utilisé par le format GIF. Je veux que tout ce qui est dans Allegro soit librement utilisable sans aucune restriction, ce qui veut dire que je ne peux pas inclure un code breveté ou sujet au paiement de royalties.
Peut-être. Essayez d'isoler le plus petit fragment de code qui est capable de reproduire le problème, et j'essayerai d'y jeter un oeil. Si vous pouvez m'envoyer un programme de 10 lignes, je le corrigerai. 100 lignes, et je pourrais probablement le corriger. 1000 lignes, et je n'aurais aucune chance :-)
Bien sûr. Lisez les termes de la licence giftware dans le fichier readme.txt. Je n'ai pas à m'occuper de ce que vous faites avec, et il n'y a aucun problème pour un usage commercial.
Quand ce sera fait ! Un peu d'encouragement est toujours le bienvenu, mais je n'ai pas de contrainte de temps, et je ne vais pas m'en imposer une pour vous :-) Dès que ce sera fini, se sera distribué.
Le grabber peut importer directement des fontes GRX ou BIOS au format .fnt, ou vous pouvez les dessiner sur une image .pcx en utilisant n'importe quel programme de dessin. Sur http://www.talula.demon.co.uk/ttf2pcx/ vous trouverez un qui permete de convertir des fontes Windows au format TrueType fonts vers le format .pcx.
Regardez les liens sur le site Allegro (http://www.talula.demon.co.uk/allegro/). Vous pouvez utiliser des patches Gravis (format .pat), ou SoundFont 2.0 (format .sf2), mais le dernier doit être converti vers un fichier patches.dat avec l'utilitaire pat2dat.
Vous devez télécharger l'outil de conversion makertf (ftp://ftp.coast.net/Coast/win3/winhelp/mkrtf104.zip), et le compilateur d'aide Windows (ftp://ftp.microsoft.com/Softlib/MSLFILES/HC505.EXE). Crééz un répertoire temporaire, copiez le fichier allegro.txi du répertoire allegro/docs, et lancez les commandes "makertf --no-warn allegro.txi -o allegro.rtf -J allegro.hpj" suivi par "hcp allegro.hpj". La seconde commande affichera un tas de warnings, mais elles peuvent être ignorées.
Le fichier allegro.rtf peut être lu directement avec Microsoft Word et imprimé à partir de là, mais vous devrez d'abord cliquer sur le bouton droit de la souris et mettre à jour la table des matières et les champs d'index pour les remplir avec les données correctes. Sinon, vous pouvez installer le package TeX et utiliser les programmes tex et dvips pour convertir allegro.txi vers le format Postscript.
Regardez sur le site d'Allegro, http://www.talula.demon.co.uk/allegro/. Si vous avez quoi que ce soit à y ajouter, s'il vous plaît envoyez-moi l'adresse !
Cà simplifie la maintenance de votre programme, au cas où la valeur de PI aurait besoin d'être modifiée. Et puis çà rendra votre programme plus portable pour d'autres compilateurs qui utilisent une autre valeur de PI.
Regardez http://www.talula.demon.co.uk/allegro/maillist.html.