Bon, on en a déjà un peu parlé ici, mais je reprend dans un topic dédicacé.
Le principe du but de l'objectif est simple: s'organiser en groupes pour créer de "vrais" jeux (en C essentiellement), un peu comme les GB
On aurait ainsi plus d'efficacité, plus d'idées, moins de mal à coder, et enfin de meilleurs jeux (je dit pas que ce qui sort en ce moment est nul, hein , mais ils ne sont pas tous finis-finis )
Pour ma part, je pensais faire un rpg du genre Arcuz, qui est très bien fait. Je peut participer au projet en tant que programmeur (j'ai de bonnes bases en C) et grapheur (option Arts-Plastiques au lycée). Par contre, j'ai besoin d'un peu d'aide coté moteur de jeu.
Je suis bien conscient que beaucoup ont entamés un projet, et qu'ils ont du mal à le finir: je veut bien vous aider, y'a pas de soucis
Voilà, je vous laisse en discuter, donnez moi votre avis.
IMPORTANT Un forum externe a été mis en place ici afin de s'organiser sans (trop) polluer ce topic
Rassemble tous les sprites dans un petit zip.
Ca rend vraiment bien. Par contre il faudrait rajouter une position entre 45° et 90° pour le canon.
EDIT
Je peux pas poster sur ton fofo sans m'inscrire.
Voici 2-3 infos ici :
- pour la jauge du canon, j'aurai pensé la mettre dans le canon
- sinon c'est ok pour la gestion des objets
- pour pouvoir mettre des grands niveaux, il faut prévoir le scroll de la map avec la touche ALPHA par exemple
- pas de niveaux de gris, on utilise MonochromeLib
j'ai re-fait les changements sur le forum, normalement ca devrait aller .
Le zip arrive bientot, j'ai même fait les graphiques pour les positions 22.5° et 67.5°
--- Edit ---
Le zip est là
----------------------------------
Purobaz En ligne Membre Niveau: Aucun
Points: 2141
Défis: 108 Email | Message
Met à jour le topic, ajoute y le lien du forum
Les graphismes sont nickels, ça colle bien à l'esprit du jeu.
Mais comme je disais je ne pourrais pas m'occuper tout de suite de ce projet.
@Purobaz, de mon point de vue, la gestion des collisions doit toujours être distinguée de l'affichage. L'écran sert de représentation de l'état des variables, pas de variable de stockage. De plus, avec un moteur basé sur des pixel_test, une modification des images du jeu perturberait son fonctionnement.
Rappel: n'hésitez pas à me faire part de vos remarques sur le forum externe: c'est fait pour ça. J'ai refait les changement, il est donc (normalement) possible de poster sans e-mail
----------------------------------
Purobaz En ligne Membre Niveau: Aucun
Points: 2141
Défis: 108 Email | Message
J'ai vu que t'as utilisé un curseur pour diriger le canon, je pense que le jeu sera plus agréable avec gauche/droite pour l'angle et haut/bas pour la force.
PS : Je peux toujours pas poster sur le forum externe.
@ Pierrotll : t'avais pas ajouté une fonction pour garder l'indentation du code ?
ca qui est bien avec le curseur, c'est qu'il y a plus de précision pour ce qui est de l'angle (je n'ai pour l'instant que 5 sprites à afficher)
Du coup, soit je garde le curseur, soit je me débrouille pour faire une barre pour afficher l'angle.
Pour le timer, je met met au point sur la partie (je relis le tuto du SdZ)
Ajouté le 27/01/2012 à 18:44 :
Le timer, tu l'appelle avec la SDL ?
Ajouté le 27/01/2012 à 18:46 :
J'oubliais: pour le forum, je sait pas ce qui va pas, donc du coup, il faut s'inscrire pour poster.
Si vous êtes inscrits, je peut vous mettre en admin pour modifier les présentations des sujets
----------------------------------
Purobaz En ligne Membre Niveau: Aucun
Points: 2141
Défis: 108 Email | Message
Voilà ce que je propose pour l'angle :
- on part de 0
- lorsqu'on appui sur gauche ou droite on augmente ou diminue l'angle
- on affiche l'image qui correspond à peu près à l'angle
Je ne sais pas si ça rendra bien, faudrait tester.
Pour le timer, lis la doc du SDK. C'est pas très compliqué.
Et pour le canon au lieu de faire des images, il y a pas moyen de calculer la position des points en fonction d'une variable angle ? Avec une fonction de rotation ?
Je pense que c'est trop petit et imprécis, mais c'est dommage qu'il n'y ait que 5 images, si ça se trouve, ça rend bien, mais ça me paraît peu.
bah, avec ta fonction, il faut gérer le canon (attention à la roue qui doit rester devant), et le bonhomme: là, il y a du boulot !
Sinon, on supprime le perso
Ç'aurait pu être bien Mais bon, j'ai finit la doc du SDK, donc bon, faisons avec ce que nous "offre" Casio
Ajouté le 29/01/2012 à 18:42 :
Puro: ta technique semble être pas mal, je creuse de ce coté.
Qqun veut bien m'expliquer le principe du timer, j'ai pas trop compris
On dit tjr "qu'est-ce-que t'as pas compris ?", du coup, j'anticipe: pas compris la syntaxe, et comment et où l'utiliser
Merci d'avance
Pour PLL: J'avais jamais utilisé les timers, donc j'ai pensé que la SDL pouvait marcher...
Ajouté le 31/01/2012 à 10:11 :
bon, j'ai compris le principe des timers, et j'ai commencé un peu le code (bouger le canon, gerer la puissance).
Je vous fait bientot part de l'avancement du projet.
PS: j'avais lu un topic sur des sprites de 8*8 sur 8 octets, mais je ne l'ai pas retrouvé (sur un autre site ) Si qqun a le lien, je le remercie d'avance
Ajouté le 01/02/2012 à 18:35 :
bon, y'a un gros problème: en utilisant MonochromeLib, il m'affiche ceci lors de la compilation:
[blablabla]
** L2310 (E) Undefined external symbol "_ML_bmp_or" referenced in "C:\Documents and Settings\Papa_2\Bureau\KtW\Debug\jeu.obj"
[...]
Build was not successful.
Je précise que j'ai bien décommenté les fonctions utilisées dans MonochromeLib.h, inclu la librairie dans mes sous-fichiers, mais rien a faire
Une idée ?
Planète-Casio est un site communautaire indépendant et n'est donc pas affilié à Casio | Toute reproduction de Planète-Casio, même partielle, est interdite
Les fichiers, programmes et publications postés sur Planète-Casio restent la propriété de leurs auteurs respectifs et peuvent être soumis à des copyrights
Merci de respecter le travail des autres ! | CASIO est une marque déposée par CASIO Computer Co., Ltd