Petite programmation [C++, SDL]
20 réponses à ce sujet
2
Salut forumeurs, visiteurs, staffeurs.
A la base, c'était juste pour tester la librairie SDL (Simple DirectMedia Layer), mais comme ça rend relativement bien je me suis dis pourquoi pas le partager.
C'est donc une release, d'une sorte de démo technique programmée de A à Z (Sauf les sprites glanés sur le ouaib, (c)Sonic Team évidemment) qui met en scène un sprite de Sonic, "animé" à partir d'un Sprite-Sheet non calibré pour être utile ce qui a pour conséquence une animation moyenne mais c'était plus la mise en oeuvre technique que la qualité. En fond, il y a décor fait d'une image répétée au format bitmap, bien qu'un format compressé aurait fait l'affaire (PNG, GIF, etc...) donc le chargement est un poil plus lent bien que vous ne verrez pratiquement pas le chargement.
Le langage utilisé est le C++.
La démo présente les techniques suivantes :
Tout cela étant très perfectible, je recodes en changeant une grosse partie du code ce n'était qu'une mise en bouche :'D (Interfaces, structures, gestion de données en format XML), cependant cela reste sans prétention aucune. Je ne comptes pas faire un jeu, je ne comptes pas révolutionner le monde du jeu vidéo, juste quelque chose qui puisse m'occuper.
Bien que j'utilise SDL et que les fichiers de la librairie sont intégrées dans l'archive et la librairie standard, vous aurez besoin du fichier Visual C++ Redistribuable 2005 ou 2008, le téléchargement est rapide de même pour l'installation.
Choisissez l'un des deux :
Visual C++ Redistribuable 2005 (XP) : http://www.microsoft.com/Downloads/deta ... laylang=fr
Visual C++ Redistribuable 2008 (XP/VISTA) : http://www.microsoft.com/downloads/deta ... laylang=fr
Et voilà la dite archive contenant le fichier Jeu.exe (Ne vous fiez pas au nom, cela reste un démonstration) : http://dl.free.fr/qyeRwYUHZ
Un extracteur (WinRAR) est nécessaire pour l'extraire.
Les contrôles :
En espérant que vous apprécierez cette démonstration très basique !
A la base, c'était juste pour tester la librairie SDL (Simple DirectMedia Layer), mais comme ça rend relativement bien je me suis dis pourquoi pas le partager.
C'est donc une release, d'une sorte de démo technique programmée de A à Z (Sauf les sprites glanés sur le ouaib, (c)Sonic Team évidemment) qui met en scène un sprite de Sonic, "animé" à partir d'un Sprite-Sheet non calibré pour être utile ce qui a pour conséquence une animation moyenne mais c'était plus la mise en oeuvre technique que la qualité. En fond, il y a décor fait d'une image répétée au format bitmap, bien qu'un format compressé aurait fait l'affaire (PNG, GIF, etc...) donc le chargement est un poil plus lent bien que vous ne verrez pratiquement pas le chargement.
Le langage utilisé est le C++.
La démo présente les techniques suivantes :
-
[*:3gizcqzi]-Scrolling avec gestion caméra.[/*:3gizcqzi]
[*:3gizcqzi]-Affichage d'information (Techniques, pas de HUD).[/*:3gizcqzi]
[*:3gizcqzi]-Physique très basique notamment pour l'accélération/décélération, ainsi que pour le saut et une petite partie collision.[/*:3gizcqzi]
[*:3gizcqzi]-Gestion des images, ainsi que celle des animations à partir d'une planche de sprites.[/*:3gizcqzi]
[*:3gizcqzi]-Gestion des entrées pour le contrôle du personnage.[/*:3gizcqzi]
Tout cela étant très perfectible, je recodes en changeant une grosse partie du code ce n'était qu'une mise en bouche :'D (Interfaces, structures, gestion de données en format XML), cependant cela reste sans prétention aucune. Je ne comptes pas faire un jeu, je ne comptes pas révolutionner le monde du jeu vidéo, juste quelque chose qui puisse m'occuper.
Bien que j'utilise SDL et que les fichiers de la librairie sont intégrées dans l'archive et la librairie standard, vous aurez besoin du fichier Visual C++ Redistribuable 2005 ou 2008, le téléchargement est rapide de même pour l'installation.
Choisissez l'un des deux :
Visual C++ Redistribuable 2005 (XP) : http://www.microsoft.com/Downloads/deta ... laylang=fr
Visual C++ Redistribuable 2008 (XP/VISTA) : http://www.microsoft.com/downloads/deta ... laylang=fr
Et voilà la dite archive contenant le fichier Jeu.exe (Ne vous fiez pas au nom, cela reste un démonstration) : http://dl.free.fr/qyeRwYUHZ
Un extracteur (WinRAR) est nécessaire pour l'extraire.
Les contrôles :
-
[*:3gizcqzi]Flèches directionnelles : Droite pour aller à droite, gauche pour aller à gauche.[/*:3gizcqzi]
[*:3gizcqzi]Espace : Sauter[/*:3gizcqzi]
[*:3gizcqzi]Croix Rouge/Alt+F4 : Quitter[/*:3gizcqzi]
[*:3gizcqzi]Le "+" du Keypad pour augmenter la vitesse limite, et "-" pour l'effet inverse.[/*:3gizcqzi]
En espérant que vous apprécierez cette démonstration très basique !
1
Mais c'est quoi ? Un jeu ? je l'ai télécharger mais ça marche pas, j'arrive pas à l'ouvrir !
Sonic, Shadows, Amy : 
3
14
21
Le lien du package visual c++ pour ceux qui ont un vista normal (pas 64bits) : http://www.microsoft.com/downloads/deta ... laylang=fr
2
Ce n'est pas réellement un jeu, c'est une démo. Le téléchargement contient une archive qu'il faut extraire (Vu que c'est du RAR, faut utiliser WinRar) ensuite, avec les fichiers tu as un exécutable "jeu.exe" où il faut cliquer dessus.
S'il ne marche pas, alors il faut télécharger ce qu'a donné ced_ ou mes deux liens plus haut (Visual C++ Redistribuable).
S'il ne marche pas, alors il faut télécharger ce qu'a donné ced_ ou mes deux liens plus haut (Visual C++ Redistribuable).
1
D'accord je vais essayer mais bon je pense pas que j'y joue beaucoup ! 
Sonic, Shadows, Amy :
2
Bah, il est très difficile de jouer longtemps sur une démo, surtout que celle là ne se contente que de quelques éléments. Cependant, si tu as des commentaires, impressions c'est toujours le bienvenue 
1
Ben elle est bien, je trouve ça sympa !
Sonic, Shadows, Amy :
2
4
22
C'est bien pour une première démo.
Il y a quand même pas mal de bugs comme par exemple le fait de pouvoir sauter plusieurs fois en l'air... etc
Je ne sais pas comment tu gères les sauts mais d'une manière générale, je conseille l'utilisation des vecteurs x et y pour gérer les forces qui s'appliquent au perso (gravité, accélération, vent ...).
C'est expliqué en "méthode 3" ici, il me semble : http://www.siteduzero.com/tutoriel-3-35 ... -en-c.html
(je trouve que les autres méthodes sont inadaptées et gourmandes en calcul)
Si tu comptes faire évoluer ta démo en jeu, il faut réfléchir dès maintenant à la manière de gérer plateformes et pentes (+ loopings etc ...). Personnellement je cherche encore un moyen efficace d'implémenter tout ça (pixel perfect), la physique des Sonic étant assez hors norme.
Il y a quand même pas mal de bugs comme par exemple le fait de pouvoir sauter plusieurs fois en l'air... etc
Je ne sais pas comment tu gères les sauts mais d'une manière générale, je conseille l'utilisation des vecteurs x et y pour gérer les forces qui s'appliquent au perso (gravité, accélération, vent ...).
C'est expliqué en "méthode 3" ici, il me semble : http://www.siteduzero.com/tutoriel-3-35 ... -en-c.html
(je trouve que les autres méthodes sont inadaptées et gourmandes en calcul)
Si tu comptes faire évoluer ta démo en jeu, il faut réfléchir dès maintenant à la manière de gérer plateformes et pentes (+ loopings etc ...). Personnellement je cherche encore un moyen efficace d'implémenter tout ça (pixel perfect), la physique des Sonic étant assez hors norme.
2
Même si dans la démo ce n'est pas implantée du tout (C'était pour avoir deux trucs qui ressemblent à de la physique), la physique que j'appliques est strictement Newtonienne, et j'utilise notamment la troisième loi de Newton pour le saut, la chute, l'accélération et la décélération. Je penses que tu la connais : somme des forces externes = m*accélération (dans un repère orthonormés). L'avantage de cette solution est que je peux gérer toutes les forces en une seule équation et en y déduisant une vitesse, voir une position à un instant t de départ le cas échéant.
Pour les Loopings, je pensais utiliser un repère de Frenet, mais j'y réfléchis encore (Notamment la façon dont je vais changer le repère passant de deux vecteurs unitaires normales X et Y à un vecteur normal et tangent). Quant aux pentes, il s'agira de gérer avec un vecteur dircteur, et le rectangle que représente le sprite Sonic avec beaucoup de trigonométrie.
La pseudo-physique qui fait le saut est responsable du fait de pouvoir faire du multi-jumps, et le manque de Handle Input adaptés est responsable des quelques bugs de contrôles, cependant j'ai entretemps crée une vraie structure pour gérer les entrées qui marchent mieux et qui simplifient notablement les contrôles.
La prochaine évolution de la démo prendra beaucoup de temps car j'ai prévu de mettre une physique potable cette fois ci, et de refondre le traitement des Sprites (nouvelles classes, nouvelles approches, etc.) afin de régler les erreurs d'animations, ainsi que des effets post-rendus tels que le flou dont les premiers essais sont concluants.
Pour les Loopings, je pensais utiliser un repère de Frenet, mais j'y réfléchis encore (Notamment la façon dont je vais changer le repère passant de deux vecteurs unitaires normales X et Y à un vecteur normal et tangent). Quant aux pentes, il s'agira de gérer avec un vecteur dircteur, et le rectangle que représente le sprite Sonic avec beaucoup de trigonométrie.
La pseudo-physique qui fait le saut est responsable du fait de pouvoir faire du multi-jumps, et le manque de Handle Input adaptés est responsable des quelques bugs de contrôles, cependant j'ai entretemps crée une vraie structure pour gérer les entrées qui marchent mieux et qui simplifient notablement les contrôles.
La prochaine évolution de la démo prendra beaucoup de temps car j'ai prévu de mettre une physique potable cette fois ci, et de refondre le traitement des Sprites (nouvelles classes, nouvelles approches, etc.) afin de régler les erreurs d'animations, ainsi que des effets post-rendus tels que le flou dont les premiers essais sont concluants.
2
4
22
On ne doit pas avoir la même approche car dans mon algo j'ai pas de multiplication.
Si ton programme suit la schéma classique (une grande boucle qui redessine tout à chaque itération) alors le "calcul" suivant devrait suffire (dsl s'il y a quelques imprecisions quant aux notions scientifiques qui suivront, j'ai arreté la physique il y a déjà quelques années) :
(les chiffres donnés sont purement arbitraires)
initiation
à chaque itération :
[list=1]
on somme les forces à appliquer (gravité + une vitesse de 20 vers le haut (seulement pour t0) = 18)
on somme les forces extérieures aux vecteurs du perso = (0, 18)
on déplace le perso suivant ses nouveaux vecteurs [/list
crk4eql7]
La gravité qui soustrait à chaque itération s'occupera de faire redescendre le perso naturellement lorsque l'on aura des valeurs négatives (18, 16, 14 ... 0, -2, -4 ...). Il faudra penser éventuellement à placer une limite de vitesse pour la chute (si jme rappelle bien la friction est proportionnelle au carré de la vitesse mais un simple if(vitesse > limite) vitesse = limite; suffira je pense).
Je pense qu'il est possible de gérer le déplacement du perso avec les contrôles de la même manière (en appuyant sur la droite, on ajoute une force de 1 vers la droite, ainsi l'accélération est naturelle).
Quasiment aucun calcul, je pense que le résultat est plutot efficace :
http://membres.lycos.fr/sonicconnexion/demo/phys/
Si ton programme suit la schéma classique (une grande boucle qui redessine tout à chaque itération) alors le "calcul" suivant devrait suffire (dsl s'il y a quelques imprecisions quant aux notions scientifiques qui suivront, j'ai arreté la physique il y a déjà quelques années) :
(les chiffres donnés sont purement arbitraires)
initiation
- la gravité est de 2
- ton perso possède 2 vecteurs vitesses x, y ( initialisés à 0 pour un perso immobile)
- imaginons maintenant que ton perso immobile touche un ressort qui a la propriété d'appliquer une force de 20 vers le haut
à chaque itération :
[list=1]
crk4eql7]La gravité qui soustrait à chaque itération s'occupera de faire redescendre le perso naturellement lorsque l'on aura des valeurs négatives (18, 16, 14 ... 0, -2, -4 ...). Il faudra penser éventuellement à placer une limite de vitesse pour la chute (si jme rappelle bien la friction est proportionnelle au carré de la vitesse mais un simple if(vitesse > limite) vitesse = limite; suffira je pense).
Je pense qu'il est possible de gérer le déplacement du perso avec les contrôles de la même manière (en appuyant sur la droite, on ajoute une force de 1 vers la droite, ainsi l'accélération est naturelle).
Quasiment aucun calcul, je pense que le résultat est plutot efficace :
http://membres.lycos.fr/sonicconnexion/demo/phys/
2
Approche intéressante, mais si la force n'est pas constante, ton algorithme pose problème, surtout si t'as une force qui s'applique à un terrain qui est en pente mais non linéaire (Avec des bosses) où la résultante (Somme des forces) ne sera pas toujours constante elle aussi.
Comme tu as si gentiment expliqué ton algorithme, je vais te donner la mienne en me basant sur la troisième loi de Newton, en prenant par exemple un saut sans frottements, ainsi seule la force de gravité est utilisée (Notée m*g (Masse x Cste de gravité terrestre ). En prenant le repère de base sous SDL (Deux vecteurs unitaires, y de direction vers le bas, x de direction vers la droite)
D'aprés la troisième loi de Newton :
m*g = m*a <=> g = a, a étant l'accélération
ax(t) = 0 (Car la force de gravité est supposé s'appliquer seulement de façon verticale)
ay(t) = g
a étant la dérivée de la vitesse en fonction du temps (Par définition), la vitesse s'obtient alors de cette façon :
vx(t) = cos(&)*vInit
vy(t) = g*t + sin(&)*vInit
vInit est en fait la valeur de la vitesse initiale, & étant l'angle d'écart entre le sol et le vecteur de la vitesse initiale, plus il est grand, plus le bonhomme saute verticalement et inversement.
Et si je veux en déduire l'équation de la position en fonction du temps (la vitesse étant une dérivée de la position en fonction du temps) :
x(t) = t*cos(&)*vInit + xInit
y(t) = 1/2*t²*g + sin(&)*vInit*t + yInit
xInit et yInit étant les coordonnées de départ.
Si je pars d'un instant t = 0 avant le saut, je peux déterminer des informations futures (Coordonnée du point d'impact, cibles rencontrées, etc...) avant même que le bonhomme n'ait commencé à sauter, si on part du postulat que son mouvement ne peut être influencé par le contrôle du joueur (Ce qui n'est pas le cas avec les vieux jeux de plate formes).
L'avantage, tu peux ne garder que les équations de la vitesse et rajouter tes constantes de vitesses par dessus, à chaque itération à l'aide de t tu détermines la vitesse, puis tu change les positions en fonction des vecteurs vitesses ainsi obtenus.
Bien que cette technique demande des connaissances en physique, elle permet de prévoir des positions à l'avance, et l'addition de forces n'est pas un problème pour en déduire la vitesse obtenue au finale (C'est une question de primitives )
Bien sûr, les deux méthodes se valent autant l'un que l'autre, dans certaines situations je penses que ton approche sera la meilleure, et dans d'autres c'est celle là.
Comme tu as si gentiment expliqué ton algorithme, je vais te donner la mienne en me basant sur la troisième loi de Newton, en prenant par exemple un saut sans frottements, ainsi seule la force de gravité est utilisée (Notée m*g (Masse x Cste de gravité terrestre ). En prenant le repère de base sous SDL (Deux vecteurs unitaires, y de direction vers le bas, x de direction vers la droite)
D'aprés la troisième loi de Newton :
m*g = m*a <=> g = a, a étant l'accélération
ax(t) = 0 (Car la force de gravité est supposé s'appliquer seulement de façon verticale)
ay(t) = g
a étant la dérivée de la vitesse en fonction du temps (Par définition), la vitesse s'obtient alors de cette façon :
vx(t) = cos(&)*vInit
vy(t) = g*t + sin(&)*vInit
vInit est en fait la valeur de la vitesse initiale, & étant l'angle d'écart entre le sol et le vecteur de la vitesse initiale, plus il est grand, plus le bonhomme saute verticalement et inversement.
Et si je veux en déduire l'équation de la position en fonction du temps (la vitesse étant une dérivée de la position en fonction du temps) :
x(t) = t*cos(&)*vInit + xInit
y(t) = 1/2*t²*g + sin(&)*vInit*t + yInit
xInit et yInit étant les coordonnées de départ.
Si je pars d'un instant t = 0 avant le saut, je peux déterminer des informations futures (Coordonnée du point d'impact, cibles rencontrées, etc...) avant même que le bonhomme n'ait commencé à sauter, si on part du postulat que son mouvement ne peut être influencé par le contrôle du joueur (Ce qui n'est pas le cas avec les vieux jeux de plate formes).
L'avantage, tu peux ne garder que les équations de la vitesse et rajouter tes constantes de vitesses par dessus, à chaque itération à l'aide de t tu détermines la vitesse, puis tu change les positions en fonction des vecteurs vitesses ainsi obtenus.
Bien que cette technique demande des connaissances en physique, elle permet de prévoir des positions à l'avance, et l'addition de forces n'est pas un problème pour en déduire la vitesse obtenue au finale (C'est une question de primitives )
Bien sûr, les deux méthodes se valent autant l'un que l'autre, dans certaines situations je penses que ton approche sera la meilleure, et dans d'autres c'est celle là.
2
4
22
Oui, les méthodes se valent dans la mesure où nous devrions obtenir les mêmes sauts en utilisant des paramètres correspondant : tandis que je simule la physique de l'environnement, tu utilises sa représentation mathématique. Mais je reste convaincu que ta méthode est plus contraignante 
Le fait de pouvoir connaitre les positions à l'avance n'est pas un réel avantage dans la mesure où dans le jeu, il y aura pleins d'éléments pour remettre en question la trajectoire prédéfinie (et donc la recalculer) : rebondir sur un ennemi, l'utilisateur qui modifie le saut en manipulant la croix directionnelle ...
C'est exact à l'échelle du niveau mais pas à l'échelle du sprite (ou tile de 8x8 pixels il me semble) où la force appliquée est linéaire (ce qui correspondrait bêtement à la normale de la pente ?).
La question que je me pose depuis déjà un bout de temps c'est de savoir comment calculer/stocker ce vecteur de contrainte pour chaque tile (d'après ce que j'avais lu, la gestion des collision/pente est gérée en "pixel perfect" dans un sonic. Malheureusement j'ai pas les détails...)
Avec ta méthode, il faudrait obligatoirement assigner à chaque élément du niveau les vecteurs ou les courbes de trajactoires non ?
Personnellement, j'essaye de me m'imaginer l'algo qui a pu être utilisé à l'époque (puisque c'est une formule qui marche ) et qui devait être suffisamment simple/économe pour tourner sur du 8 bits.
Le fait de pouvoir connaitre les positions à l'avance n'est pas un réel avantage dans la mesure où dans le jeu, il y aura pleins d'éléments pour remettre en question la trajectoire prédéfinie (et donc la recalculer) : rebondir sur un ennemi, l'utilisateur qui modifie le saut en manipulant la croix directionnelle ...Approche intéressante, mais si la force n'est pas constante, ton algorithme pose problème, surtout si t'as une force qui s'applique à un terrain qui est en pente mais non linéaire (Avec des bosses) où la résultante (Somme des forces) ne sera pas toujours constante elle aussi.
C'est exact à l'échelle du niveau mais pas à l'échelle du sprite (ou tile de 8x8 pixels il me semble) où la force appliquée est linéaire (ce qui correspondrait bêtement à la normale de la pente ?).
La question que je me pose depuis déjà un bout de temps c'est de savoir comment calculer/stocker ce vecteur de contrainte pour chaque tile (d'après ce que j'avais lu, la gestion des collision/pente est gérée en "pixel perfect" dans un sonic. Malheureusement j'ai pas les détails...)
Avec ta méthode, il faudrait obligatoirement assigner à chaque élément du niveau les vecteurs ou les courbes de trajactoires non ?
Personnellement, j'essaye de me m'imaginer l'algo qui a pu être utilisé à l'époque (puisque c'est une formule qui marche
) et qui devait être suffisamment simple/économe pour tourner sur du 8 bits.2
Ma méthode ne sert seulement que pour les mouvements d'un ou plusieurs mobiles à partie de paramètres initiaux.
Si on devait stocker les vecteurs, cela serait dans une classe "CTiles" par exemple, bien que cette méthode soit lourde, le Pixel-Perfect doit être plus intéressant au final.
Mais, la méthode du Pixel-Perfect nécessite de pouvoir accéder aux informations au niveau du pixel de tous tes éléments (SDL ne l'implante pas nativement, mais avec de la bidouille on finit par créer une fonction de récupération du pixel exprimé soit en 32 bits, soit en 16, 8 bits), en gérant intelligemment la détection en Pixel Perfect, la méthode sera rapide et peu coûteuse, mais si c'est mal fait ça sera archi-coûteux en mémoire, il faudrait que je me renseignes aussi là dessus plus précisément.
Si on devait stocker les vecteurs, cela serait dans une classe "CTiles" par exemple, bien que cette méthode soit lourde, le Pixel-Perfect doit être plus intéressant au final.
Mais, la méthode du Pixel-Perfect nécessite de pouvoir accéder aux informations au niveau du pixel de tous tes éléments (SDL ne l'implante pas nativement, mais avec de la bidouille on finit par créer une fonction de récupération du pixel exprimé soit en 32 bits, soit en 16, 8 bits), en gérant intelligemment la détection en Pixel Perfect, la méthode sera rapide et peu coûteuse, mais si c'est mal fait ça sera archi-coûteux en mémoire, il faudrait que je me renseignes aussi là dessus plus précisément.
2
4
22
Ouais, je vois. En tout cas, ça m'a permis de recommencer à chercher un peu et je suis retombé sur le site de sonicretro, et c'est plutôt intéressant :
physique Sonic : http://info.sonicretro.org/Category:Sonic_Physics_Guide
info hacking http://info.sonicretro.org/Category:Hacking_Information
Dans le premier lien les mouvements du personnage est décortiquée et on trouve les coefficients pour la physique générale du jeu. Les chiffres sont assez précis, ça permettrait de faire un moteur très fidèle.
physique Sonic : http://info.sonicretro.org/Category:Sonic_Physics_Guide
info hacking http://info.sonicretro.org/Category:Hacking_Information
Dans le premier lien les mouvements du personnage est décortiquée et on trouve les coefficients pour la physique générale du jeu. Les chiffres sont assez précis, ça permettrait de faire un moteur très fidèle.
Edité le 23/06/09 15:47
2
De mon côté j'ai trouvé un article trés interessant sur le Pixel-Perfect, cependant c'est que de la théorie.
http://www.games-creators.org/wiki/Détection_pixel-perfect_des_collisions_2D
http://www.games-creators.org/wiki/Détection_pixel-perfect_des_collisions_2D
2
4
22
Ouais j'avais lu cet article il y a 2 ans, mais ça n'explique que la gestion de collision au sens strict
Salut à tous !
Je compte travailler très prochainement sur un fan-game Sonic reproduisant le gameplay de Sonic The Hedgehog (sur Mega Drive) tout en ajoutant des fonctionnalités (comme la prise en charge réseau). Ce travail sera effectué dans le cadre du projet de première année d'une école d'informatique (il y a donc des chances qu'ils aboutissent).
C'est pourquoi le travail de Bartpab m'intéresserait ! Seulement, sa démo n'est plus disponible
Est-ce que quelqu'un en a gardé une copie ?
Sinon, je ne peux pas voir son adresse mail, et je doute qu'il réponde en lui envoyant un MP (ça doit être un visiteur rare, tout comme moi). Étant donné qu'il a obligatoirement dû donner un mail valide pour valider son inscription, j'aurais voulu savoir si un membre de l'équipe du forum pouvait me la donner.
Merci d'avance !
Je compte travailler très prochainement sur un fan-game Sonic reproduisant le gameplay de Sonic The Hedgehog (sur Mega Drive) tout en ajoutant des fonctionnalités (comme la prise en charge réseau). Ce travail sera effectué dans le cadre du projet de première année d'une école d'informatique (il y a donc des chances qu'ils aboutissent).
C'est pourquoi le travail de Bartpab m'intéresserait ! Seulement, sa démo n'est plus disponible
Est-ce que quelqu'un en a gardé une copie ?
Sinon, je ne peux pas voir son adresse mail, et je doute qu'il réponde en lui envoyant un MP (ça doit être un visiteur rare, tout comme moi). Étant donné qu'il a obligatoirement dû donner un mail valide pour valider son inscription, j'aurais voulu savoir si un membre de l'équipe du forum pouvait me la donner.
Merci d'avance !
2
4
22
La personne capable de cela est pour l'instant absente. Je penserai à transmettre la demande.
3
10
15
Accessoirement, il n'est pas impossible que Bartpab soit notifié par e-mail des messages privés qu'il reçoit. Essaie toujours un petit MP !
“Sonic 2006 is both the most challenged and challenging Sonic game ever put to market, and it is one of the most misunderstood commercial videogames of the 2000s.”
— Zolani Stewart
— Zolani Stewart
En effet, ça peut fonctionner !
Sinon, savez-vous où je pourrais trouver un maximum de ressources graphiques du jeu Sonic The Hedgehog ?
J'ai déjà trouvé ces sites là, mais je préfère faire confiance à vos connaissances dans le domaine
Merci d'avance
Sinon, savez-vous où je pourrais trouver un maximum de ressources graphiques du jeu Sonic The Hedgehog ?
J'ai déjà trouvé ces sites là, mais je préfère faire confiance à vos connaissances dans le domaine
- http://dioxaz.free.fr/
- http://www.themysticalforestzone.com/Kajin/sprites/Sonic%20Sprites/unfolderd/Sonic5.htm
- http://www.sonicfangameshq.com/sprites.html
Merci d'avance
2
Salut, désolé de ne pas avoir répondu en ce moment je n'ai plus trop le temps de traîner sur le net pour mes hobbies.
Alors j'ai une mauvaise nouvelle, le code source de la démo n'est malheureusement plus dans mes bagages (Disons que mon seul ordinateur où j'ai eu les sources ne me répond plus... Immonde D:), d'un autre côté vu que j'ai programmé la démo j'ai tous dans la tête.
Il se peut que je recodes ce que j'ai fait en changeant quelques principes (Ayant appris à interfacer Python et CPP ça va être plus fun) et cette fois ci j'uploaderai les sources dans un endroit sûr.
Si tu as des question (même après quelque mois), tu peux me les poser ici ou en mp.
Alors j'ai une mauvaise nouvelle, le code source de la démo n'est malheureusement plus dans mes bagages (Disons que mon seul ordinateur où j'ai eu les sources ne me répond plus... Immonde D:), d'un autre côté vu que j'ai programmé la démo j'ai tous dans la tête.
Il se peut que je recodes ce que j'ai fait en changeant quelques principes (Ayant appris à interfacer Python et CPP ça va être plus fun) et cette fois ci j'uploaderai les sources dans un endroit sûr.
Si tu as des question (même après quelque mois), tu peux me les poser ici ou en mp.