Logicielsmoto.com

@__sam__ Je ne comprends pas ce code que tu avais souligné plus haut. Un DEC #$E7C3 ne serait pas mieux finallement?

@neotenien Un BRA SPRI01 / BRA TILE01 serait plus approprié

J'ai changé les DP pour le mettre en début de la routine timer, ça n'a rien changé.

Pour ce qui est de ORCC, je l'ai ajouté pour tester justement si ça changeaut quoi que ce soit, mais c'est pareil (même résultat que sur la vidéo)

J'ai aussi changé les ORG pour les mettre à partir de A000 (puis A500, AA00 et B000) mais là c'est encore pire, rien ne s'affiche.

Je ne sais pas où il faut positionner les fonctions ASS et la procédure principale. La documentation n'est pas claire quant à l'utilisation de la zone non commutable, j'ai lu quelque part qu'il ne fallait rien mettre en dessous de $7200

J'informe quand même que dans mon source assemble, j'ai forcé l'adressage étendu avec ">"

Pour ce qui est du conseil sur l'adressage de DP, désolé mais ce qui prend le plus de cycles est bien la routine d'affichage de sprite qui fait des aller retour assez fréquent avec les variables locales qui sont sur la même page! Pour ce qui est des sprite, vu que ça utilisera surtout les registre X et Y en indexé, il n'y a aucun intérêt à mettre les DP ici. Alors que dans la fonction d'affichage de sprite (et celle des tiles) il y a pas moins de 10 à 12 adressage étendu qui passe en immédiat dans la fonction et ce, pour chaque boucle (sachant qu'il y a 64 octet par sprite) donc c'est bien ici qu'il y a intérêt à mettre le DP, je suis programmeur depuis plus de 25 ans, je connais quand même bien mon sujet! (J'ai fait du Pascal, du C, du Basic, du CAML, de l'ADA, du Pearl, Python et je suis spécialiste du PHP et JavaScirpt). Et je suis quand même rompu à ce qui est optimisation en complexité algorithmique. Par exemple, le meilleur algorithme de tri est le quick short.

J'ai trouvé d'où venait le problème!! C'est dans l'allocation en RAM et la clarification en basic de l'espace à allouer!

J'avais mis un clear,&H9FFF,,&H71FF en changeant le loadm dès &h7200 et vec les datas en &ha00!!

Or en &ha00 dans la même banque mémoire que le basic et le programme résident, ça ne le fait pas LOL. Je vais voir comment paramétrer ça... Mais je remarque quand même que le TO8 est capable d'animer très rapidement 6 sprites de 8x16 à vitesse réelle (les 6 sprites traversent tout l'écran en largeur, soit 40 déplacements pour les 6 personnages, en moins de 4s pour un timer à 0.1 et en moins de 2s pour un timer à 0.05s). Et je pense même que ça va nettement plus vite que la version Falcon030 Double Bubble (qui elle tourne avec un timer de 0.2s apparemment!).


Il y a l'effet de scintillement mais quand je manipulerai ça avec le gate array mode page (selection de la page écran), il n'y aura plus ce soucis.

Je pense que yaura même pas besoin d'optimiser avec les DP pour le jeu Bubble Bobble. Par contre, il faudra sans doute temporiser les déplacements des sprites en timer à 0.05. Surtout qu'au début, les personnages ne se déplacent pas à une vitesse supersonique. Les personnages sont en mode transparent, le tile de remplacement ne l'est pas (en fait,ce tile simule le décor de fond).

Si tu sais être en ramA ou ramB en ce point du code oui, sauf que dans le code de Neotenien, on peut être simultanément dans les deux sortes de ram en ce point du code à cause du rebouclage. Appeler une sous routine réalisant le décodage seul (et pas la commutation de VRAM) peut-être une option, mais elle coûte plus de cycles.

@Neotenien J'imagine comme tu es en interruptions, tu ne sais pas quelle banque est actuellement présente en $A000 quand l'interruption se produit. Il te faut, tout comme la valeur de DP, mettre à jour $E7E5 dans ta routine d'interruption (et n'oublie pas de la restaurer à la sortie, ou sinon j'ai peur que le basic n'aime pas qu'on lui change le contenu du $A000 sans rien dire.)

_________________
Good morning, that's a nice Tnetennba

Salut Samuel

Merci pour toute ces information précieuse. J'ai rajouté une vidéo du défilement des sprite avec un timer à 0.1s et un a 0.05s, et c'est particulièrement intéressant. Je m'appelle Bruno AUBIN au fait LOL.

J'avoue que je ne sais pas trop où mettre les routines assembleur... Est ce dans la zone 7300-9FFF ? Ou dans une banque RAM ? En fait le soucis venait effectivement que j'avais mis les datas des sprites dans A000 et que ça "mangeait" le basic. La question est de savoir quelle zone non commutable on peut utiliser au minima ? J'avais inscrit quelque part que c'était en $7200 mais je ne sais pas d'où je sors ça... Apparemment il y a quelques pages utilisée notamment pour le SW2 et SW3 et des zones réservée pour le moniteur (début $6000) et extramoniteur ? Mais je me dit aussi que le texte du Basic doit bien se trouver quelque part dans cette zone. A partir de 6100 peut-être ? Le problème est que FRE(1) ou FRE'() ne donne pas la zone à partir de laquelle c'est libre, on est obligé de faire le calcul LOL.

En tous cas je ne suis pas fâché d'avoir enfin corrigé ce bug qui ne venait pas de mon code mais de l'allocation mémoire. Je vais pouvoir dormir tranquille ce soir (LOL ça faisait 3 jours que j'étais sur ce bug)

Maintenant j'aimerais aussi pouvoir activer le SETDP dans les routines d'affichage des sprites et tiles (qui sont dans la même page! Y compris les datas). Parce qu'il y a 2 cycles à gagner dans la transparence (sur 32 à 39, ça peut paraitre peu mais bon) 3 autres sur la boucle J, et 4 sur la boucle I qui est assez courte mais concerne quand même les hauteurs des sprites qui sont de 16 de haut.. Au total, on peut gagner plus de 10% en cycles je pense.

Je ne sais pas si quelqu'un a vu les démo du jeu "wip zezito"
l'auteur avait créé une super démo TO8 il y a plus d'un an avec un scrolling de fou en bm16c, en mode bm16c, mais j'ai bien l'impression qu'il a laissé tomber pour le mode 320x200 4 couleurs dans la plupart des ordi 8 bits (BBC Micro, ZX Spectrum, C64, Oric Atmos...Et MO5 (en mode 320x200 seulement)). Ya encore du boulot pour que j'atteigne son niveau.

Si tu utilises Y et U pour les pointeurs, tu peux utiliser X comme compteur (LEAX -1,X lève le drapeau Z du CC quand X passe à 0, ce qui est utile pour les boucles.)

_________________
Good morning, that's a nice Tnetennba

Bonjour

Toujours dans la phase de tests des sprites
J'ai réussi à faire afficher les sprites en déplacement de 2 en 2 pxl horizontalement (même si ça alourdit légèrement le code, quoique pas tellement puisque ça ne concerne que les initialisation de la position du Sprite).

J'ai pu faire une séquence d'animation de 12 Sprites (déplacement de gauche à droite, 80 mouvement en quasiment 8s) en mettant le timer à 1/20s, et avec un déplacement de 2 en 2 pxl horizontalement!
Mais l'étrangeté est qu'apparemment, quand la routine du timer met plus de 1/20s à s'exécuter, ça saute l'interruption suivante pour aller à la 3ème et ainsi de suite!

Je m'explique...
première interruption du timer (1/20) : exécution de la routine (met 1.5/20 s)
seconde interruption (2/20) : passe puisque occupé
3ème interruption (3/20): exécution de la routine (met 1.5/20s)
4ème interruption : passe puisqu'occupé

En fait, on a tout intérêt à utiliser un TSB (durée avant interruption en nombre de 8 cycles) la plus courte possible. Dans le jeu, il peut y avoir des séquences où ça prend énormément de temps (10 sprites par exemple) et d'autres où c'est plus lent... Et ça se voit sur des jeux vidéos sur certaines plate forme (comme sur Atari ST par exemple).

En tous cas, ma routine assembleur d'affichage de sprite aux coordonnées X et Y de l'écran (X allant de 0 à 79, et Y de 0 à 199) fonctionne parfaitement. Et le tout prend moins de 256 octets (avec ou sans DP d'ailleurs). Cette routine peut afficher un sprite (avec transparence) ou un tile (sans transparence) le tout dans la même procédure (il y a un test ISSPRI effectué).

Samuel, j'ai utilisé ton conseil de mettre un JMP plutôt que de conserver un JSR et RTS, et j'ai enfin réussi à implanter les SETDP correctement (apparemment). Je vais faire des tests avec et sans le setdp avec un nombre différents de sprites.

Alors là j'étais à 1/20s, mais je pourrais être en 1/25 ou 1/50 ?

Bon l'étape suivante va être de voir avec le gate Array Mode Page (mettre la RAM écran sur la banque 2 ou 3 suivant la séquence) pour éviter cet effet de scintillement. La mécanique que j'ai choisi pour Buble Boble est d'effacer tous les sprites d'un coup avant de les réafficher, c'est ce qui aura le meilleur rendu puisque des sprites peuvent se chevaucher.. On n'aura ainsi pas les mauvais effets comme il y a sur la NES, Master System, ZX Spectrum et d'autres) et comme il y a une couleur de transparence autre que le noir, ça passera au travers des plateforme sans aucun effet bizarre comme c'est le cas sur le C64 (on voit par transparence dans les yeux de Bobble, les plateforme!).

Et l'étape d'après, afficher un écran de niveau (le premier) dont les couleurs vont être proche de la version Atari ST. Mais je dois faire des concessions sur la hauteur des niveaux, supprimer des lignes pleines (le Bubble Bobble original faisant 224 de haut, ici, je vais quand même garder les 2 lignes de scores en hait, mais supprimer 3/34 lignes de haut. La largeur des tableau étant (15+2) fois celle des sprites, il restera 16 PXl à droite en largeur pour afficher des trucs divers (par exemple certain compte à rebours peur-être ?) ça pourrait être un plus

Ou BRA (plus rapide) si l'appel n'est pas trop loin

NON Jaz!! Tu te trompes!! BRA utilise exactement le même Nc que JMP (j'ai vérifié dans ma doc papier) en plus, il n'y a qu'un mode dans BRA alors qu'il y en a 3 avec JMP (direct, 3 Cycles, étendu, 4 Cycles et Indexé)

Vérifie tes informations STP avant de dire une connerie.

De toutes façons, dans le logiciel c'est pas cet appel sporadique de JMP qui va augmenter la vitesse d'exécution, le gros du code vient dans l'affichage des Sprites. J'ai déjà réussi à optimiser un max la gestion de la transparence et l'affichage par octet (2 pixels), ce qui au moins, divise par 2 la durée affichage de sprite comparé à l'utilisation de PLOT par exemple (ça peut même être divisé par plus que ça).

Je pense qu'on peut obtenir une meilleure version que celle de BC Micro dans les prochaine semaine, le premier niveau sera en démo (je pense) avec une musique de fond dans doute (ça ne ralentira pas considérablement si les notes sont courtes du genre 1/5s par note).

Globalement BRA est pas mal car ca donne du code "relogeable" où l'on veut en RAM. Pour le son, il faudra voir chaque chose en son temps. On a parfois de mauvaise surprises de ce coté sur thomson: un blocage de 1/5sec c'est suffisamment long pour rendre l'affichage non fluide.

Pour ma part avec les démos 1k qui jouent du son, j'estime que jouer du son "en tache de fond" via les interruptions réduit par 2 la disponibilité du CPU pour le reste.

_________________
Good morning, that's a nice Tnetennba

Ben en fait, je voyais plutôt ça à l'inverse!! Le jeu en interruption timer (pour une relative coordination du tout) et le son en utilisant juste le synthé (note par note avec une attaque) en prog principal. Le jeu "démonia" je crois qu'il fait ainsi et ça reste vraiment correct au niveau de l'animation (qui a un scrolling horizontal en plus!)

Le C64 a un processeur à 1 MHz et arrive toujours à avoir des jeux d'une incroyable fluidité et avec du son, on devrait pouvoir en faire autant avec les Thomson je pense.

Il y a quelques petites différences importantes entre le C64 et le thomson:

• Les sprites sont matériels. Il n'y a pas de masquage ou d'écriture en RAM vidéo à gérer. Ca ne coute quasi rien en temps cpu.
• Le graphisme "du fond" est pour parti orienté en mode caractères. Cela signifie que 8 octets vidéos sont directement changés en n'écrivant qu'un seul octet en ram vidéo. C'est 8 fois moins de boulot que sur thomson qui n'a pas de mode "caractères". En plus ces caractères sont redefinissables, ce qui signifie que s'il est utilisé disons 40 ou 50 fois dans le fond écran, changer les 8 octets de sa définition change les 40 ou 50 zones de l'écran sans rien faire. C'est 40 fois plus rapide que sur thomson où il faudrait ré-écrire ces 40 ou 50 zones à chaque redéfinition.
• Le scrolling du fond au pixel près est matériel. Ca ne coûte aucun cycle cpu pour ainsi dire. Quand on dépasse de 8 pixels, il faut juste décaler les 1000 octets du mode caractères de fond, là où sur thomson il faudrait décaler tous les 8000 (x2 éventuellement) octets de la mémoire vidéo. Là encore le C64 est nettement plus rapide.
• Sur le C64 le chip son est autonome. Il se contente d'être nourri toutes les 20ms (VBL) par le CPU pour changer la fréquence ou le volume, mais tout le reste (génération des échantillons audio à intervalles réguliers) est automatique sans utilisation du CPU principal. Sur thomson ce chip audio n'existe pas. Le CPU doit lui même générer les échantillons audio qui, pour avoir une qualité correcte, doivent avoir une fréquence stable de 4000Hz minimun. Cela signifie que le CPU a 80 fois plus de boulot à faire pour avoir du son durant un jeu sur thomson.

Toutes ces différences font que le thomson est carrément désavantagé par rapport aux ordis ayant des chips son ou vidéo dédiés. Par contre les couleurs C64 sont moches (délavées), et le thomson a une belle palette, donc graphiquement il y a de quoi faire les jeux les plus jolis de tous les ordis 8 bits (cf. les passagers du vent par exemple) et s'il y a des sprites et du son durant le jeu tout en étant fluide c'est une prouesse exceptionnelle (cf. Mission:Liftoff).

_________________
Good morning, that's a nice Tnetennba

En mode direct oui!

Comment dois-je l'interpréter?

LBRA est équivalent à JMP en mode étendu aussi

Excuse moi d'avoir été aussi cru, j'étais un peu sur les dents. Je vopis tellement d'infos qui m'exaspèrent... Bon je t'envoie une boite de chocolat pour me faire pardonner ?

Comment ça fonctionne les SETDP ???

Parce que j'ai comparé les 2 dans ce code



Qui est le code final d'affichage de Sprites ou de Tiles en bm16c, que j'active le SETDP de début ou pas, j'obtiens le même temps d'animation de 12 Sprites sur la largeur (avec rafraichissement toutes les 1/20s), soit 80x12 déplacements de sprites en 6.9s (transparence inclus), alors que normalement, les étiquettes indiqué dans ce codes, sont sensés être en mode direct (et pas étendu) et gagner au moins 10 à 15% de temps. J'ai mis à $72 (dans la routine d'interruption), le DP (en rétablissant la valeur initiale à la fin de la routine). Apparemment, ça devrait fonctionner pourtant Il devrait y avoir 15 cycles d'horloge économisés sur toute la fonction (c'est pas grand chose d'autant que certaines sont en dehors de la boucle la plus utilisée).... Bon ok je me demande si les DP valent le coup finalement...

Bon tant pis.

Allez aujou'rdhui je tente le Gate Array Mode Page.