Mon programme dessine en screen 12 un objet en mouvement.
Je dessine en couleur puis je redessine avec la couleur 0 pour effacer, j'effectue le mouvent voulu, et je dessine, etc...
Cela provoque un scintillement désagréable.
Il me semble avoir lu quelque part qu'on pouvait se synchroniser avec le raffraichissement d'écran en testant la valeur d'une adresse mémoire (peek)(mais laquelle et comment interpréter son contenu, etc...) et ainsi afficher au bon moment.
Quelqu'un pourrait-il m'aider dans ce domaine ?
Merci d'avance.

Sans parler de synchronisation (qui peut aussi être très utile, bien entendu) tu perds du temps si tu redessines avec la couleur 0.
Si tu utilises des sprites (je suppose que c'est le cas) il me semble qu'il est possible de les effacer en appliquant un xor sur put. Ce qui permet de n'effacer que la partie de l'image qui change.

Pour ce qui est de la synchronisation, il me semble qu'il faut utiliser du code en assembleur. Du moins, les infos que j'avait trouvé à l'époque ou je pratique QB utilisaient toujours de l'asm.
Je ne sais pas si tu trouveras de la doc pour un truc en QB la dessus à notre époque...

Salutations.

Dans de nombreux programmes, il m’a fallu déplacer des dessins habituellement carrés en évitant au mieux les phénomènes de scintillement. Avec le principe d’afficher successivement image colorée, noire, colorée, noire, colorée, noire, etc …/… , je pense qu’il doit obligatoirement y avoir du scintillement sauf si les 20 ou 25 images par seconde sont obtenues (comme au ciné). Je ne vois pas ce qu’une synchronisation pourrait apporter comme solution, mais dans ce dernier cas, si la vitesse de 20 ou 25 est atteinte, le mobile va telle vite qu’il est incontrôlable par le joueur.
Il existe une solution si la zone sur laquelle se déplace le mobile est d’une seule teinte (cela doit être le cas). C’est ce que j’utilise pour des démos ou jeux que tu peux trouver sur le wall : INKJEUX3.BAS, V!!BALLE.BAS, MIAMMIAM\MIAMMIAM.BAS, DAMIER, TOTOS.BAS (Jeu)
Au moment de la mise en table du dessin (GET coordonnées, tableau), incorporer à la surface sauvegardée un cadre/bordure de un pixel (tout autour) de la couleur de la surface où le déplacement se fera. Cette bordure ne sera pas visible lors du PUT (avec PSET), mais en cas de déplacement d’UN pixel, quel que soit son sens, elle effacera tout « résidu » du dessin précédent et il n’y a pas besoin de supprimer l’image précédente. Plus, ou presque pas de scintillement. Et le déplacement est très rapide, au point qu’il faut toujours le ralentir.
Si mes explications ne sont pas assez claires, S.O.S.
Et je pourrai mettre un petit programme de démo sur le Wall.

Salutations.

Il y à aussi la solution qui consiste à copier ce qui est en dessous dans un sprite avant d'afficher le sprite voulu.
Simple, plus rapide que l'effacement total, et permet de conserver un éventuel fond. (c'est la technique utilisée dans les jeux 2D en fait)

Ah, j'ai retrouvé un site (et la partie cachée de ce site qui contient les fichiers) qui devrai contenir des solutions:
http://biskbart.free.fr/nouveau/proge.htm

En fouillant les sources, je pense qu'il doit y avoir quelque part un bout de code pour la synchronisation verticale... (c'est plus tout jeune par contre, certains risquent de se souvenir d'une autre époque des pbs )

Salutations.

Passkhaal nous dit :

Citation Mon programme dessine en screen 12 un objet en mouvement.
Je dessine en couleur puis je redessine avec la couleur 0 pour effacer, j'effectue le mouvent voulu, et je dessine, etc...

Nous pouvons en conclure qu’il n’y a pas de fond d’écran, étant donné que la surface dessinée est « effacée » par du noir.
Il est possible d’obtenir le même résultat avec la méthode que j’indique ci-dessus.
Elle est très simple à écrire, avec un seul PUT, (X, Y), PSET et l’exécution par Billy est très rapide.
Dans le contexte donné, que peut-il y avoir de plus simple ?
C’est amplement suffisant pour la conception de petits jeux sans ambition excessive.

Salutations.

Ce n'étaient que des compléments d'information