Avec ce beau mois de Mai avec ses week ends rallongés, j'ai eu un peu le temps d'avancer dans mon projet.

Par contre, n'ayant toujours pas trouvé de CPC+ dans des conditions convenables (budget serré+pas loin) et mon chineur ne m'en ayant toujours pas dégoté , je suis bien embeté pour voir si mon code marche.

Est ce que quelqu'un équipé d'une 6128+ pourrait me tester le disque joint (run"loader) sur winape et 6128+ et me dire si il constate des différences.C'est encore très loin d'avoir la tête définitive (une pré-alpha?) mais les parties de code qui à mon sens pourraient poser problème sont là.

Merci d'avance

PS:euh dernier détail, le vaisseau se contrôle au joystick et le bouton 1 permet de tirer.

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Je test ca tout de suite.

Tu n'es pas a 50Hz ca flashouille. En fait rien ne marche... Pas de scroll ni de vaisseau. Plantage probable dès le debut.

putain j'ai les boules ! je m'en doutais un peu depuis que tu as parlé de timings différent sous Winape.
J'ai essayé de faire un petit fix en retirant les bidouilles avec R9, histoire de voir si ça peut venir de là.Vu que le prog attend justement les interruptions pour se synchroniser , il est possible que les modifs sur R9 affectent celles ci.
Les flashouilles dans le border c'est normal, vu que le prog tourne normalement à 25HZ/fps , ça me sert juste d'indication pour tester le timing de certaines routines.

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Hop ca marche ce coup ci. En revanche le scroll a 25Hz c'est très moche, passe a 50Hz.

Super ! merci Iron suis soulagé

La morale de l'histoire, faut pas déconner avec R9 si PRI sauf à avoir un + sous la main pour tester en live.

Bah pour le le 50Hz , le problème c'est que même en tirant de partout , je pense que ça le fera pas.Ca me ferait à peu près 9000nops pour traiter les sprites hard et softs et à peu près 10000 pour le jeu et l'alimentation du scroll.
Sachant que tout est loin d'être implementé comme par exemple les tests de collisions sprites/sprites/décors, mine de rien quand tu rapportes au nombre d'objets, ça pique.

En tout cas re-merci , ça m'a re-motivé

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Tu dois absolument passer a 50Hz. Si tu n'as déjà plus de cpu c'est que tes routines sont trop lentes (mais pourquoi donc lorsque l'on tire le CPU pris augmente ???) Réfléchis, trouve des méthodes plus rapide et fait du 50Hz. La machine est faite pour ca et du 25Hz serait décevant. Je t'encourage et peux t'aider (par mail, pas sur un forum).

le 25hz est très bien -> tu ferras une version spéciale pour BDCIron en 50hz juste avec un vaisseau, le décors et les boulettes pour qu'il soit content, c'est tout !!!

Bah c'est pas faute de compter mes NOPs, ce bout de prog tourne largement en 50HZ , c'est juste que je me laisse de la réserve pour la suite qui va être nettement plus coton avec l'implémentation des sprites soft.Passer les sprites en 50HZ ne poserait pas de problème par contre le scroll en 1 pix/frame , c'est nettement trop rapide surtout pour la longueur des niveaux (12K/20 à peu près 614 colonnes soit 12,8 écrans), d'ailleurs comme tu as pu voir, on arrive (trop) vite au bout.

Les couleurs dans le border correspondent justement aux sprites soft (projectiles enemis+tir joueur), violet foncé pour la restitution du fond violet clair pour le dessin, sachant que ce n'est que le dessin, la gestion et le calcul des adresses est fait pendant une autre partie.

Après je cherche à optimiser (structures alignées, sprites compilés hard et soft, tables, organisation du code, etc...) et je suis preneur de tous conseils et techniques pouvant m'aider à rendre mon code plus rapide même si parfois il faut quand même un compromis avec l'espace mémoire (sprites compilés par exemple).

En tout cas, 50Hz c'est un peu le saint graal et y réussir sans sacrifier le reste , c'est pas toujours possible.
C'est sûr qu'au final, je vois que mon code est pas loin d'y arriver, je vais encore pousser pour dire d'y arriver.

En tous cas, je te remercie de tes encouragements

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Le 25Hz est la principale raison qui fait que les gens d'autres scènes trouvent les jeux CPC merdiques... Tous les jeux CPC+ (les bons) sont a 50 Hz, il faut perseverer en ce sens. Surtout pour un shoot, ce n'est vraiment pas ce qui prend le plus de CPU en gestion quand on s'y prend bien. Le totu est justement de bien reflechir au truc avant de commencer quoi que ce soit.

rooooh mais ca déboite tout ca , vivement la suite !!!

lool Megachur , de toute façon, le source sera dispo donc libre à chacun de l'améliorer.

merci Hermol, c'est ça de potasser la doc dispo ici et de poser des questions chiantes En tous cas y'a encore beaucoup de taf, j'espère arriver jusqu'au bout.En tous cas Grafx est vraiment tip-top pour faire du gfx plus.

Et en plus xeo3 cpc est de retour , ça va me motiver d'autant plus

a bientôt pour la suite

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

L'écran reste en 50hz, ce qui change c'est que le scrolling est plus lent...ce qui est très bien.

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...

Bonne continuation !

Le moniteur est a 50Hz (encore que, pas vérifié) en revanche l'affichage ne l'est pas et cela ce voit !!! Je trouve dommage que tous les jeux CPC soient à de basses fréquences. Encore pire sur CPC+. Ne pas être à 50Hz c'est ne pas être fluide. Il n'y a rien qui s'oppose à ce que ce jeu soit à 50Hz pourquoi donc vouloir avoir du 25 Hz ???

Bin théoriquement pour laisser au CPU le temps de gérer 2x plus de choses...

Après c'est clair que au niveau de l'affichage bin l'oeuil humain n'est pas si lent que ça non plus et l'épiléptique qui sommeil en nous peut décider que c'est naze.

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.

Mais cela n'implique t'il pas aussi un gros travail sur les Timings et autres synchronisations ?