Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

diabolos29 · Le 16/12/2012, à 10:07

Bonjour,

Je travaille sur un projet d'action RPG type Zelda 3 (version SNES) depuis plus d'un an sur mon temps libre et ça avance tranquillement mais sûrement.

Aujourd'hui, et pour ceux que ça intéresse donc, je suis à la recherche de personnes désireuses de tester mon moteur de jeu.

Je souhaite particulièrement connaître :
- la configuration matérielle de la machine sur laquelle vous faites les tests (processeur, RAM, autre).
- la consommation de ressources du jeu sur votre machine. Lorsque le jeu est lancé, ouvrez un terminal et tapez la commande "top". Les valeurs des colonnes %CPU et %MEM de la ligne ActionRPG m'intéressent.
- vos commentaires sur le système de gestion des collisions et sur les déplacements en général.
- vos commentaires autres.

Notes :
1° c'est tout sauf un jeu fini.
2° le jeu est compilé pour GNU/Linux uniquement (un makefile est disponible). Les sources sont disponibles mais je ne peux pas assurer en cas de problèmes pour le compiler ailleurs.
3° le jeu est codé en C++ et nécessite pour le moment les libs SDL, SDL image et SDL gfx.

Enter -> menu du jeu
P -> pause
espace -> parler
A -> épée
Q -> courrir
Z -> arme secondaire
echap -> menu fin de partie

Lien : http://zelda.sujets-libres.fr
L'accès est ouvert en lecture à tout le monde mais je serais quand même heureux de connaître les personnes que ça intéresse (via ce topic ou par MP).

Merci aux volontaires et à leurs retours !

richardgilbert · Le 16/12/2012, à 21:54

Bonsoir;
Je suis intéressé mais je vais revenir vers toi les derniers jours de l'année ou les premières du 2013.
A+

londumas · Le 17/12/2012, à 02:23

Je vais jeter un coup d’œil.
Je suis sous Quantal.

mon ordi : mémoir : 3.8 Gb
procésseur : Intel® Pentium(R) CPU B950 @ 2.10GHz × 2
os : 64 bits

Merci pour ton travail

londumas · Le 17/12/2012, à 02:32

1er impression.
Ton dossier "ActionRPG" est rempli de fichiers et il n'y a pas de "README.txt" ni de "LICENCE.txt".
Pour plus de lisibilité met tous ces fichiers dans un ou plusieurs dossier si c'est possible (et ça doit l'être normalement)
Essaye de créer un "README.txt" dans lequel tu rappelle les dépendances à avoir pour jouer, les instructions si il faut compiler et les instructions pour jouer : commandes...
Essaye de créer un "LICENCE.txt" dans lequel tu donne la licence avec laquelle tu publie ton boulot et tu peux également donner un e-mail pour te contacter.

Je te donne des nouvelles dès que je teste.

Merci pour ton travail, et ton partage

londumas · Le 17/12/2012, à 03:24

Bon j'obtiens le message d'erreur suivant :

./ActionRPG: error while loading shared libraries: libSDL_gfx.so.13: cannot open shared object file: No such file or directory

Il me manque donc des dépendances.
Peux tu lister les paquets à installer ?

Merci

diabolos29 · Le 17/12/2012, à 06:58

Bonjour,

Est-ce que tu as installé la librairies SDL gfx ?

Concernant les fichiers README et LICENCE, ce sera fait en temps voulu.
A défaut, les informations du README sont dans mon premier message.
Et puisque que ce n'est pas précisé, mon code source sera sous GPL v3.

Merci à vous, j'attends vos retours !

wido · Le 17/12/2012, à 07:45

Abonnement,
je le testerai une prochaine fois.

Archlinux rolling release 64bits nvidia 8800 GTS intel Q9450, 4Go en ram.

londumas · Le 17/12/2012, à 08:39

ma version est "libsdl-gfx1.2-4". Es-ce la bonne ? Quelle est la tienne ?
Le problème peut venir de ta compilation. Si elle n'a pas était faite avec la même version ("libsdl-gfx1.2-4" pour moi). C'est ce que j'ai trouvé sur le web.
Quand pense tu ?

bishop · Le 17/12/2012, à 08:56

Salut !
J'ai supprimé mon message d'erreur (j'aurai pas dû) parce que je n'avais pas fait le make.
Maintenant l'interface se lance sans problème.

bishop@JC:~/ActionRPG$ ./ActionRPG 
20
quete1 0
quete2 0
num epee 1
num arc 0
grappin 0
bombe 0
feu 0
glace 0
lampe 0
marteau 1
palme 0
num gant 0
flacon 1 0
flacon 2 0
flacon 3 0
3
quete1 0
quete2 0
num epee 1
num arc 0
grappin 0
bombe 0
feu 0
glace 0
lampe 0
marteau 0
palme 0
num gant 0
flacon 1 0
flacon 2 0
flacon 3 0
7
quete1 0
quete2 0

du Mas des Bourboux écrit :
ma version est "libsdl-gfx1.2-4". Es-ce la bonne ? Quelle est la tienne ?
Le problème peut venir de ta compilation. Si elle n'a pas était faite avec la même version ("libsdl-gfx1.2-4" pour moi). C'est ce que j'ai trouvé sur le web.
Quand pense tu ?

N'oublie pas qu'il faut installer les librairies de développement (.dev)
En ce qui me concerne:

libsdl-gfx1.2-4, libsdl-gfx1.2-dev
libsdl-image1.2, libsdl-image1.2-dev
libsdl1.2debian, libsdl1.2-dev

Je testerai un peu plus tard...

Ubuntu Precise 12.04, Intel Core i7 980, 6GB DDR3, CG EVGA GTX580.

Dernière modification par bishop (Le 17/12/2012, à 09:03)

londumas · Le 17/12/2012, à 09:43

Je pense avoir compris le problème.
Je suis sous 64 bits.
j'ai fait un

locate libSDL

et ça me donne :

/usr/lib/i386-linux-gnu/libSDL-1.2.so.0
/usr/lib/i386-linux-gnu/libSDL-1.2.so.0.11.4
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0.11.4
/usr/lib/x86_64-linux-gnu/libSDL.a
/usr/lib/x86_64-linux-gnu/libSDL.so
/usr/lib/x86_64-linux-gnu/libSDL_gfx.so.13
/usr/lib/x86_64-linux-gnu/libSDL_gfx.so.13.9.1
/usr/lib/x86_64-linux-gnu/libSDL_gfx.so.4
/usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0
/usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0.8.4
/usr/lib/x86_64-linux-gnu/libSDL_image.a
/usr/lib/x86_64-linux-gnu/libSDL_image.so
/usr/lib/x86_64-linux-gnu/libSDL_mixer-1.2.so.0
/usr/lib/x86_64-linux-gnu/libSDL_mixer-1.2.so.0.12.0
/usr/lib/x86_64-linux-gnu/libSDL_mixer.a
/usr/lib/x86_64-linux-gnu/libSDL_mixer.so
/usr/lib/x86_64-linux-gnu/libSDL_ttf-2.0.so.0
/usr/lib/x86_64-linux-gnu/libSDL_ttf-2.0.so.0.10.1
/usr/lib/x86_64-linux-gnu/libSDL_ttf.a
/usr/lib/x86_64-linux-gnu/libSDL_ttf.so
/usr/lib/x86_64-linux-gnu/libSDLmain.a

J'ai créer un lien symbolique pour libSDL_gfx.so.13 via :

sudo ln -s /usr/lib/x86_64-linux-gnu/libSDL_gfx.so.13 /usr/lib/libSDL_gfx.so.13

et maintenant cela donne ça :

error while loading shared libraries: libSDL_gfx.so.13: wrong ELF class: ELFCLASS64

Peux tu donner ton fichier à compiler avec les instructions de compilation ?

bishop · Le 17/12/2012, à 11:23

Moi aussi je suis en 64 bits.
Je reposte mon message d'erreur avant d'avoir fait le make...

bishop@JC:~/ActionRPG$ ./ActionRPG 
./ActionRPG: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory

Du coup j'avais créé ce lien symbolique :

bishop@JC:~/Bureau$ sudo ln -s /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 /usr/lib/libSDL-1.2.so.0

Puis relancé la commade :

bishop@JC:~/ActionRPG$ ./ActionRPG
./ActionRPG: error while loading shared libraries: libSDL-1.2.so.0: wrong ELF class: ELFCLASS64

Mais comme dit plus haut j'ai fait le make et tout est rentré dans l'ordre.

bishop@JC:~/ActionRPG$ make
g++    -c -o main.o main.cpp
g++    -c -o Ami.o Ami.cpp
g++    -c -o Arme.o Arme.cpp
g++    -c -o Audio.o Audio.cpp
g++    -c -o Carte.o Carte.cpp
g++    -c -o Clavier.o Clavier.cpp
g++    -c -o DeroulementPartie.o DeroulementPartie.cpp
g++    -c -o Donjon.o Donjon.cpp
g++    -c -o Ennemi.o Ennemi.cpp
g++    -c -o Entite.o Entite.cpp
g++    -c -o Generique.o Generique.cpp
g++    -c -o Hero.o Hero.cpp
g++    -c -o ImagesPartie.o ImagesPartie.cpp
g++    -c -o Menu.o Menu.cpp
g++    -c -o Jeu.o Jeu.cpp
g++    -c -o Objet.o Objet.cpp
g++    -c -o ObjetRecolte.o ObjetRecolte.cpp
g++    -c -o Personnage.o Personnage.cpp
g++    -c -o Pnj.o Pnj.cpp
g++    -c -o Projectile.o Projectile.cpp
g++    -c -o SelectionPartie.o SelectionPartie.cpp
g++    -c -o Statut.o Statut.cpp
g++    -c -o Texte.o Texte.cpp
g++ -o ActionRPG main.o Ami.o Arme.o Audio.o Carte.o Clavier.o DeroulementPartie.o Donjon.o Ennemi.o Entite.o Generique.o Hero.o ImagesPartie.o Menu.o Jeu.o Objet.o ObjetRecolte.o Personnage.o Pnj.o Projectile.o SelectionPartie.o Statut.o Texte.o -lSDL -lSDL_gfx -lSDL_image

Si je fais un locate :

locate libSDLbishop@JC:~/Bureau$ locate libSDL
/usr/lib/libSDL_sound-1.0.so.1
/usr/lib/libSDL_sound-1.0.so.1.0.2
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0.11.3
/usr/lib/x86_64-linux-gnu/libSDL_gfx.so.13
/usr/lib/x86_64-linux-gnu/libSDL_gfx.so.13.9.1
/usr/lib/x86_64-linux-gnu/libSDL_gfx.so.4
/usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0
/usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0.8.2
/usr/lib/x86_64-linux-gnu/libSDL_mixer-1.2.so.0
/usr/lib/x86_64-linux-gnu/libSDL_mixer-1.2.so.0.10.1
/usr/lib/x86_64-linux-gnu/libSDL_ttf-2.0.so.0
/usr/lib/x86_64-linux-gnu/libSDL_ttf-2.0.so.0.6.3

: --- : --- : --- :

du Mas des Bourboux écrit :
Peux tu donner ton fichier à compiler avec les instructions de compilation ?

Tu veux le makefile ?
Il est dans le dossier ActionRPG.

CC=g++
CFLAGS=-W -Wall -ansi -pedantic
LDFLAGS=-lSDL -lSDL_gfx -lSDL_image
EXEC=ActionRPG
SRC= main.cpp Ami.cpp Arme.cpp Audio.cpp Carte.cpp Clavier.cpp DeroulementPartie.cpp Donjon.cpp Ennemi.cpp Entite.cpp Generique.cpp Hero.cpp ImagesPartie.cpp Menu.cpp Jeu.cpp Objet.cpp ObjetRecolte.cpp Personnage.cpp Pnj.cpp Projectile.cpp SelectionPartie.cpp Statut.cpp Texte.cpp
OBJ= $(SRC:.cpp=.o)

all: $(EXEC)
ActionRPG: $(OBJ)
$(CC) -o $@ $^ $(LDFLAGS)
%.o: %.c
$(CC) -o $@ -c $< $(CFLAGS)
.PHONY: clean mrproper
clean:
rm *.o
mrproper: clean
rm $(EXEC)

Ubuntu Precise 12.04, Intel Core i7 980, 6GB DDR3, CG EVGA GTX580.

Dernière modification par bishop (Le 17/12/2012, à 13:37)

londumas · Le 17/12/2012, à 11:51

Merci bishop.

Je viens de faire le "make" et ça fonctionne.

On arrive sur un écran avec rien d'écris et on peut choisir trois cases : la premiere il y a plein de coeur, la seconde pas beaucoup et la troisième un eu plus.

Je vais tester.

Merci

bishop · Le 17/12/2012, à 14:20

diabolos29 !
Je viens de faire un p'tit test pour voir de quoi il retourne. Premier test :

bishop@JC:~/Bureau$ top

top - 13:47:33 up  2:45,  3 users,  load average: 0.54, 0.45, 0.51
Tasks: 242 total,   2 running, 238 sleeping,   0 stopped,   2 zombie
Cpu(s):  3.8%us,  1.3%sy,  0.0%ni, 94.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   6104104k total,  1821452k used,  4282652k free,    81612k buffers
Swap:  6291452k total,        0k used,  6291452k free,   615428k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                
 4457 bishop    20   0  120m  23m 4872 R   24  0.4   0:12.57 ActionRPG

Second test :

bishop@JC:~/Bureau$ top

top - 14:08:14 up  3:06,  3 users,  load average: 0.52, 0.65, 0.66
Tasks: 243 total,   2 running, 239 sleeping,   0 stopped,   2 zombie
Cpu(s):  4.2%us,  1.2%sy,  0.0%ni, 94.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   6104104k total,  2235792k used,  3868312k free,    96952k buffers
Swap:  6291452k total,        0k used,  6291452k free,   888540k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                
 6743 bishop    20   0  120m  23m 4908 R   23  0.4   1:33.48 ActionRPG

Pas de problème avec le dialogue (bulle Lorem Ipsum....). Je me suis balladé à l'extérieur puis dans les salles. Dans l'une d'elle j'ai combattu "les p'tits monstres"...
Sur ma distrib le jeu est fluide et les commandes que tu proposes sont fonctionnelles.

Ubuntu Precise 12.04, Intel Core i7 980, 6GB DDR3, CG EVGA GTX580.

Dernière modification par bishop (Le 17/12/2012, à 15:00)

londumas · Le 17/12/2012, à 14:44

1er teste

helion@helion-PC:~$ top

top - 20:33:42 up  5:32,  2 users,  load average: 0,72, 0,74, 0,55
Tasks: 190 total,   3 running, 185 sleeping,   0 stopped,   2 zombie
%Cpu(s): 25,6 us,  4,0 sy,  0,0 ni, 69,0 id,  1,3 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:   3947384 total,  2531212 used,  1416172 free,   144124 buffers
KiB Swap:   999420 total,        0 used,   999420 free,  1238536 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND           
14761 helion    20   0  131m  23m 4872 R  33,9  0,6   1:25.68 ActionRPG

2nd teste

helion@helion-PC:~$ top

top - 20:35:37 up  5:34,  2 users,  load average: 0,53, 0,67, 0,55
Tasks: 191 total,   2 running, 187 sleeping,   0 stopped,   2 zombie
%Cpu(s):  9,6 us,  2,7 sy,  0,0 ni, 86,4 id,  1,2 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:   3947384 total,  2529264 used,  1418120 free,   144272 buffers
KiB Swap:   999420 total,        0 used,   999420 free,  1243208 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND           
15007 helion    20   0  131m  23m 4856 S  38,8  0,6   0:02.74 ActionRPG

Sinon question gameplay.
Les graphismes sont pas mal, l’interaction avec les ennemis est très bonne. L’interaction avec les obstacles est un peu crevant car le perso se décale tout seul.
Les commandes sont très bonnes, très bonne idée la touche courir.
Je ne sais pas si c'est par ce que j'ai du faire "make". Mais le menu n'a pas d'explication, je n'ai pas réussi à sauver une partie. Quand je suis mort j'ai du éteindre et recommencer.
Le perso dans la maison parle un espèce de latin, es ce normal ?

Enfin et le plus important, les mouvements du héros sont super. Quand il cours, on s'y croirai.

Bon courage pour la suite

diabolos29 · Le 17/12/2012, à 17:22

Merci à vous deux pour vos premier retours.
Bon, je vois qu'une fois recompilé, tout est rentré dans l'ordre. Je ferai quelque chose de clair dans le README à ce sujet.

L’interaction avec les obstacles est un peu crevant car le perso se décale tout seul.

C'est à dire ?
L'idée, c'est que comme il est frustrant d'être bloqué car on est décalé de quelques pixels par rapport au passage, là, c'est le moteur de collisions qui prend le relais et qui fait le petit ajustement qui va bien.

Concernant vos autres commentaires, une fois le jeu lancé :
- L'absence de texte dans le premier écran est normale car je n'ai pas encore trop travaillé cette partie (cet écran permet simplement de sélectionner le bon fichier de sauvegarde parmi les 3 possibles).
- Après la mort du perso, pour le moment il ne se passe rien. Qu'il n'y ai pas de sauvegarde de proposée à ce moment là, ça me semble normal (ça obligera à repartir à la dernière sauvegarde). Ceci dit, il faudra que je rajoute un retour au menu de départ dans ce cas là.
- Le PNJ dans la maison, je lui ai donné comme texte un lorem ipsum juste pour tester l'affichage de dialogue long.
- Pour les graphismes, ce ne sont pas les miens mais ceux tirés de Zelda 3 (sur SNES, le jeu est sorti il y a déjà plus de 20 ans). J'ai à un moment pensé faire mes propres graphismes mais c'est un travail qui demande beaucoup de temps et de très bonnes compétences (j'ai d'ailleurs perdu deux mois en pensant que j'y arriverais). La licence GPL v3 ne s'appliquera pas à ces ressources là. Peut être qu'à terme (lorsque le jeu sera fonctionnel), je pourrai convaincre un bon graphiste de travailler dessus pour en faire un truc totalement libre.

Dernière modification par diabolos29 (Le 17/12/2012, à 18:40)

diabolos29 · Le 21/12/2012, à 10:26

Afin de motiver les curieux, voilà une petite vidéo (je viens aussi de mettre l'archive à jour) : http://www.youtube.com/watch?v=JbuK_gNc … e=youtu.be

wido · Le 22/12/2012, à 18:35

Je ne suis pas expert regarde ces sites:
http://opengameart.org/
http://freegamedev.net/wiki/Art_asset_resources
http://doc.ubuntu-fr.org/developpement_de_jeux_video

diabolos29 · Le 22/12/2012, à 18:45

J'ai passé pas mal de temps à regarder les ressources dispo sur opengameart.org mais je n'ai pas trouvé mon bonheur.
Dans le même genre, j'ai aussi pensé reprendre les ressources de BrowserQuest mais j'ai renoncé aussi (même si la licence de ce jeu est compatible avec le GPL).

Pour le moment en fait, j'ai préféré me concentrer sur le dev. C'est vraiment la partie qui m'intéresse et dans laquelle je veux progresser.

wido · Le 22/12/2012, à 18:53

Plus tard quand le jeu sera mature, je l'exporterai sous Archlinux (A.U.R)

chaoswizard · Le 28/12/2012, à 23:52

Ma contribution :

ça pourrait être bien d'ajouter l'option -f dans les options de clean du Makefile,
la ligne de compilation des fichiers .cpp est fausse :
```
%.o: %.cpp
```
au lieu de
```
%.o: %.c
```

sans optimisations :

 PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                   
 4327 chaoswiz  20   0 69780  22m 3952 R  28,3  0,8   0:12.97 ActionRPG

avec optimisations (-O3) :

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                   
 6583 chaoswiz  20   0 69720  22m 3904 R  25,7  0,8   0:02.88 ActionRPG

dans tous les cas, l’utilisation CPU me parait absolument énorme, il doit y avoir un problème à quelque part !

au secours mon capitaine, ça fuit ! :

==6923== HEAP SUMMARY:
==6923==     in use at exit: 15,011,328 bytes in 3,852 blocks
==6923==   total heap usage: 27,575 allocs, 23,723 frees, 266,942,896 bytes allocated
==6923== 
==6923== 20 bytes in 2 blocks are definitely lost in loss record 354 of 1,886
==6923==    at 0x4C2C04B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6923==    by 0x5D94ED1: strdup (in /usr/lib/libc-2.16.so)
==6923==    by 0x69456D5: ??? (in /usr/lib/libX11.so.6.3.0)
==6923==    by 0x6946614: _XimSetICValueData (in /usr/lib/libX11.so.6.3.0)
==6923==    by 0x6941CBD: _XimLocalCreateIC (in /usr/lib/libX11.so.6.3.0)
==6923==    by 0x69281A2: XCreateIC (in /usr/lib/libX11.so.6.3.0)
==6923==    by 0x4E727AC: ??? (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E736E0: ??? (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E61D1A: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E3B20B: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E3B28B: SDL_Init (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E62A61: SDL_SetVideoMode (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923== 
==6923== 24 bytes in 1 blocks are definitely lost in loss record 378 of 1,886
==6923==    at 0x4C2C04B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6923==    by 0x7249A8D: ???
==6923==    by 0x7249524: ???
==6923==    by 0x724989C: ???
==6923==    by 0x7249CC1: ???
==6923==    by 0x7244498: ???
==6923==    by 0x4E737C4: ??? (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E61D1A: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E3B20B: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E3B28B: SDL_Init (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E62A61: SDL_SetVideoMode (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4024FD: main (main.cpp:32)
==6923== 
==6923== 192 (16 direct, 176 indirect) bytes in 1 blocks are definitely lost in loss record 1,484 of 1,886
==6923==    at 0x4C2C25E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6923==    by 0x692DC9E: ??? (in /usr/lib/libX11.so.6.3.0)
==6923==    by 0x692E155: ??? (in /usr/lib/libX11.so.6.3.0)
==6923==    by 0x692F904: ??? (in /usr/lib/libX11.so.6.3.0)
==6923==    by 0x6930095: _XlcCreateLC (in /usr/lib/libX11.so.6.3.0)
==6923==    by 0x694C7AF: _XlcDefaultLoader (in /usr/lib/libX11.so.6.3.0)
==6923==    by 0x693736D: _XOpenLC (in /usr/lib/libX11.so.6.3.0)
==6923==    by 0x69374B7: _XlcCurrentLC (in /usr/lib/libX11.so.6.3.0)
==6923==    by 0x693750D: XSetLocaleModifiers (in /usr/lib/libX11.so.6.3.0)
==6923==    by 0x4E7290B: ??? (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E736E0: ??? (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E61D1A: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923== 
==6923== 932,840 bytes in 1 blocks are possibly lost in loss record 1,880 of 1,886
==6923==    at 0x4C2C25E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6923==    by 0x4E48904: ??? (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E4969E: ??? (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E5EEA7: SDL_LowerBlit (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E5F11E: SDL_UpperBlit (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x403F64: Carte::afficherCarte(SDL_Surface*, SDL_Surface*, SDL_Surface*, SDL_Surface*, SDL_Surface*, position**, int, int) (Carte.cpp:242)
==6923==    by 0x41F406: DeroulementPartie::afficherPartieEnCours(SDL_Surface*, bool*) (DeroulementPartie.cpp:204)
==6923==    by 0x433972: Jeu::miseAJour(SDL_Surface*, bool*) (Jeu.cpp:76)
==6923==    by 0x4025C0: main (main.cpp:51)
==6923== 
==6923== 952,320 bytes in 1 blocks are possibly lost in loss record 1,881 of 1,886
==6923==    at 0x4C2C04B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6923==    by 0x4E5FB0A: SDL_CreateRGBSurface (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E5FC7B: SDL_ConvertSurface (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x428FD4: ImagesPartie::chargerImage(std::string) (ImagesPartie.cpp:47)
==6923==    by 0x43721E: SelectionPartie::SelectionPartie() (SelectionPartie.cpp:76)
==6923==    by 0x4336B2: Jeu::Jeu() (Jeu.cpp:26)
==6923==    by 0x40256A: main (main.cpp:42)
==6923== 
==6923== 952,320 bytes in 1 blocks are possibly lost in loss record 1,882 of 1,886
==6923==    at 0x4C2C04B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6923==    by 0x4E5FB0A: SDL_CreateRGBSurface (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x4E5FC7B: SDL_ConvertSurface (in /usr/lib/libSDL-1.2.so.0.11.4)
==6923==    by 0x428FD4: ImagesPartie::chargerImage(std::string) (ImagesPartie.cpp:47)
==6923==    by 0x43727B: SelectionPartie::SelectionPartie() (SelectionPartie.cpp:77)
==6923==    by 0x4336B2: Jeu::Jeu() (Jeu.cpp:26)
==6923==    by 0x40256A: main (main.cpp:42)
==6923== 
==6923== 12,113,047 (40 direct, 12,113,007 indirect) bytes in 1 blocks are definitely lost in loss record 1,886 of 1,886
==6923==    at 0x4C2BA77: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6923==    by 0x40255F: main (main.cpp:42)
==6923== 
==6923== LEAK SUMMARY:
==6923==    definitely lost: 100 bytes in 5 blocks
==6923==    indirectly lost: 12,113,183 bytes in 2,978 blocks
==6923==      possibly lost: 2,837,480 bytes in 3 blocks
==6923==    still reachable: 60,565 bytes in 866 blocks
==6923==         suppressed: 0 bytes in 0 blocks

Il y a beaucoup de new mais aucun delete (de même, les fonctions SDL pour libérer les ressources ne sont jamais appelées)...
N.B. : il n'y a pas de garbage collector en C++ !!!
De manière général, il y a beaucoup d'allocations dynamiques là où elles n'ont pas lieux d'être !
(tu es un programmeur Java à la base ? (ce n'est pas une critique, mais cela expliquerait des choses))

il existe déjà plusieurs Zelda dans ce genre (qui sont libres) ; ça peut te servir !
les graphismes et le moteur semblent bons,
si tu veux d'autres tests, n'hésites pas !
Zelda, c'est bien !

Ma config :

Archlinux 64 bits,
Intel(R) Core(TM)2 Duo CPU T6670 @ 2.20GHz,
3 Gio de Ram.

++

Dernière modification par chaoswizard (Le 29/12/2012, à 12:47)

diabolos29 · Le 29/12/2012, à 09:24

Bonjour et merci de ton retour.

C'est vu pour le Makefile et effectivement, ce n'était pas bon.

Pour ce qui est de la consommation CPU, je trouve aussi que c'est énorme et pourtant, j'ai déjà travaillé à la réduire. Je ne sais pas si j'y peut encore grand chose.
En fait, c'est dû presque essentiellement à la fonction SDL_BlitSurface. Le jeu tourne à 50fps et utilise 3 cartes superposées (sol + collision + air). C'est aussi pour ça que je voulais des retours sur la consommation du jeu sur diverses configs.
Ces cartes sont optimisées par mon éditeur de cartes. Par exemple, si une tuile de la couche collision est totalement opaque, la tuile de la couche de sol correspondante est remplacée par un tuile transparente. Lorsque le jeu détecte une tuile transparente sur l'une des cartes, il ne la traite pas (la quasi totalité des tuiles de la carte air sont transparentes). Côté FPS, c'est géré en dur par ça (là, ça évite de bouffer toutes les ressources CPU) :

        do
        {
            tempsActuel = SDL_GetTicks();
            SDL_Delay(4);
        }
        while(tempsActuel<tempsPrecedent+(950/fps));
        tempsPrecedent = tempsActuel;

A titre de comparaison, chez moi, Zelda ROTH consomme 18% de CPU contre 28% pour le jeu que je développe. C'est sans doutes perfectible mais ce n'est si déconnant que ça quand même (enfin... je pense).

Je ne connaissait pas l'outil valgrind. Par contre, je n'arrive pas à reproduire les erreurs que tu me signale. Est-ce que tu pourrais me préciser comment tu y arrives ?

08:54:15 fred@obelix:~/Documents/Projets-code::blocks/ActionRPG$ valgrind ./ActionRPG --leak-check=full

==2653== HEAP SUMMARY:
==2653==     in use at exit: 14,979,697 bytes in 3,851 blocks
==2653==   total heap usage: 24,665 allocs, 20,814 frees, 193,198,936 bytes allocated
==2653== 
==2653== LEAK SUMMARY:
==2653==    definitely lost: 56 bytes in 5 blocks
==2653==    indirectly lost: 2,847,380 bytes in 1,809 blocks
==2653==      possibly lost: 12,085,491 bytes in 1,177 blocks
==2653==    still reachable: 46,770 bytes in 860 blocks
==2653==         suppressed: 0 bytes in 0 blocks
==2653== Rerun with --leak-check=full to see details of leaked memory
==2653== 
==2653== For counts of detected and suppressed errors, rerun with: -v
==2653== Use --track-origins=yes to see where uninitialised values come from
==2653== ERROR SUMMARY: 2369 errors from 18 contexts (suppressed: 0 from 0)

Sinon, je suis un piètre programmeur Java à la base et autodidacte en C++ .

Dernière modification par diabolos29 (Le 29/12/2012, à 10:18)

chaoswizard · Le 29/12/2012, à 11:34

Manque de bol, je ne connais pas vraiment la SDL, donc ça va être dur de t'aider précisément :S
Dans l'idée, toutes les ressources sont rafraichies toutes les 1/50 de secondes, même s'il ne se passe rien ?
C'est peut être ça le problème non ? Si aucune action n'est faite, il devrait n'y avoir qu'une faible conso CPU vu que rien ne change, non ?

A titre de comparaison, chez moi, Zelda ROTH consomme 18% de CPU contre 28% pour le jeu que je développe. C'est sans doutes perfectible mais ce n'est si déconnant que ça quand même (enfin... je pense).

Après, ROTH n'est peut être pas parfait non plus...

Je ne connaissait pas l'outil valgrind. Par contre, je n'arrive pas à reproduire les erreurs que tu me signale. Est-ce que tu pourrais me préciser comment tu y arrives ?

Il faut compiler avec le flag de debug (et sans optimisations) :

CFLAGS=-W -Wall -ansi -pedantic -g

puis lancer valgrind :

valgrind ./ActionRPG

Toutes les options supplémentaires nécessaires sont ensuite proposées par valgrind comme :

valgrind --track-origins=yes --leak-check=full ./ActionRPG

Attention, au lancement avec valgrind, ça rame sévère ! (et c'est normal !)

Sinon, je suis un piètre programmeur Java à la base et autodidacte en C++

Je te conseille de corriger ce problème de fuite mémoire avant de continuer (une fois que le code est trop gros, ça peut devenir compliqué).
Tu as groso modo quatre concepts à comprendre ou mettre en place :

contrairement à Java, tu n'as pas forcement besoin de créer un objet avec new : par exemple, dans ta classe DeroulementPartie, tu peux très bien créer de manière statique les instances des classes Carte, Clavier, ...
```
class DeroulementPartie : public ImagesPartie
{
	...
	
	private:
		Carte map;
		Clavier clav;
	
	...
};
```
si tu fais un new, tu dois faire un delete (dans le destructeur par exemple). Dans la SDL, il doit y avoir des new (ou des malloc) "cachés", et tu dois appeler les fonctions signalées dans la doc pour libérer les ressources (comme SDL_VideoQuit quand tu utilises SDL_VideoInit)
tu peux passer les objets en paramètres des fonctions par référence (voir ici)
si tu dois vraiment gérer des pointeurs, que le même pointeur est utilisé à plusieurs endroits dans le code et que tu n'as strictement aucune idée de quand rendre la mémoire, tu peux laisser "quelqu'un" gérer ça pour toi (voir ici)

++

Dernière modification par chaoswizard (Le 29/12/2012, à 17:02)

diabolos29 · Le 30/12/2012, à 21:39

Fuites mémoire corrigées (essentiellement dûes à des SDL_FreeSurface ou des delete manquant effectivement).

Il me reste ceci mais ça semble être propre à la SDL :

==3276== HEAP SUMMARY:
==3276==     in use at exit: 47,014 bytes in 872 blocks
==3276==   total heap usage: 23,141 allocs, 22,269 frees, 68,981,121 bytes allocated
==3276== 
==3276== 20 bytes in 2 blocks are definitely lost in loss record 13 of 123
==3276==    at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3276==    by 0x42D0AF0: strdup (strdup.c:43)
==3276==    by 0x50526E6E: ???
==3276== 
==3276== 112 (8 direct, 104 indirect) bytes in 1 blocks are definitely lost in loss record 100 of 123
==3276==    at 0x402BF52: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3276==    by 0x45AD7B6: ??? (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45ADCB2: ??? (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45AF75F: ??? (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45AFFEA: _XlcCreateLC (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45CEF59: _XlcDefaultLoader (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45B7E3B: _XOpenLC (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45B80BA: _XrmInitParseInfo (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x459E6BD: ??? (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45A22A4: XrmGetStringDatabase (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x457DE0A: ??? (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x457E026: XGetDefault (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276== 
==3276== 112 (8 direct, 104 indirect) bytes in 1 blocks are definitely lost in loss record 101 of 123
==3276==    at 0x402BF52: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3276==    by 0x45AD7B6: ??? (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45ADCB2: ??? (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45AF75F: ??? (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45AFFEA: _XlcCreateLC (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45CEF59: _XlcDefaultLoader (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45B7E3B: _XOpenLC (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x45B7FA1: _XlcCurrentLC (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==3276==    by 0x4093E4B: ??? (in /usr/lib/i386-linux-gnu/libSDL-1.2.so.0.11.3)
==3276==    by 0x4081D18: SDL_VideoInit (in /usr/lib/i386-linux-gnu/libSDL-1.2.so.0.11.3)
==3276==    by 0x4056269: SDL_InitSubSystem (in /usr/lib/i386-linux-gnu/libSDL-1.2.so.0.11.3)
==3276==    by 0x40562EA: SDL_Init (in /usr/lib/i386-linux-gnu/libSDL-1.2.so.0.11.3)
==3276== 
==3276== LEAK SUMMARY:
==3276==    definitely lost: 36 bytes in 4 blocks
==3276==    indirectly lost: 208 bytes in 8 blocks
==3276==      possibly lost: 0 bytes in 0 blocks
==3276==    still reachable: 46,770 bytes in 860 blocks
==3276==         suppressed: 0 bytes in 0 blocks
==3276== Reachable blocks (those to which a pointer was found) are not shown.
==3276== To see them, rerun with: --leak-check=full --show-reachable=yes
==3276== 
==3276== For counts of detected and suppressed errors, rerun with: -v
==3276== ERROR SUMMARY: 3469 errors from 47 contexts (suppressed: 0 from 0)

Je ferai une mise à jour de l'archive ce soir...

chaoswizard · Le 30/12/2012, à 22:04

Ok pour les autres libérations.
Il faudrait (si tu es joueur), prendre les dernières versions des librairies et les compiler en debug pour voir d'où viennent les fuites restantes.

Tu as avancé sur le "problème" de l'utilisation CPU ?

Dernière modification par chaoswizard (Le 30/12/2012, à 22:07)

diabolos29 · Le 30/12/2012, à 22:52

A ce que j'ai compris, la SDL utilise le CPU et non le GPU pour les calculs (contrairement à SFML ou OpenGL). C'est ce qui explique ce type de perfs et la réputation qui accompagne cette lib.
Tout est effectivement rafraîchit 50x / s, peu importe ce qu'il se passe.

Je vois en gros deux possibilités :
- soit SDL_Flip(fenetre); mise à jour de l'écran à intervalles réguliers (ce que je fais actuellement, qui est la méthode "classique" avec la SDL).
- soit j'empile les sprites qui changent là où il faut (animations automatiques, pnj, perso, texte...) et je fait uniquement mon SDL_Flip(fenetre); lorsque j'ai tout l'écran à mettre à jour en même temps.

Sur le papier, la seconde solution semble mieux mais j'ai bien peur que ce soit en fait un beau bordel à gérer pour un gain limité en terme de performance. Ceci dit, je la testerai peut être sur projet plus simple (type tétris) juste pour voir de quel ordre est le gain de performances.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 16/12/2012, à 10:07

Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#2 Le 16/12/2012, à 21:54

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#3 Le 17/12/2012, à 02:23

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#4 Le 17/12/2012, à 02:32

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#5 Le 17/12/2012, à 03:24

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#6 Le 17/12/2012, à 06:58

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#7 Le 17/12/2012, à 07:45

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#8 Le 17/12/2012, à 08:39

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#9 Le 17/12/2012, à 08:56

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#10 Le 17/12/2012, à 09:43

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#11 Le 17/12/2012, à 11:23

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#12 Le 17/12/2012, à 11:51

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#13 Le 17/12/2012, à 14:20

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#14 Le 17/12/2012, à 14:44

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#15 Le 17/12/2012, à 17:22

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#16 Le 21/12/2012, à 10:26

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#17 Le 22/12/2012, à 18:35

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#18 Le 22/12/2012, à 18:45

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#19 Le 22/12/2012, à 18:53

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#20 Le 28/12/2012, à 23:52

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#21 Le 29/12/2012, à 09:24

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#22 Le 29/12/2012, à 11:34

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#23 Le 30/12/2012, à 21:39

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#24 Le 30/12/2012, à 22:04

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

#25 Le 30/12/2012, à 22:52

Re : Cherche testeurs pour moteur de jeu Action RPG type Zelda 3

Pied de page des forums