Timing sur la synchro ??? Pas spéciallement. Tout réside dans le fait de ne pas ce manger le balayage. Pas spéciallement difficile et de plus on peux tout de même faire du flipping ce qui résoud le problème du moment qu'on reste a 50Hz. Au final ce qui prend du temps, c'est l'affichage des sprites soft (soit pas grand chose, juste une bande d'un octet toutes les 2 frame si on est au pixel); le tir (ca va pas chier lion non plus) et le gros morceau des collision qui s'il est bien géré ne prend pas grand chose non plus. Y'a plus qu'a jouer une musique SID; faire des rasters partout... Ca rentre à 50Hz sans problème.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Oui, m'enfin la bande, ça bouffe quand même près de 2000nops
Euh pourquoi des rasters ? par contre si j'ai encore un peu de temps à la fin pour caser un petit startfield, je dirai pas non Par contre pour le son, c'est important qu'il soit en adéquation avec le reste comme dans certaines démos (e.g. S&KOH ou DTC).Sinon, je pensais utiliser Starkos.Mais pourquoi du SID ? c'est un format qui vient du C64 , ça ?
Ben, je dirai qu'au contraire les collisions c'est assez délicat parce que difficilement optimisable du fait que c'est du conditionnel et je vois pas comment utiliser des tables ou du code pré-compilé. Toujours est il que j'ai découvert un bouton que j'avais jamais testé sous Winape : un compteur de NOPs ! c'est génial car ça me permet de voir où mon code pêche.Actuellement, il me reste à peu près 5000nops en charge, ça fait pas bien lourd.
Megachur a écrit :
Par contre, peut-être que pour le keyboard test et pour les sprites, cela peut être intéressant d'être en 50hz si la jouabilité en patie à 25hz...
Oui je crois que ça va en finir là, même si la jouabilité ne pâtit pas du 25Hz, c'est quand même sympa d'avoir les sprites qui bougent de manière bien fluide.
MacDeath26 a écrit :
Et bon, comparant du 50Hz avec les 4 MHz du Z80...même si d'autres composants ralentissent le process, on a probablement de la marge.
Bah, mine de rien , chaque tâche prend quand même un sacré paquet de temps à notre pauvre Z80.
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Non, l'optimisation vient en premier en réfléchissant directement a la façon la plus rapide de faire les choses. En dernier c'est l'optimisation des routines en elles mêmes et quand bien même, autant faire bien du premier coup que d'y revenir plus tard.
Bon je suppose que y'a pas encore les contrôles et que les graphismes sont pas définitifs... sinon c'est sans doute un bon début...à voir bien sur quand les éléments de gameplay seront plus finis...lol.
Comptes tu user des sprites hards ? Quelles sont les dimensions de l'écran de jeux en fait ? Et les dimensions des sprites ? Et le système des collisions ? Je suppose que tu vises la version 128Ko de Ram... Et pour le son, le DMA du plus ? théoriquement c'est alors l'Asic qui gère mais ça doit toujours peser un poil sur le CPU (les pros d'ici sauront le dire) Veux tu mettre de la zic pendant les levels ou seulement en "intro" ou entre les levels ?
Envoies moi en tout cas comme convenu les trucs pour que je puisse me pencher sur du design. N'omet aucun détail stp dans ton mail.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
MacDeath26 a écrit :
Comptes tu user des sprites hards ? Quelles sont les dimensions de l'écran de jeux en fait ? Et les dimensions des sprites ? Et le système des collisions ? Je suppose que tu vises la version 128Ko de Ram... Et pour le son, le DMA du plus ? théoriquement c'est alors l'Asic qui gère mais ça doit toujours peser un poil sur le CPU (les pros d'ici sauront le dire) Veux tu mettre de la zic pendant les levels ou seulement en "intro" ou entre les levels ?
Oui, ce sont déjà des sprites Hard, le format de l'ecran c'est 48*20 soit 192*160 pixels mode 0, le système de collision c'est point/AABB pour les tirs/projectiles, AABB/AABB pour les objets et pour les cas spéciaux c'est un mix. Il utilise déjà 128k sachant que les sprites Hard et l'écran occupent la même position en mémoire (#C000).Pour la zic, ça sera vraisemblablement STarkos , d'autant plus que le source du player est maintenant dispo
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Okay donc en effet l'écran est redimensionné moins haut mais plus large...
Pour les Sprites Hards, tu les utilise tous ? Ils serviront pour le joueur ou pour tous les vaisseaux à l'écran ?
Sont ils "magnifiés" ? (aggrandis donc...) équivalents Mode 0 je suppose, euh, sont ils aussi x2 en hauteur ? (donc des gros pixels en "2x2")
Sinon je ne peux que te conseiller de bien faire attention aux tirs si ils sont du type "points"... On se souvient tous de SlapFight (enfin moi oui en tout cas) avec les tirs adverses minuscules, blancs et donc indivisbles la moitiés du temps.
Idéalement il me semble que réserver une Encre rien que pour les tirs , voire 2 histoire de différencier les tirs Joueurs et tirs CPU, peut le faire sachant que 14 couleures peuvent suffire. ça permet idéalement de mettre des couleurs qui flashent et sont bien visibles alors par rapport au décors.
Bon hélas ton histoire de collision je n'y comprend rien en fait. Je vais me renseigner donc.
Vises tu le multiplayer ? Et l'usage de 2 boutons ?
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
BDCIron a écrit :
Non, l'optimisation vient en premier en réfléchissant directement a la façon la plus rapide de faire les choses. En dernier c'est l'optimisation des routines en elles mêmes et quand bien même, autant faire bien du premier coup que d'y revenir plus tard.
je crois que si on devait inventer la caricature que tu joues ici, on y arriverai pas mieux que la réalité !
Il ne faut optimiser que quand le code 'fonctionne' déjà, sinon on ne sais pas si c'est à cause de l'optimisation ou non que cela ne fonctionne pas...
on voit que tu n'as pas fait d'étude d'info (ou alors de loin ) ! Mais bon, si c'est ce que tu préfères, tu es libre de mettre 100 fois plus de temps pour coder, c'est ton 'blem!
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
MacDeath26 a écrit :
Pour les Sprites Hards, tu les utilise tous ? Ils serviront pour le joueur ou pour tous les vaisseaux à l'écran ?
Non , 4 sont reservé pour le joueur, le reste pour les enemis et l'allocation est dynamique.Seules les explosions sont en *2/*2 sinon c'est du mode 0, faut que ça soit harmonieux avec le reste.
MacDeath26 a écrit :
Sinon je ne peux que te conseiller de bien faire attention aux tirs si ils sont du type "points"...
Les boulettes enemies utilisent spécifiquement la couleur 15 qui pulse.C'est parce que j'ai corrigé à que la variation de couleur n'y est pas.Quand aux tirs du héro , il utilisent leurs propres couleurs qui changent fonction de l'option.
MacDeath26 a écrit :
Bon hélas ton histoire de collision je n'y comprend rien en fait. Je vais me renseigner donc.
Désolé c'est plus rapide d'écrire AABB que Axis Aligned Bounding Box qui est d'ailleurs un peu pompeux pour désigner des simples boites de collisions rectangulaires/carrées.Celle du joueur est d'ailleurs plus petite que le sprite mais pas trop (on est pas dans un manic hein)
MacDeath26 a écrit :
Vises tu le multiplayer ? Et l'usage de 2 boutons ?
Non , pas ici, il faudrait que j'accapare encore au minimum 2/3 sprites pour le second joueur, ce qui réduirait le nombre dispo pour le reste à 9/8.Sinon oui,pour un contrôle à la R-Type il faut deux boutons, d'ailleurs je me cherche une manette Master System pas cher parce que celle du + à part te bouffer les doigts...
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Non, l'optimisation vient en premier en réfléchissant directement a la façon la plus rapide de faire les choses. En dernier c'est l'optimisation des routines en elles mêmes et quand bien même, autant faire bien du premier coup que d'y revenir plus tard.
je crois que si on devait inventer la caricature que tu joues ici, on y arriverai pas mieux que la réalité !
Il ne faut optimiser que quand le code 'fonctionne' déjà, sinon on ne sais pas si c'est à cause de l'optimisation ou non que cela ne fonctionne pas...
on voit que tu n'as pas fait d'étude d'info (ou alors de loin ) ! Mais bon, si c'est ce que tu préfères, tu es libre de mettre 100 fois plus de temps pour coder, c'est ton 'blem!
Je crois surtout que tu ne cherches pas a comprendre ce que je dis... Il y a optimisation dans la façon de faire et optimisation du code en lui même !!!
Quand au fait que j'ai fait des études en info ou pas, cela me fait bien rire ??? T'as fait quoi toi ??? Au lieu de venir me casser les couilles avec ce genre de commentaires, tu ferais mieux d'aller coder quelque chose de correct pour une fois.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
tu sais, tu peux provoquer les autres en étant agressif mais cela ne fait pas bien avancé la réflexion.
quand tu codes, tu as généralement deux grands étapes :
1 - ce que tu veux faire avec ton code -> ce qui abouti à un algorithme que tu peux optimiser à loisir 2 - l'implémentation, généralement propre à la machine (hardware) et au système d'exploitation (ici pas de risque puisqu'on utilise pas l'amdos et les vecteurs systèmes)
et l'implémentation (ou programmation) doit se faire en plusieurs étapes : a - le code fonctionne (et est conforme à l'algo) b - si besoin, on optimise (là, toute la qualité d'un bon codeur est au rendez-vous !) Pour cela, tunning du code et recherche des morceaux de codes qui prennent bcp de temps et on commence par optimiser ceux là en premier, etc... a - on est vraiment très bon et on a de l'expérience et a & b se sont fait quasi en même temps...
Donc, je ne voulais pas de froisser avec tes études, mais si tu cherches à optimiser tout de suite et tout ton code -> tu perds du temps et de la productivité (et sache qu'en terme d'étude j'ai une maîtrise bac+4 mais que ce n'est pas là le débat).
et tu peux me dire ce que je n'ai pas codé de correct ? si tu penses à la démo "maurice aime les bobs", et la valeur du r0 CRTC utilisée -> saches que j'ai utilisé le hardware du cpc correctement -> si certains moniteurs sifflent ce n'est pas de ma faute... et c'est bien dommage que je n'ai pas de CPC plus pour avoir pu tester cela avant dessus... mais personne n'est parfait
Ne soit pas agressif mais joue ton rôle de conseil envers cette nouvelle génération de codeur... qui se défonce sur des ordis de 25 ans d'âge qd même !!!
Ce que je dis depuis de début c'est justement qu'il n'y a pas que l'optimisation de routines et que le plus important est de bien concevoir son prog dès le debut. L'optimisation c'est surtout dans la façon de penser la chose. Si dans un jeu tu te contentes de regarder ce que tu dois faire et le faire betement tu vas droit au casse pipe !!! Bien au contraire, sur une machine comme le CPC il faut dès le debut refléchir a la méthode et à l'ordre des choses. La façon dont Fano semble vouloir gerer ses collisions depuis le debut est loin d'être bonne par exemple, ca va lui prendre un max de CPU de tester alors qu'en y réflechissant un peu il y a bien plus simple et surtout bien plus rapide... Avant de coder quoi que ce soit j'ai toujours eut l'habitude de réfléchir assez longtemps sur l'organisation de la RAM et de divers éléments. Cela m'évite de me crouter lamentablement. Pour ce qui est du reste, je ne critique pas ton unique démo (et non tu ne respectes pas forcement le hardware en augmentant R0... Un CPC c'est un clavier ET un ecran... Les excuses à la Chany comme quoi ca passe chez lui donc c'est bon sont a éviter... T'es pas à 50Hz... ), je critique plutôt le fait que ta démo soit unique... Montre nous ce que tu sais faire autrement qu'en nous montrant tes boules
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Le pire c'est que sur le fond vous êtes pas loin, par contre la forme
On a plus 14ans, on a passé l'age de pisser du code, on réfléchit un peu maintenant (euh....) pis de toute façon sur le CPC t'as intêret d'y penser car les ressources sont limitées (hors de question d'alloc à tout bout de champ et après dire à l'user qu'il faut 2Go de RAM ou d'implementer comme un porc et dire après qu'il faut un super processeur dernier cri )
De toute façon on a le temps de le penser son prog, vu le peu de temps qu'on a pour l'implémenter (faites des gosses !)
Sinon, je ne calcule les boites qu'une fois par cycle quel que le nombre de tests , si tu as une méthode plus rapide pour la collision je suis preneur.
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 85 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum