Bonjour,

J'ai la ferme intention de procéder à la conception d'un petit danmaku (ou "bullet hell, exemple ici: http://upload.wikimedia.org/wikipedia/en/2/24/PCByukari140.jpg ).

J'ai le temps, j'ai de bonnes notions d'algorithmique et un très bon background mathématique (étudiant ingénieur civil (~polytechnique en France)). La programmation m'est très loin d'être inconnue, mais essentiellement dans les applications web et calculs scientifiques.

Je compte réaliser ce petit projet comme à la fois un entrainement au C++ (que je n'ai jamais eu l'occasion de vraiment pratiquer) et à la création de jeu (idem). Coté graphiques/son donc, pas besoin de me casser la tête, je piocherai à gauche à droite puisque ça restera pour mon utilisation personnelle et rien de plus.

J'ai donc essentiellement deux questions:

1) Y aurait-il d'autres prérequis que je n'ai pas mentionné et donc que je ne possède peut-être pas?

2) Quelle serait une bonne librairie graphique C++ adaptée à ce projet? Éventuellement un autre langage serait-il mieux adapté?

Merci d'avance.

je pense que si tu es bon en algo et en math en general, tu devrais bien t'en sortir. Si tu ne le sais pas deja, tu peux vouloir regarder ce qu'est un quad-tree.

Pour faire ca en C++, je pense que la SFML fonctionnera bien. La SDL devrait marcher egalement. Mais SFML a la reputation d'etre plus rapide et compte tenu du nombre de bullet a afficher sur un danmaku, tu peux vouloir aller directement du cote de SFML.

Merci beaucoup pour cette réponse rapide

Je ne connaissais pas le quadtree mais j'adopte, ça sera bien utile pour accélérer les tests de collision, merci pour le tuyau.

J'avais déjà un peu chipoté avec la SDL mais autant faire directement au mieux, je vais donc me renseigner du coté de SFML.

Je reste évidemment ouvert à tout autre suggestion/réponse/conseil (^-^)

En vrai, j'ai un projet de shooter en cours. Je n'utilise pas de quadtree et mon affichage avec SDL consiste seulement de rectangle (pas de sprite) mais je ne fais pas de collisions inutile (comme les collisions bullet/bullet).
J'ai fait des tests a un nombre important d'objet et je n'ai pas vu de soucis de vitesse sur mon laptop (processeur model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz).

Donc si j'etais toi, je ne me focaliserais pas sur la realisation d'un moteur super performant. Fais plutot quelquechose de facile a utiliser.

Si ca t'interesse, je mettrais du code en ligne a l'occasion.

C'est sûr qu'avec les bêtes qu'on a maintenant, nos petits jeux 2D ne consomment plus grand chose :P

Mais vu que je suis un malade de l'optimisation et que c'est surtout un projet pour bien me remettre à la POO, je crois que je vais quand même tenter le coup. Au pire si j'ai bien géré le coup, il ne devrait pas être trop compliqué de revenir à un système plus simple si ça me bloque vraiment.

Mais effectivement, je suis en train de scruter du code source de shooters qui me passent sous la main pour me faire une idée de la chose, donc cela m'intéresserait beaucoup

j'essayerais de poster ca ce soir.

Optimiser le code pour un pc, ca manque un peu de sens compte tenu des ressources monumentale que l'on a. parcontre il y a d'autres architectures interessantes que je vise souvent comme la ds, la wii ou mon pda.

choses promises, choses dues.
Le code est la, tu devrais n'avoir besoin que de la libSDL pour le compiler.
http://godrik.mandragor.org/~erik/shmup.tgz
Une fois le binaire ./shmup compiler, tu peux tester un niveau avec
$ ./shmup <level>

les niveaux sont les fichiers .timed
J'ai inclut mon historique git dans l'archive des fois que ca t'interesse.
Si tu as des questions n'hesite pas.

L'architecture logicielle est a moitie a chier.

Si tu de demande, oui, j'ai fait les niveaux avec xfig

Trés beau projet (dans le sens réaliste, c'est rare sur ce forum )
Par contre pour la collision je suis pas sur que les quadTree sont utiliséé dans ce type de jeu ( les objets ne sont pas assez complexes) la collision se fait (je pense) au pixel c'est ce qui rend le jeu fun , en donnant l'impression au joueur d'etre un dieu , en utilisant des OBB ou des tests de collisions plus poussés tu va juste rendre le jeu trop dur et faire chuté tes FPS.
Pour les graphismes une fois que tu aura les bases du jeu en place tu ne devrais pas avoir de mal a trouver un graphiste.

Bonne continuation

Regarde du coté de "BulletML", c'est fait pour ce genre de jeux

http://www.asahi-net.or.jp/~cs8k-cyu/

Les collisions pixel perfect c'est bien quand tu as une resolution constante. Personnellement, je prefere avoir un model de jeu qui ne depends pas de la resolution et caler les graphismes a posteriori.

Le fait de donne au joueur l'impressoin d'etre un dieu est generalement obtenu en mettant la boite de colision du vaisseau du joueur plus petite que son image. C'est ce qui est fait dans Ikaruga par exemple ou la zone de collision du vaisseau est uniquement le cocpit.

le quadtree est une methode simple pour eviter des test de collision inutile. Ce n'est pas la seule methode, mais elle est classique, efficace et bien documente. C'est a connaitre avant de te lancer dans un Danmaku. Dans mes tests, je ne fais jamais de collision bullet/bullet donc mon nombre de calcul de collision est relativement faible et je n'ai pas besoin de retirer de collision evidement fausse. Cependant, quand j'avais active les collisions bullet/bullet pour voir si c'etait faisable, j'ai eu un ralentissement evident. Et dans ce cas une methode pour retirer des calcul de collision aurait ete utile.

En terme de FPS, dans mon moteur, tous les objets sont des rectangles et je calcul facilement 1000 etats par secondes (sur enemySRotate.timed). Le rendu est exclu de ce compte parceque le moteur calcul independament du rendu.

En general les maniac shooter ne travaillent pas au pixel pour la collision. Je dirai que le vaisseau est 1 pixel.
Pour les tirs, ce sont surement des cercle ou des formes simples.
Un simple algo de distance permets de rapidement virer les candidats trop loin. (un quadtree semble inutile ici en effet, ca bouge tellement vite, que finalement il n'y aurait aucun gain de temps entre calculer un quad tree toutes les trames et faire un test de collision entre 1 points et les formes aux alentours).

Oui, il faut faire un peu attention en effet et ce n'est pas forcement la meilleure methode. Mais tu peux greffer des heuristiques assez facilement la dessus.

Par exemple, tu ne fais pas exactement un quadtree mais une grille de 5x5 et ainsi l'allocation dans une case de la grille se fiat en deux modulo.

Ou encore, si tu connais la vitesse maximale de tes objets, tu peux calculer le temps minimal de traverser d'une case de la grille et ne mettre a jour le quadtree que periodiquement.