[Jeux] ; TecnoballZ pour les amateurs d'Arkanoïd

Doug713705 wrote:

Ceci dit, le jeu ne fonctionne pas chez moi, je n'ai que le menu principal.
Quand je lance une partie, j'ai le message suivant : uanble to find
map01.bmp (un truc du genre).
Très très très étrange...

Le fichier map01.bmp est lu uniquement lorsque tu démarres une nouvelle
partie. Donc comme tu dis tu as bien le menu du jeu, mais je ne
vois pas pour quelle raison certains fichiers auraient été désarchivés
et par d'autres...

Je n'ai pas le temps de m'en occuper mais je pense qu'il suffit juste de
créer un script d'installation qui remette tout ça dans l'ordre dans un
repertoire (jai vu que le fichier map01.bmp était fourni, il doit
simplement pas être à la bonne place).
Je ne crois pas, mais là j'avoue ne pas savoir de quoi ça vient

(surtout que chez Phil ça fonctionne sur sa slak)
j'ai testé aves succès la compilation et l'execution avec Mdk10, Debian
et même sur Mac OS X + fink.

Bref ça mérite une meilleure finition quand à la compilation/installation.
Des détails quoi ... ;-)
C'est certain, mais on perd beaucoup de temps avec des détails...

Faudrait que je passe le tout en autoconf / automake.

Cordialement,
--
Pause Choco

Ainsi Parlait Rakotomandimby Mihamina <mihamina@mail.rktmb.org>

"Prouve-le".
Le slack a eu une facilité sur ce point précis. Cela ne veut en aucun
cas dire qu'elle est généralement supérieure.
"Tu as perdu".

La Slackware est RÉPUTÉE superieure.

--
Franck Yvonnet <franck@yvonnet.org>
"Reality is that which, when you stop believing in it, doesn't go away."
- Philip K. Dick

Pause Choco , dans le message <4187227D.8010209@voila.fr>, a écrit :

Le fichier map01.bmp est lu uniquement lorsque tu démarres une nouvelle
partie. Donc comme tu dis tu as bien le menu du jeu, mais je ne
vois pas pour quelle raison certains fichiers auraient été désarchivés
et par d'autres...

Ne serait-ce pas que ce fichier est cherché dans le répertoire courant, et
pas dans un répertoire configuré à la compilation ?

Et à part ça, pourquoi utiliser un format aussi nul que le BMP ?

Nicolas George wrote:

Ne serait-ce pas que ce fichier est cherché dans le répertoire courant, et
pas dans un répertoire configuré à la compilation ?
Non. La compilation n'affecte pas la recherche des fichiers qui se fait

toujours dans le répertoire courant. De plus la fonction de chargement
est identique à tous les fichiers.

Et à part ça, pourquoi utiliser un format aussi nul que le BMP ?
Pour éviter une dépendance supplémentaire vers SDL_image, le format

BMP est géré nativement pas SDL.

Cordialement,
--
Pause Choco

Bob Sinclar , dans le message <4187DDF0.4050400@voila.fr>, a écrit :

Non. La compilation n'affecte pas la recherche des fichiers qui se fait
toujours dans le répertoire courant.

Bon, alors c'est bien un mauvais design du programme. Un programme Unix est
censé pouvoir fonctionner en étant lancé depuis n'importe quel répertoire,
et se débrouiller pour trouver ses données automatiquement (en général par
un chemin codé en dur à la compilation, éventuellement altérable par une
option de ligne de commande un une variable d'environnement).

Pour éviter une dépendance supplémentaire vers SDL_image, le format
BMP est géré nativement pas SDL.

Impressionnant : la SDL sait lire le BMP et _seulement_ le BMP. C'est assez
ahurissant.

Bon, alors c'est bien un mauvais design du programme. Un programme Unix est
censé pouvoir fonctionner en étant lancé depuis n'importe quel répertoire,
et se débrouiller pour trouver ses données automatiquement (en général par
un chemin codé en dur à la compilation, éventuellement altérable par une
option de ligne de commande un une variable d'environnement).
Non non ce n'est pas un mauvais design du programme, juste la flemme de

regarder comment faire un autoconf/automake. La version 0.90
de TecnoballZ, comme tu l'as sûrement remarqué n'a pas de
"Make install", elle est prévue pour s'exécuter dans le
répertoire où le programme est compilé, même si la fonction
de localisation des fichiers est capable de parcourir plusieurs
chemins pour localiser les fichiers (voir la méthode
(ressources::locateFile() )

Si tu veux me faire un autoconf/automake je suis preneur, car le
programme pourra même se compiler sur *BSD et peut-être
même fonctionner sur ta Slackware, qui sait ?

De toute façon je ne comprends toujours pas cela ne compile pas
chez toi, surtout que Phil nous dit un peu plus haut dans
ce thread que cela fonctionne sur sa Slackware ! De plus j'ai
fait des tests sur Debian, Mandrake et Mac OS X. J'aimerai
bien comprendre où ça cloche. Essaie :
./tecnoballz --verbose

Impressionnant : la SDL sait lire le BMP et _seulement_ le BMP. C'est assez
ahurissant.
La bibliothèque SDL sait uniquement lire les fichiers BMP, mais son

extension sait lire une multitude de formats graphiques. (PNM, XPM, LBM,
PCX, GIF, JPEG, PNG, TGA). C'est un choix des développeurs de ne pas
surcharger La bibliothèque SDL de base tout en proposant une solution
à ceux qui comme toi ne veulent pas utiliser le format BMP.

D'ailleurs tu peux tout à fait convertir les fichiers BMP en PNG
par exemple, modifier la seule fonction SDL_LoadBMP par la fonction
IMG_Load et ajouter -lSDL_image dans le Makefile. Ca devrait
te prendre pas plus de temps que ça :-D

En tout cas on peut remercier Sam Lantinga et tous les développeurs de
SDL pour la qualité de leur travail.

Cordialement,
--
Pause Choco

Pause Choco , dans le message <4187E8D0.2010809@voila.fr>, a écrit :

Non non ce n'est pas un mauvais design du programme, juste la flemme de

La flemme peut être une cause de mauvais design.

regarder comment faire un autoconf/automake.

Tu n'as pas besoin de faire un autoconf pour faire ceci. Deux méthodes :

- tu crées un fichier config.h, dans lequel tu mets :

#define DATA_PATH "/usr/local/share/games/tecnoballz"

et tu mets un #include "config.h" dans tous les fichiers.

- tu mets en début de Makefile :

DATA_PATH = /usr/local/share/games/tecnoballz
CPPFLAGS += -DDATA_PATH="$(DATA_PATH)"

Et dans les deux cas, tu remplaces « "foo.bmp" » par
« DATA_PATH "/foo.bmp" » partout dans le programme. C'est tout.

De toute façon je ne comprends toujours pas cela ne compile pas
chez toi

Chez moi, c'est très simple, je n'ai pas essayé.

La bibliothèque SDL sait uniquement lire les fichiers BMP, mais son
extension sait lire une multitude de formats graphiques. (PNM, XPM, LBM,
PCX, GIF, JPEG, PNG, TGA). C'est un choix des développeurs de ne pas
surcharger La bibliothèque SDL de base tout en proposant une solution
à ceux qui comme toi ne veulent pas utiliser le format BMP.

Le choix de ne supporter qu'un format dans le noyau de la bibliothèque est
tout à fait légitime. Le choix que ce format soit BMP est complètement
débile, car BMP n'est ni simple (il y a un entête avec pas mal de
subtilités, et la possibilité d'avoir une compression RLE), ni puissant. Le
choix de PNM (simple) ou PNG (puissant) aurait été infiniment meilleur.

Nicolas George wrote:

La flemme peut être une cause de mauvais design.
Sûrement, mais comme tu peux le constater ce n'est pas le cas ici.

Tu n'as pas besoin de faire un autoconf pour faire ceci. Deux méthodes :
Oui je l'avais fait pour un autre projet mais je préfère de loin un

autoconf/automake, car cela va beaucoup loin (vérification de la
présence des devels et des bibliothèques, donne le bon chemin de
ces dernières) et le programme peut se compiler sur un éventail
plus large de système.

Chez moi, c'est très simple, je n'ai pas essayé.
Erreur de ma part je voulais dire pourquoi cela ne fonctionne

pas, mis à part le menu, sur la Slackware de Doug.

Le choix de ne supporter qu'un format dans le noyau de la bibliothèque est
tout à fait légitime. Le choix que ce format soit BMP est complètement
débile, car BMP n'est ni simple (il y a un entête avec pas mal de
subtilités, et la possibilité d'avoir une compression RLE), ni puissant. Le
choix de PNM (simple) ou PNG (puissant) aurait été infiniment meilleur.
C'est facile de dire çà aujourd'hui, mais il fallait le dire à

Sam Lantinga lorsqu'il a commencé à développer SDL en 1998. L'idée
lui est d'ailleurs venu en portant une application Windows sous Mac OS.
Le BMP était peut-être tout simplement le meilleur choix à l'époque.

Rappel sur le très connu format PNM :
Le PNM (Portable aNyMap) encapsule le PBM (portable bitmap) pour les
images bitmap (monochrome), le PGM (portable graymap) pour les images en
niveaux de gris et PPM (portable pixmap) pour les images couleurs était
peu-être moin connu à l'équoque qu'aujourd'hui, non c'est possible :-).

Personnellement je ne connaissais pas PPM, mais lorsque j'ai cherché à
récupérer des fichiers graphiques ILBM de mon Amiga, j'ai découvert
ilbmtoppm qui me proposait des fichiers PPM lisible dans GIMP (GIMP ne
lit pas les fichier IFF/ILBM de l'Amiga), que j'ai bien entendu
convertit en BMP :-))

Pour moi PNM ne me paraît ni pire ni meilleur que BMP, c'est kif kif
bourricot petit mulet. A vrai dire j'aurai préféré le support du PNG
en natif :-)

Bonne journée,
--
Pause Choco

Pause Choco , dans le message <41886DC5.9030508@voila.fr>, a écrit :

Oui je l'avais fait pour un autre projet mais je préfère de loin un
autoconf/automake, car cela va beaucoup loin (vérification de la
présence des devels et des bibliothèques, donne le bon chemin de
ces dernières) et le programme peut se compiler sur un éventail
plus large de système.

Pour moi, autoconf est une grosse connerie, qui mélange, et c'est
dramatique, la configuration des options de compilation, et la configuration
des dépendances au système.

C'est facile de dire çà aujourd'hui, mais il fallait le dire à
Sam Lantinga lorsqu'il a commencé à développer SDL en 1998.

Que ce soit vieux, et que personne n'ait été là pour signaler la bêtise
explique que ce soit resté, mais n'excuse pas le mauvais choix.

Pour moi PNM ne me paraît ni pire ni meilleur que BMP

L'entête est nettement plus simple, et il n'y a pas cette connerie de mettre
les données graphiques à l'envers par raport à tous les autres formats et la
disposition des images en mémoire.

On Wed, 3 Nov 2004 14:48:25 +0000 (UTC), Nicolas George wrote:

Pour moi, autoconf est une grosse connerie, qui mélange, et c'est
dramatique, la configuration des options de compilation, et la
configuration
des dépendances au système.

Pourtant les deux sont très liées et je trouve normal d'avoir un
outil qui puisse faire les deux. Par exemple si l'on n'a pas <pthread.h>
on ne va pas compiler avec -pthread.

C'est facile de dire çà aujourd'hui, mais il fallait le dire à
Sam Lantinga lorsqu'il a commencé à développer SDL en 1998.

Que ce soit vieux, et que personne n'ait été là pour signaler la
bêtise
explique que ce soit resté, mais n'excuse pas le mauvais choix.

Si personne n'a râlé contre la bêtise c'est peut-être que ça n'est
pas si bête que cela ?

Pour moi PNM ne me paraît ni pire ni meilleur que BMP

L'entête est nettement plus simple, et il n'y a pas cette connerie de
mettre
les données graphiques à l'envers par raport à tous les autres
formats et la
disposition des images en mémoire.

Premièrement, l'entête est plus simple dans sa description, mais
est nettement plus difficile à lire parce qu'elle n'est pas binaire
(il faut prendre en compte les espaces et les tabulations, sauter les
commentaires jusqu'à la fin de la ligne, etc.). À l'inverse, tout dans
BMP est défini par offsets binaires, ce qui en fait un format trivial à
lire.

Deuxièmement, un *énorme* défaut de PNM, qui le rend absolument
inutilisable comme format standard dans le contexte d'un jeu, c'est
qu'il ne sait pas gérer de palette. Une image en 256 couleurs est donc 2
à 4 fois plus grosse que l'équivalent en BMP.

Et enfin, le codage upside-down est loin d'être l'aberration isolée
que tu décris : le format TGA le supporte en option. Mais je pense
surtout à OpenGL qui requiert ses textures codées de bas en haut (ce
sera d'ailleurs le cas de n'importe quel système de coordonnées ayant
l'origine en bas à gauche et non en haut).

Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
Software should be free -- http://www.debian.org/
Media access should be free -- http://www.videolan.org/
Knowledge must be free -- http://www.wikipedia.org/