Re: IRENA - Genesis Metal Fury

[Invité]

La semaine est terminée, mais j'ai attrapé de nouveau une crève pas possible et forcément hors de question pour moi de ne pas aller à la salle de sport. Hier j'ai salement dégusté en rentrant tout comme ce matin, mais tout comme le sport, hors de question de ne pas avancer sur le projet !

Et tu trouves le temps de bosser entre les deux ?!  je ne sais pas comment tu fais !

[Invité]

@Gringos10 depuis que j'ai arrêté de participer activement au topic MD vs SNES, j'ai un peu plus de temps

Plus sérieusement, j'aime beaucoup coder, donc tant pis si je ça me retire le temps que je consacre normalement à la détente.

[Invité]

Comme demandé, je me suis occupé d'ajouter des sons pour les explosions, oui ça rend beaucoup mieux ! J'en ai profité pour appliquer ma nouvelle font et j'ai commencé à élaborer des paternes pour les ennemis.

Se sera tout pour le week-end, je vais un peu me reposer histoire de commencer une nouvelle semaine de boulot Normalement je suis en congé à la fin du mois, ça devrait me laisser un peu de temps libre pour continuer de travailler sur le projet.

[Invité]

Bon j'ai menti, hier soir j'ai encore bossé toute l'après-midi / soirée sur le code. J'ai amélioré plusieurs petites choses, corriger plusieurs bugs concernant le score et les ennemis. J'ai également remplacé la musique qui posait problème avec les digit qui passaient en mono.

Désormais, il faut tirer plusieurs fois sur un ennemi pour le détruire et j'ai ajouté des impacts lorsque les bullets touche une cible.

Sinon j'ai reçu ce matin les nouveaux sprites.

[Invité]

Coucou,
Nouveeaux travaux de Uipneu pour Irena :


T'en a de la chance !
Faudrais que tu le contactes ...

[Invité]

Whaaaoou c'est super joli ! J'aime beaucoup, c'est juste énorme comme réalisation.

Par contre, je l'ai contacté par email dès que tu me l'as envoyé par MP. J'ai attendu de ces nouvelles tout le week-end, mais je n'ai rien vu dans ma boîte.

Peut-être que mon mail est arrivé dans les SPAMS ? Je t'envoie mon mail par MP, se sera plus simple

[Invité]

Ce matin j'ai reçu de nombreux nouveaux sprites et comme j'étais impatient de travailler avec, j'ai profité de ma pause déjeuner pour ajouter les deux modules (3 frames) et la nouvelle explosion qui possèdent 8 frames contre 4 pour l'ancienne !

Par contre, j'ai atteins les limites de la console, ça commence à ramer, mais je pense qu'avec quelques astuces, il est possible de préserver encore un grand nombre d'ennemis à l'écran.

[Stef]

Je pense que tu es encore loin des limites de la console Mais par contre peut être que tu rencontres les limites du sprite engine de SGDK dans une utilisation classique (et sans optimisation particulière). Rassures toi, il y a toujours des moyens d'optimiser

[Invité]

Oui je confirme, tu peux en mettre encore, j'utilise le SE avec Papi Reload, et je t'assures que je gère un paquet de trucs en gardant une fluidité correcte.
Faut optimiser maintenant, trouver les parties dans ton code qui sont "Cyclovores".
Bon courage !

[uran]

J'aime beaucoup la musique du jeu!
C'est de l'original pour ton jeu ou un rip?
Le système de vague d'ennemis est sympa, surtout quand un se sépare en plusieurs!
Je trouve juste que c'est un peu long entre deux vagues successives.

[Invité]

@uran merci, pour l'attente entre les vagues c'est normal, cela me permet de tester et de ne pas me faire rusher dessus ! Sinon pour la musique, non c'est un RIP, le temps que je puisse y intégrer des compositions originales.

@Stef @Vetea impressionnant si on peut utiliser plus de sprites, car bon, là où sa rame, je trouve qu'il y a déjà pas mal de sprites quand même ! Par contre j'ai ajouté les deux modules pouvant tirer autant de bullets que le joueur, ça ralenti direct le framerate ! Du coup, j'ai fais mes tests avec un écran vide :)

[Invité]

Excellent avec les modules, ça sent le R-Type Like de qualité !!
Et puis quel talent ce graphiste ... Faudra me le présenter.

Astuce pour réduire la charge en modifiant ton Gameplay :
- Introduit une notion de Chauffe Laser, c'est à dire que si tu t'excites trop sur le bouton tir, ça coupe le tir direct !
Ca te permettra de faire des tirs en rafales, pas plus de 4 5 boulettes, tu fais des cycles comme ça.
Car ici, c'est du continu, normal que ça rame, avec en plus le calcul de collision, etc ... ^^

Après, tu auras certainement à faire des traitements de collisions par Bloc, et non sur la totalité des projectiles tirés. Ou sinon sur 1 frame sur 3, etc ... Tu as plein d'astuces !
Et bien sûr, privilégie la puissance du C avec ses pointeurs de structures, de cette manière tu fera appel à de l'adressage mémoire plus rapide.

Bon courage !!

[Invité]

@Vetea encore merci ! Oui, je trouve qu'il fait du très bon boulot et grâce à lui, le commence à ressembler à quelque chose, mais franchement, attends de voir les autres sprites qu'il m'a envoyé, c'est juste génial !

En fait, je voulais utiliser un autofire comme dans Thunder Force III, mais c'est clair que ça pompe pas mal de ressource dans mon jeu. Je ne sais pas comment les gars chez Techno Soft se sont débrouillé, j'ai l'impression que les tirs vont très vite, mais qu'il n'y en a pas tellement en fait.

Merci pour tes conseils d'optimisation, je vais essayer de commencer à les appliquer.

[Tryphon]

Peut-être mettre plusieurs boulettes dans un même sprite (si elles sont alignées)...

[Invité]

Hum je viens de vérifier, dans Thunder Force 3, c'est bien une bullet et j'en ai compté 8 à l'écran et 12 avec les deux modules. C'est clairement moins que moi avec mes 30 bullets. Je crois qu'ils ont trouvé le bon réglage entre quantité de bullets raissonnables et grande vitesse de déplacement.

Sinon l'idée d'aligner plusieurs bullets dans un sprite est plutôt pas mal, à tester !

Edit : en jouant avec la vitesse et le timing, je suis passé de 30 à 18 bullets ! Je vais voir ça sa ralenti !

[uran]

Sinon en jouant sur la persistance rétinienne, tu affiches un même sprite à deux endroits une image sur deux, du coup tu doubles le nombre affichés "à l'oeil".

[Stef]

Hum je viens de vérifier, dans Thunder Force 3, c'est bien une bullet et j'en ai compté 8 à l'écran et 12 avec les deux modules. C'est clairement moins que moi avec mes 30 bullets. Je crois qu'ils ont trouvé le bon réglage entre quantité de bullets raissonnables et grande vitesse de déplacement.

Sinon l'idée d'aligner plusieurs bullets dans un sprite est plutôt pas mal, à tester !

Edit : en jouant avec la vitesse et le timing, je suis passé de 30 à 18 bullets ! Je vais voir ça sa ralenti !

Tu mets le doigt sur le pourquoi de on a autant de shump rapide sur les vieilles consoles, ça permettait comme tu le fais remarquer, de limiter le nombre d'objets à gérer à l'écran, la grande vitesse augmente virtuellement l'impression d'action.
Perso je n'aime pas ce genre de shoots... je préfère les shoots un peu plus lents mais qui t'envoie une foule de choses à la tête... Super Aleste, R² et TF3 sont typiquement dans ce style de shoots rapides que je trouve très fades :-/ N'augmente pas trop les vitesses des objets, car tu risques de tomber dans le même travers et ça serait dommage je pense :-/

Sinon 30 bullets c'est beaucoup quand meme, ça bouffe quasi la moitié de ton budget sprites !
20 bullets amis + 20 bullets ennemis + 5 sprites pour ton player (gestion module, items...) + 20 sprites ennemis (boss compris) + 10 explosions / GFX / divers + 5 bonus pour HUD et autres.
Ca me semble une bonne répartition pour un shump... et déjà faut réussir à les gérer

[Invité]

[Invité]

@Stef effectivement j'ai revu à la baisse un peu le nombre de bullets, car je me suis rendu compte que même dans Thunder Force III y en  a pas autant. Dans la vidéo au dessus, je pense qu'il y en a déjà pas mal et ça devrait amplement suffire. Je vais donc suivre ton conseil, en évitant de vouloir "artificiellement" augmenter le nombre de sprites à l'écran.

Cette nuit, pendant mon sommeil, j'ai un peu visualisé le code dans ma tête et j'ai trouvé quelques petites améliorations me permettant de gagner en vitesse de calcul, c'est certain. De plus, je me dis que c'est une perte de puissance de vouloir détecter la moindre collision dès qu'un projectile rentre en scène. Je pense que je pourrais au préalable vérifier la distance entre un projectile et un ennemi avant de vérifier la collision. Je pense que cela devrait soulager un peu le processeur.

Hier, j'ai surtout constaté que ce n'est pas le nombre de sprite qui pose problème, mais tous les petits calculs. Ce soir, je m'occupe donc d'optimiser un peu le code en espérant que je pourrais afficher plus de sprites tout en préservant un affichage fluide.

J'en profiterais pour mettre les power up.

[Tryphon]

N'optimise pas le code trop tôt, ça a tendance à le rendre difficile à maintenir et modifier. Découpe bien les différentes unités de ton code pour pouvoir optimiser l'une sans casser les autres (plus facile à dire qu'à faire).

[TotOOntHeMooN]

Par contre, j'ai atteins les limites de la console, ça commence à ramer [...] j'ai revu à la baisse un peu le nombre de bullets, car je me suis rendu compte que même dans Thunder Force III y en a pas autant.

C'est certain que TFIII à coté c'est de la rigolage ! 

[Invité]

Ça me tracasse tellement cette histoire d'optimisation ^^

Mais sinon oui, tu as raison, je vais me contenter de bien découper chaque tâche et de ne pas calculer en boucle chaque collision.

J'aurais aimé faire tourner les modules autour du vaisseau, mais j'avoue avoir du mal à retranscrire ce mouvement dans le code.

[Tryphon]

Détache bien la partie détection des collisions.

Il y a plusieurs façons de tester les collisions :

tu peux créer une liste d'objets amis et une liste d'objets ennemis, et tester chaque objet de la première avec chaque objet de la deuxième

tu peux découper ton écran en petites cellules de x*x pixels (typiquement, x = 32), tenir pour chaque cellule une liste des objets amis s'y trouvant, et pour chaque ennemi ne tester que les collisions avec les amis qui se trouvent dans la même cellule que lui

tu peux reprendre l'idée ci-dessus mais faire des découpages de taille variable (technique des quadtree)

[fanoplusplus64K]

Le partitionnement est effectivement un moyen de discriminer certaines collisions et gagner en temps (attention tout de même à ce que les tests de discrimination ne soient pas plus chers que le code qu'on chercher à rejeter).
Après, j'ai envie de te dire qu'avant de penser à optimiser son code, il faut déjà optimiser ses structures de données et aussi l'algorithme.

J'aurais aimé faire tourner les modules autour du vaisseau, mais j'avoue avoir du mal à retranscrire ce mouvement dans le code.

Une simple table de n valeurs (perso je mettrai typiquement 256) avec un offset en X et en Y (sur 8 bits signés c'est parfaitement suffisant) doit faire l'affaire.

[Stef]

@shingosama> Comme on te l'a conseillé plus haut, optimise déjà tes structures et ton code dans le sens de le rendre le plus simple et lisible possible, en utilisant des algos efficaces... tu verras que tu gagneras probablement déjà un peu.
Les optimisations fines sur la performance sont à faire à la fin, ça risque de rendre ton code un peu moins lisible donc ce n'est pas une bonne chose de s'y attaquer de suite.

Sinon pour la rotation de tes modules, tu as une table sin dans SGDK (dans l'unité maths.h tu devrais trouver ça)

[Spirale]

Encore un sujet avec des infos intéressantes sur la programmation.

Concernant le projet, il semble bien parti pour aboutir vu ta motivation et le travail du graphiste.
Dans ces projets homebrew, j'ai l'impression (mais peut-être que je me trompe) que le point faible est la musique, en effet, il me semble difficile de trouver quelqu'un pour faire des musiques originales.

En tout cas, bonne continuation dans ton projet. Je prendrais plaisir à suivre son avancement.

[drludos]

Woaw, bravo Shingosama, la dernière vidéo envoie du lourd !

J'aime beaucoup le rendu des explosions, avec le fait qu'il faille tirer plusieurs fois sur les ennemis on sent bien les "impact". Les waves d'ennemis qui bougent à l'écran rendent super aussi, tu as vraiment une bonne base.

La vitesse du jeu / des tirs semble bien aussi, mais il faudrait avoir la manette en main pour mieux en juger

Il ne te manque plus maintenant qu'à rajouter un boss, et tu auras déjà une bonne ébauche de premier niveau ! Je suis impressionné de la vitesse avec laquelle tu as avancé, d'autant plus que visiblement c'est ton premier projet homebrew

[Metalik]

Concernant le projet, il semble bien parti pour aboutir vu ta motivation et le travail du graphiste.
Dans ces projets homebrew, j'ai l'impression (mais peut-être que je me trompe) que le point faible est la musique, en effet, il me semble difficile de trouver quelqu'un pour faire des musiques originales.

-Le point faible c'est surtout l'abandon. Et il arrive souvent simplement quand les choses se complique. C'est pour ça que les projets abouti qui ont un minimum de gueule son rare.
-Pour la musique, je ne sait pas. Pourtant c'est pas les musiciens qui manque et beaucoup semble encore s'amuser avec le chipset de la Megadrive.

https://www.youtube.com/user/Groovemaster303X/videos

https://www.youtube.com/results?search_query=sega+genesis+fm

[Invité]

@Spirale merci pour tes encouragements. C'est vrai que le graphiste assure, ce qui permet au jeu d'être un minimum attrayant. Pour le musicien, j'en ai un sous la main, mais pour le moment j'attends que le projet soit bien plus avancé pour lui demander de travailler sur les compositions. L'idéal serait qu'il puisse réaliser la musique une fois le jeu pratiquement terminée afin de s'inspirer de son ambiance et de son univers. Il faut vraiment que les musiques s'accordent avec le jeu.

@drludos merci également pour les compliments. C'est pas trop mal pour le moment, en tout cas bien plus que mes premières vidéos, mais il y a encore quelques trucs un peu difficile que j'aimerais implanter. Pour le boss, j'ai imaginé le vaisseau arriver à une plateforme métallique où le joueur affronte un canon au dessus de lui se trouve un tunnel/passage où déferlent des unités ennemis. Le joueur devra donc gérer les vagues d'ennemis et les tirs du canon. Il y aura certainement des petits canons positionnés sur la plateforme qui tirons des missiles en direction du joueur.

@Metalik malheureusement tu as raison et c'est pour cela que je m'efforce de rester sur un shmup classique, simple et efficace. Je ne pars pas sur des effets "bling-bling" comme dirais @Tryphon et je n'essaie pas de révolutionner ou de copier une technique difficile à reproduire. Je vais plutôt me concentrer sur l'ambiance et le gameplay plutôt que d'essayer dans mettre plein la vue.

Sinon j'ai reçu hier un gros sprite sheet comprenant une multitude de bullets très réussi ! J'ai testé rapidement deux bullets en ajoutant une fonction permettant de switcher entre les deux, c'est juste génial et très agréable visuellement.

Bizarrement, lorsque je switchais, j'ai remarqué que même les bullets activent étaient remplacées. Pourtant dans mon fonction getFreeBullet(), je ne récupère qu'un bullet libre, c'est à dire inactif. Bref, je suis parti voir comment Thunder Force 3 se comportait et dans les faits, les bullets actives sont annulées / effacées avant d'être remplacées. J'ai donc appliqué cette technique qui est beaucoup plus propre.

[Invité]

Petite illustration en gif :)

[Stef]

Ca fait un peu bizarre je trouve, tu es sûr que TF3 fait de cette manière ?
Une manière classique c'est de bloquer la nouvelle arme tant qu'il reste des anciens bullets à l'écran, ça pénalise le changement d'arme (latence) mais ça peut être un argument stratégique