CPC Rulez :: Consulter le sujet

pour la "Beast" , j'ai déjà une trentaine de sprites différents (gauche + droites) avec des formes différentes + une cinquantaine de 'monstres' avec toutes des formes différentes
et en +, les animations font que le contenu des sprites change bcp.

j'avais pensé à faire un carré de test de collision plus petit que la taille du sprite réel :

en gros j'utilise cela pour voir si il y a collision entre les sprites et la BEAST

SPR_X, SPR_Y
SPR_WIDTH, SPR_HEIGHT

pour chaque sprite le X et le Y bouge avec le mouvement
SPR_WIDTH est fixe et égale au nombre de sprite * la taille en fonction du résolution x du sprite (Z)
SPR_HEIGHT est fixe et égale au nombre de sprite * la taille en fonction du résolution y du sprite (Z)

si on continue sur la beast, elle fait 2 sprites de large et 3 de haut en résolution mode 1.

donc j'ai pensé à réduire le carré de test à une taille inférieure (ici dans mon exemple 3 lignes en Y en haut de moins et 3 colonnes en X de moins en large ):
COL_X = SPR_X + 3
COL_Y = SPR_Y + 3
COL_WIDTH = SPR_WIDTH - 3
COL_HEIGHT = SPR_WIDTH - 3

pour la beast, cela ne va pas trop mal... sauf quand on s’accroupie ou on saute !
Et cela se gâte et devient une usine à gaz, car le contenu des sprites des monstres change bcp en fonction des animations et du coup on test des lignes vides...même avec cette méthode...

ou sinon, je dois rajouter pour chaque animation de changer le COL_X, COL_Y, COL_WIDTH, COL_HEIGHT ce qui devient très soulant car cela veut dire que je doit déterminer pour chaque sprite ces valeurs soit au moment de la définition du sprite soit au moment ou on rajoute le sprite sur l'écran !

donc en fait, j'ai l'impression de devoir faire une usine à gaz en z80 pour éliminer de la détection de collision juste les lignes/colonnes qui sont vides des sprites !

je me demande d'ailleurs en écrivant cela : comment marche le sprite collision hardware de l'amiga ou sur les consoles !?
--> peut-être que cela pourrait m'inspirer !?

Auteur :	Lone [ 07 Jan 2019, 10:25 ]
Sujet du message :	Re: ASIC Powaaa !
C'est très impressionnant ! Vivement une "vrai" version CPR que l'on puisse y goûter sur un vrai CPC+ ! Pour le problème de joystick sur Sugarbox, je réfléchis (parmi d'autres choses) à recoder une partie des contrôles de manière à diminuer l'input lag (ainsi que ce genre de problèmes). Ca arrivera sans doute un jour ou l'autre !

Auteur :	Hwikaa [ 08 Jan 2019, 09:42 ]
Sujet du message :	Re: ASIC Powaaa !
C'est bluffant. Un collègue qui zieutait sur mon écran à même cru qu'il s'agissait de la version Amiga !

Auteur :	norecess464 [ 08 Jan 2019, 14:15 ]
Sujet du message :	Re: ASIC Powaaa !
Chouette boulot. Bravo !!!

Auteur :	TotO [ 10 Jan 2019, 11:12 ]
Sujet du message :	Re: ASIC Powaaa !
Je n'avais pas fait attention au topic (peut-être le nom), cependant je te souhaite bon courrage car c'est un sacré projet ! Probablement peux-tu utiliser les sprites pour gagner en couleurs (voir finesse) sur des éléments d'interséquences comme la corde et le feuillage du puit par exemple. Perso, je ne suis pas fan du jeu qui passé la vitrine technique graphique et audio sur Amiga, à un gameplay plutôt médiocre qui mériterait d'être retravaillé.

Auteur :	dlfrsilver [ 14 Jan 2019, 11:22 ]
Sujet du message :	Re: ASIC Powaaa !
le gameplay doit pouvoir être bien amélioré, puisque le problème de gameplay un peu raide de la version Amiga est provoqué par le mirroring en software du sprite principal, fait au 68000. Comme l'a dit Martin Edmonson, le jeu n'était pas très bien programmé (en dehors des effets, des 8 palettes de 16 couleurs réparties sur différentes zones de l'écran).

CPC Rulez https://cpcrulez.fr/forum/

ASIC Powaaa ! https://cpcrulez.fr/forum/viewtopic.php?f=6&t=6141	Page 3 sur 3

Auteur :	Megachur [ 19 Jan 2019, 08:27 ]
Sujet du message :	Re: ASIC Powaaa !
Merci à Lone, Hwikaa, norecess464, TotO pour votre soutien moral en réponse à mon précédent post sur ce forum ! Peut-être que personne ne le sait, mais il y a là déjà plus de 100h de boulot sur le code, les rips et conversions des graphismes de l'amiga, etc. Au départ, j'ai vraiment pris ce jeu en référence qui est un vitrine technologique pour l'amiga de ce qu'en a dit l'auteur... Et je me souviendrai toujours la première fois que j'ai vu un amiga 500 avec Shadow Of The Beast, Xenon 2 et Battle Squadron le même jour -> ouuuaaaah ! J'ai fait cela au départ aussi comme une démo technologique pour voir ce qu'on pouvait faire avec un CPC+/GX4000 ! ce qu'apportait les nouveautés de l'ASIC par rapport à un old notamment car je n'avais jamais eu la chance de coder dessus ! Je pense d'ailleurs comme vous, vu l'ampleur et la durée de ce projet, que si je veux arriver à sortir quelque chose un jour, il vaut mieux privilégier le 'gameplay" et le plaisir du jeu ! Quitte à ce que dans un deuxième temps, un graphiste chevronné fasse une version/adaptation plus 'CPC' des graphismes amiga que j'utilise pour l'instant et qui sont très peu modifié. Comme évoqué dans mon poste précédent, j'arrive à certaines limites concernant l'ASIC : - la gestion des collisions reste soft car l'ASIC ne l'offre pas en natif... pour l'instant j'ai codé uniquement la collision des sprites mais pas au pixel prêt : toute suggestion / aide à ce sujet est la bienvenue ! -> utiliser un MASK pour chaque sprite me semble énorme en mémoire de cartouche ! sur la zone de collision : utiliser un test pour vérifier chaque pixel différent de zéro et qui touche un autre pixel d'un autre sprite me semble très consommateur en temps cpu z80 !? -> autre technique !? - on utilise bcp de mémoire de la cartouche juste car l'ASIC ne sait pas faire une transfo horizontal d'un sprite pour gérer le même sprite gauche / droite ! je trouve bizarre que les ingénieurs de chez Amstrad n'utilise que 4 bits pour les données des sprites et qu'il n'ait pas prévu juste un shit de 4bits pour utiliser ou inverser les 4bits de poids fort pour changer le contenu d'un sprite.... alors que le z80 ne sait envoyer que 8bits à chaque fois sur un octet de mémoire ! - le son : j'ai compris le principe du DMA mais j'ai pas encore eu le temps de coder cela avec la conversion du player original de David Whitaker et de toutes les musiques originales (ce qu'a fait Overflow dans la Eerie Forest). Je m'interroge sur la conversion des samples (version DMA Amiga) vers le CPC+, sur la place que cela va prendre en mémoire. Doit-on limiter la gestion de la musique quand on a 128ko par exemple pour faciliter les transferts avec la cartouche et les contraintes d'être dans la ram principal 64ko lors de l'exécution des DMAs ? Peut-on compresser les samples sur la cartouche pour gagner de la place, les décruncher dans les 64ko supplémentaires (soit en 1 fois ou en plusieurs fois) avant de les copier en RAM (pour l'instant je n'utilise pas la RAM de #0040 à #3fff)... bref, très peu de codeurs CPC+ sont passés par là, le chemin est encore long pour moi si je n'ai pas d'aide... - je n'ai pas eu de réponse sur le fond de mon précédent post, ce qui renforce mon impression d'être seul face à la BEAST ASIC que ce soit techniquement ou pour choisir comment contourner le technique quand ce n'est pas possible de faire comme l'original sur CPC+ ! bref... j'espère ne pas me démotiver dans le temps... pour l'instant, de toute façon, le projet est en pause car je n'ai plus bcp de temps libre en ce moment... je suis donc preneur de toute aide / conseil / soutien !

Auteur :	Lone [ 19 Jan 2019, 12:21 ]
Sujet du message :	Re: ASIC Powaaa !
La même que toi : J'ai toujours eu une tendresse particulière pour Shadow of the Beast et Battle squadron, notamment parce que c'est sûrement deux des premiers jeux que j'ai lancé sur la machine (faut dire que ça faisait un sacré écart quand on venait du cpc, visuellement parlant !) Côté aide, je ne vois par contre pas trop ce que je peux t'apporter (à mon grand regret) : Si j'ai au final bien compris comment marche l'asic et compagnie, je n'ai pas l''expérience du code efficace en ce domaine. Par contre, tu peux compter sur mes encouragements !

Auteur :	TotO [ 19 Jan 2019, 12:27 ]
Sujet du message :	Re: ASIC Powaaa !
Salut ! Des musiques samplés in-games, c'est chaud... Juste dans Eerie Forest, ça prend les 3/4 de la cartouche pour un thème ! Le code source n'avait-il pas été mis à dispo, pour permettre de t'aider dans ton entreprise ? Concernant les collisions, je pense que tu peux te contenter de tester quelques points bien placés et non la totalité. SotB, c'est la plaine que sert de hub "prétexte" (vitrine techno) pour déservir les différents niveaux plutôt banals. Je pense que le vrai challenge réside dans la réinterprétation de ces niveaux pour qu'ils soient intéressant à jouer. Concernant la mémoire, normalement si tu as tes données en ROM, tu vas les pager sans avoir besoin d'utiliser les 64K de RAM en plus. Enfin, l'intérêt étant de pouvoir tourner sur une GX4000, dans le cas contraire, limité au 6128plus.

Auteur :	marcel [ 19 Jan 2019, 14:10 ]
Sujet du message :	Re: ASIC Powaaa !
Megachur a écrit : Comme évoqué dans mon poste précédent, j'arrive à certaines limites concernant l'ASIC : - la gestion des collisions reste soft car l'ASIC ne l'offre pas en natif... pour l'instant j'ai codé uniquement la collision des sprites mais pas au pixel prêt : toute suggestion / aide à ce sujet est la bienvenue ! -> utiliser un MASK pour chaque sprite me semble énorme en mémoire de cartouche ! sur la zone de collision : utiliser un test pour vérifier chaque pixel différent de zéro et qui touche un autre pixel d'un autre sprite me semble très consommateur en temps cpu z80 !? -> autre technique !? Citer : Concernant les collisions, je pense que tu peux te contenter de tester quelques points bien placés et non la totalité. J'allais te faire un peu la même réponse, pour les collisions ça dépend énormément du gameplay ET des déplacements des sprites Pour mon petit jeu de bulle je fais une détection presque au pixel avec du code généré parce que l'ingame en a besoin et ça prend assez peu de temps. En gros pour chaque étape d'animation, j'ai une routine de détection de collision associée qui est en ROM cartouche. Voir vidéo si l'idée te plait https://www.youtube.com/watch?v=q2KEhFaPFbw

Auteur :	Megachur [ 19 Jan 2019, 14:55 ]
Sujet du message :	Re: ASIC Powaaa !
@Lone: merci pour ton soutien moral sans faille @TotO: le jeu marche actuellement sans problème sur une gx4000 avec le C4CPC... Il utilise 2x17 ko pour l'affichage et 16ko de code environ en mémoire principale et reste de &0040 à &3fff de libre + les 64kos supplémentaires si on est sur un 6128 +. je n'ai pas pu le tester sur un 464+, mais j'imagine qu'il doit marcher aussi sur celui-ci ! pour l'instant, j'ai diffusé que des vidéos pour ne pas gâcher le bonheur de le découvrir... vous n'avez pas vu les screens d'intro encore par exemple ! @marcel (roudoudou inside) : j'ai revu ton tuto mais je n'y trouve pas vraiment ce qui m'intéresse... ici tu as une bulle pour laquelle tu as un sprite représentant l'intérieur qui te permet de trouver facilement la collision avec le décors... c'est super bien pensé (si si ) mais cela se complique dans mon cas... Code : pour la "Beast" , j'ai déjà une trentaine de sprites différents (gauche + droites) avec des formes différentes + une cinquantaine de 'monstres' avec toutes des formes différentes et en +, les animations font que le contenu des sprites change bcp. j'avais pensé à faire un carré de test de collision plus petit que la taille du sprite réel : en gros j'utilise cela pour voir si il y a collision entre les sprites et la BEAST SPR_X, SPR_Y SPR_WIDTH, SPR_HEIGHT pour chaque sprite le X et le Y bouge avec le mouvement SPR_WIDTH est fixe et égale au nombre de sprite * la taille en fonction du résolution x du sprite (Z) SPR_HEIGHT est fixe et égale au nombre de sprite * la taille en fonction du résolution y du sprite (Z) si on continue sur la beast, elle fait 2 sprites de large et 3 de haut en résolution mode 1. donc j'ai pensé à réduire le carré de test à une taille inférieure (ici dans mon exemple 3 lignes en Y en haut de moins et 3 colonnes en X de moins en large ): COL_X = SPR_X + 3 COL_Y = SPR_Y + 3 COL_WIDTH = SPR_WIDTH - 3 COL_HEIGHT = SPR_WIDTH - 3 pour la beast, cela ne va pas trop mal... sauf quand on s’accroupie ou on saute ! Et cela se gâte et devient une usine à gaz, car le contenu des sprites des monstres change bcp en fonction des animations et du coup on test des lignes vides...même avec cette méthode... ou sinon, je dois rajouter pour chaque animation de changer le COL_X, COL_Y, COL_WIDTH, COL_HEIGHT ce qui devient très soulant car cela veut dire que je doit déterminer pour chaque sprite ces valeurs soit au moment de la définition du sprite soit au moment ou on rajoute le sprite sur l'écran ! donc en fait, j'ai l'impression de devoir faire une usine à gaz en z80 pour éliminer de la détection de collision juste les lignes/colonnes qui sont vides des sprites ! je me demande d'ailleurs en écrivant cela : comment marche le sprite collision hardware de l'amiga ou sur les consoles !? --> peut-être que cela pourrait m'inspirer !? j'ai trouvé cela pour la collision hard sur amiga : http://amigadev.elowar.com/read/ADCD_2. ... e015B.html dommage que notre ASIC ne sache pas le faire (ou alors c'est bien caché dedans !?) !

Auteur :	marcel [ 19 Jan 2019, 16:23 ]
Sujet du message :	Re: ASIC Powaaa !
Bah en mixant nos méthodes, tu pourrais attribuer à chaque sprite une routine qui teste différents carrés La recopie d'un sprite s'occupant aussi de poker la bonne routine pour tester la collision de ce sprite, ça fait un octet (ou deux) en plus par sprite Tu aurais le carré complet, le petit carré au centre, le petit carré en haut, en bas, à droite, à gauche, le moyen carré à gauche/droite, etc. Tu vas trouver ton bonheur, sisi Ou alors faire des boites par animation mais là, il va rapidement te falloir un outil qui automatise cette étape!!!

Auteur :	Kris [ 19 Jan 2019, 17:43 ]
Sujet du message :	Re: ASIC Powaaa !
Hello Megachur, Pas pu te soutenir niveau gfx par manque de temps (moi aussi), par contre , ça à l'air d'avancer assez vite et c'est vraiment agreable à regarder. Bon courage pour la suite.

Auteur :	Megachur [ 19 Jan 2019, 18:15 ]
Sujet du message :	Re: ASIC Powaaa !
Kris a écrit : Hello Megachur, Pas pu te soutenir niveau gfx par manque de temps (moi aussi), par contre , ça à l'air d'avancer assez vite et c'est vraiment agreable à regarder. Bon courage pour la suite. Merci Kris de ton soutien !

Auteur :	Princesse Mariana [ 07 Avr 2020, 12:06 ]
Sujet du message :	Re: ASIC Powaaa !
Si, si, ils ont osé .... Citer : getting there and starting to feel pretty solid at last ! may start letting out playable versions soon

Page 3 sur 3	Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/