Malgré un smashed stack detected (flippe garantie) - corrigé - voici l'avancée du jeu.
Il reste :
- à augmenter le nombre de voiture stationnée
- changer les graphismes
- voir comment on fait si on termine un niveau
Malgré un smashed stack detected (flippe garantie) - corrigé - voici l'avancée du jeu.
Il reste :
- à augmenter le nombre de voiture stationnée
- changer les graphismes
- voir comment on fait si on termine un niveau
Bonsoir.
Enfin! La mécanique du jeu original est respectée. Il faut faire quelques améliorations, car tel quel, c'est trop difficile. Je n'ai même pas réussi à finir le niveau!
voici le lien vers la video et les sources.
J'avais oublié de libérer la mémoire de mon image TGA chargée au début.
Du coup, lorsque je le fais, je me retrouve avec -320 (moins 320) octets qui n'ont pas été libérés...
Aucun idée de pourquoi.
Le jeu ne ralentit pas, c'est juste que j'ai adapté la vitesse des voitures à celle du personnage. D du coup, celà devient jouable.
Alors j'ai testé ton jeu et voici je que j'en conclu :
Tu as mis les vitesses pour gérer les collisions c'est bien.
Les évents sont dans un tableau , c'est bien aussi.
La programmation me semble modulaire (fonction / structure , pas de variable global).
Le moins serait :
Je n'aime pas ton indentation du code.
Le jeu a 2 gros défaut techniques :
Il utilise beaucoup beaucoup trop de mémoire RAM (sur mon ordi je suis a 138 mo ) et en terme de CPU je suis a 30% , c'est beaucoup trop pour ce que tu fait....
En comparaison j'avais fait un jeu 3D (et j’utilisais très peu la carte graphique , collision 3D , animation par squelette cote CPU) ben le jeu me coûte 5% de cpu et 28 mo , un jeu 2D me coûte 4% de CPU et 17 mo.
L'autre point sur mon ordi , j'ai l'impression que ton jeu ralenti quelque fois...
Je conclurai que optimiser son code pour ma part cela a était formateur pour moi (enfin optimiser dans le sens penser a faire un jeu en utilisant le moins de ressource possible) , je te conseille apres avoir fini ton jeu , a pense a utiliser le moins de calcul et de ressource.
hello!
moi aussi je suis à 138 Mo de mémoire.
Par contre 7% cpu.
Je n'ai pour l'instant aucune idée de comment optimiser (j'ai déjà du mal à régler des problèmes de base).
Par exemple quel serait le moyen de diminuer la mémoire utilisée?
Pour le % cpu cela dépend de la machine , mais en tout cas ton jeux consomme beaucoup trop de calcul pour ce qu'il fait (si tu as moins que moi c'est que tu as tout simplement une machine plus puissante que la mienne ).
(Si tu as un PC pas trop puissant sous la main je te conseille te tester ton jeu la dessus ! ).
Pour les ressources , ben cela dépend de tes malloc et autre fonction SDL qui charge en mémoire mais je vois pas comment avec ce que tu affiche que tu es a 138 mo pour être honnête...
Sinon un autre point la résolution peut jouer un rôle sur ces 2 paramètres (calcul et ressource) , je conseille de faire une résolution max de 640x480 avec la SDL 1 (par info c'est la résolution des jeux PS2,XBOX , GameCube , Dreamcast).
Si tu veux grossir ta résolution il est préférable de le faire coté CPU (je conseille d'utiliser OpenGL sur ce coup ).
Après j'avais eu la remarque que quelqu'un me disait que il ne visait pas les consoles quand je lui est fait remarqué que son jeu ne pouvait pas tenir sur une PSP ou PS2.
C'est un peu le cas de ton jeu il ne pourrait même pas tourner sur une telle machine :/
Pour tes souci de base , je devrait lire plus attentivement ton code , mais c'est un peu le souci de ce qu'il font du jeu vidéo en C , il faut plus se soucier de l'efficacité de son code que tu résultat.
Je trouve que ton projet est intéressant pour toi , il te permet de voir toute la difficulté de faire un jeu aussi 'basic' pour ma part c'est justement a cause de ces difficultés quand j'ai était étudiant que j'ai commencé sérieusement a être très méthodique sur mon code a me soucier de l'efficacité de mes fonctions que du résultat obtenu (je parle ici en terme de jeux , je prefere avoir un truc pas fini mais sans bug et optimisé que l'inverse ).
En général quand on a du mal a modifier le code source c'est que le code a atteint ces limites il faut repenser son architecture !
Donc si tu pense pouvoir finir ton jeu fait le , tu pourra la prochaine fois comprendre et prédire les prochaines difficulté , moi je te conseillerai au prochain projet de repartir a zéro , de faire chaque fonction petit a petit jusqu'a elle te semble fiable , modulaire (j'avais deja dit ici la liste de ce que tu devrait faire pour un jeux vidéo même minimaliste ).
J'ai essayé de build et lancer ton projet sur une machine avec MSYS2 sous Windows 7, depuis l'archive que tu as postée un peu plus haut. Je ne suis pas sûr d'avoir la dernière version.
Rien que ça, je ne vois pas comment ça peut passer :
En corrigeant quelques trucs à l'initialisation, ça segfault plus loin au chargement d'un tileset. Pense à nettoyer la mémoire : tu appelles SDL_Quit mais je n'ai pas constaté la destruction de ton objet « niveau », à moins que ce soit fait par une callback ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 Map* m; m->screen = SDL_SetVideoMode(800,600,32,SDL_HWSURFACE|SDL_DOUBLEBUF);
Un truc que je n'ai pas compris en adaptant le makefile : tu compiles en debug mais avec les optimisations activées. C'est un peu contradictoire. Écris deux targets à la limite, une pour chaque build. Demande également une norme et les avertissements supplémentaires : j'ai ajouté -std=c11 -pedantic -Wall -Wextra.
Comme il te l'a été suggéré, pense à confier ton projet à un hébergeur dédié : outre le contrôle de version, cela nous assure également à nous relecteurs de disposer de la dernière version du projet et de pouvoir te proposer des modifications pertinentes. GitLab, Github et compagnie sont tes amis. Ne push pas les fichiers binaires !
On pourrait peut-être renommer / forker le fil de discussion (« rotation d'ellipses ») ?
Je vois rien d'anormal a ce code , screen est une structure du type SDL_SURFACE (même si je conçois que 'm'' n'est pas forcément le meilleur nom choisi).
Cela fait un moment que ce post aurait du être séparer , je pense que la section SDL serait plus approprié !
Le projet est un peu bordélique (surtout que les .o j'ai du les supprimer pour pouvoir utiliser son Makefile) , pour le segfault c'est marrant , ça me rappel un copain qui avait le même probleme sur Windows on avait un segfault (et non sur Linux) , j'ai du lui dire je crois "Windows est un bon debuggeur ! "
Kannagi.. tu n'as pas les yeux en face des trous, relis mieux.
Je n'ai pas trop creusé les segfaults, il s'agit de ma machine de boulot qui n'est pas très clean et n'a probablement pas toutes les dépendances à jour. Si j'ai des corrections / suggestions à faire, je les écrirai depuis ma machine perso (Arch Linux).
au passage, je choisis l'option de terminer mon jeu même s'il n'est pas optimisé. Celà m'apprend les collisions, les files de priorité, les mouvements etc.
Peut être que la place mémoire RAM occupée vient du fait que je ne passe pas des pointeurs de SDL_Rect à mes fonctions, mais les SDL_Rect eux même.
Merci pour les conseils en tous cas, je vais me tenir à les suivre avec rigueur.
Les paramètres de fonction sont placés sur la pile, ce n'est pas cela qui entraîne une telle consommation de mémoire.
hello!
je poste dorénavant l'avancée du programme sur le forum SDL, mais, ayant été encouragé ici par Obsidian et Ternel, je ne résiste pas à la joie de poster à cet endroit la dernière avancée du jeu : je me suis permis une liberté par rapport au jeu original : je joueur peut profiter d'un refuge au commissariat, et si sa barre de vie est sous 50, il peut y ramasser un carnet de pv qui lui donne 50 pts de vie supplémentaires. Si sa vie est au dessus de 50, ramasser le carnet de pv n'a aucun effet.
Il s'agit toujours de traiter les collisions et de mettre un booléen à vrai ou faux selon que ces conditions testées sont vraies ou fausses.
Tu y prends goût et c'est une excellente chose ! Regarde où tu en es arrivé depuis le moment où tu as ouvert ce fil…
D'ailleurs, à ce propos, et si tu n'y vois pas d'inconvénient, il pourrait être intéressant de scinder le fil car le sujet actuel n'a plus grand chose à voir avec la question originale.
ok pour scinder car de toutes façons, ça n'a plus rien à voir avec la rotation d'élipses.
C'est passionnant la programmation, surtout quand on a un but ludique (d'ailleurs ça tombe bien, ça reste pour moi un loisir).
Il ne reste plus qu'à voir comment on programme un changement de niveau, et le jeu sera terminé.
Merci encore pour les encouragements!
je veux bien le publier, mais je ne comprends rien à github (j'ai trouvé un tuto mais je ne l'ai pas encore regardé).
Quant à choisir une licence libre, késako? Je vois bien le principe de la licence libre, mais à quoi ça servirait pour un si petit jeu?
sinon je continue de poster ici:
https://www.developpez.net/forums/d1...000-sdl-1-2-a/
Ce n'est pas grave. Chaque chose en son temps.
C'est déjà une excellente chose de l'avoir partagé sur Developpez !
Quand tu en auras le temps, c'est-à-dire quand tu auras finalisé une première version de ton jeu et que tu auras rempli une liste d'objectifs à atteindre fixée par toi-même, essaie de te familiariser avec Git en local. Tu peux initialiser un dépôt même s'il y a déjà quelque chose dedans. Ensuite, quand tu seras à l'aise, il te suffira simplement de publier les branches que tu gères déjà en local.
Ce n'est pas fondamental non plus, et tu peux très bien décider de diffuser ça en simple freeware, voire d'abandonner tes droits et de mettre ton logiciel dans le domaine public. Tu peux aussi choisir d'y mettre un copyright, voire de le diffuser contre rémunération (mais il aura moins de succès). Par contre, les licences sont utiles parce qu'elles ont une valeur juridique, dans le sens où, par défaut, c'est le droit d'auteur qui s'applique en l'absence de toute mention. Donc spécifier une licence et, si possible, en choisir une parmi celles qui ont été mûries pour éviter toute ambiguïté, permet aux gens de savoir en un coup d'œil ce qui est permis et ce qui ne l'est pas. Et notamment : redistribuer le logiciel (donc dans l'absolu, sans avoir à te demander l'autorisation à chaque fois), modifier le logiciel (c'est idiot mais ce n'est pas automatique, donc si tu veux avoir des contributeurs, c'est bien de savoir où on met les pieds), savoir s'il faut te citer si on utilise ton produit ou si ce n'est pas nécessaire, et si on peut se baser sur ce que tu as écrit pour sortir un produit dérivé, pour éviter de réinventer la roue à chaque fois (utile spécialement si c'est une bibliothèque, mais pas seulement).Quant à choisir une licence libre, késako? Je vois bien le principe de la licence libre, mais à quoi ça servirait pour un si petit jeu?
Il existe notamment les licences GPL, BSD, Apache, MIT et les Creative Commons, en vigueur sur Wikipédia.
J'ai ajouté une licence Creative Commons au jeu.
N'ayant toujours rien compris à Github, je poste ici la version dans laquelle j'ai ajouté un niveau (les voitures vont plus vite que le joueur). Il y a également une barre d'état qui s'affiche. Disons qu'elle représente le pourcentage de chance d'avoir une prime de fin d'année de mise à la fourrière. (on ne tue personne dans ce jeu! j'y tiens!).
Pour se faire une idée :
Le logiciel de contrôle de version derrière tout ça est git, que tu installes en local et qui te permet éventuellement de communiquer avec un dépôt distant, appelé remote. Le dépôt distant peut, tout comme un site web, être servi par n'importe quel serveur. Github et autres ne sont que les hébergeurs spécialisés de ce remote, qui te permettent de garder ton projet à l'abri et de le partager avec le monde.
On insiste, mais utiliser un logiciel de contrôle de version (qu'il s'agisse de git, bazaar, mercurial, etc..) est quasiment indispensable même pour un projet « loisir ». Franchement le temps investi dans l'apprentissage de son utilisation te sera rendu au centuple, tu ne reviendras pas en arrière.
Tu pourras trouver des crash courses et tutoriels express pour débuter avec git un peu partout.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager