encore une chtite question - Page 25

s veut dire size, et doit être remplacé par b,w ou l (selon le cas)

- oué t'as un switch pour désactiver les "optimisations" auto, RTFM
- tu synchronises bien avec genlib::timer ?
- .s = .b pour les sauts

Flanker
: s veut dire size

Non, "short".

rhâ c chiant le "suivant" qui est pas en jaune sur toutes les skins, j'arrête pas de louper des pages

regarde la doc d'a68k... (p-ê qu'elle est seulement en .txt)

-n désactive les optimisations de A68k.

Il faut faire attention à utiliser genlib::frame_timer ou genlib::timer selon qu'on utilise des Screens ou des DScreens (cf la doc anglaise pour la différence).

->Pour m'améliorer et apprendre à écrire proprement, j'aurais aimé savoir s'il y a un moyen d'éviter tous les changements automatiques que fait a68k dans le code: move en moveq, cmp en cmpa, cmpi, etc...

oui il y a des switch pour empecher ceertaimes optimisation notament les plus complexe(regarde la doc) mais je suis pas sur pour les move en moveq, cmp en cmpa, cmpi, Verifie dans les option de la ligne de commande de la documentation

Et regarde dans un manuel (68kpm.pdf ou 68000UM.pdf) pour connaître les différences entre instructions (taille et vitesse).

>->Pour m'améliorer et apprendre à écrire proprement, j'aurais aimé savoir s'il y a un moyen d'éviter tous les changements automatiques que fait a68k dans le code: move en moveq, cmp en cmpa, cmpi, etc...
a68k -n -g -t -IC;\ti\include\ toto.asm
makeprgm toto.o

>->Je fais un prog avec genlib, mais même en réarangeant mon code dans tous les sens, je n'arrive pas à avoir des grays aussi stables que sur
>la majorité des jeux, dès que je fais bouger des sprites à l'écran (ils disparaissent pratiquement quand je les fais bouger pixel par pixel entre autre).
> Je fais du double-buffering, mais apparemment ça ne fait pas tout. Quels sont les autres moyens d'avoir une image vraiment nette?
Il te manque une syncho avec l'ecran.
Regarde la doc et en particulier les exemples de fonctions Wait15, Wait30 et Ready

MainLoop:
  La tu peux faire tout le calcul que tu veux qui ne modifie pas le Working DScreen.
  Y compris mettre a jour les Plane par un update_vscreen.
   bsr Ready  ; Est-ce qu'on  peut commencer a ecrire a l'ecran ?
   Affichage de la frame courante

   bsr SwapBuffer  ; Echange les DScreen
   bsr Wait15          ; Ou Wait30 / Synchronise avec l'ecran pour avoir un frame constant (15 fps ou 30 fps).
   bra MainLoop

J'oubliais : j'ai teste ton programme et n'ai vu scrictement aucun probleme. Ca affiche une belle image sans aucun probleme.
Peut-etre faudrait-il que tu m'envoies le binaire ?

Martial Demolins
: oui, je ne crois pas que le switch -n désactive ce dont je parle (écriture la mieux adaptée des instructions).

Il désactive tout ce qui est désactivable. (C'est-à-dire tout sauf xxx->xxxA et xxx->xxxI.) Il n'y a pas mieux en tout cas.

> (ton adresse sur voila)
J'ai une adresse

pour les sprites 16x16 je me demande si do16x16-32x32 ne permet pas de faire ça... mais oui j'ai prévu de refaire le tout, seulement je suis un peu débordé depuis quelques mois ...

là tu as largement dépassé la chtite question, nan ? 25 pages pour une question, ça fait bcp je trouve

Martial Demolins
: est-ce que vous savez par hasard si PpHd a prévu de rajouter une fonction pour enregistrer une partie d'écran au format big_sprite? (ça serait cool, sinon je vais devoir le faire à la main..)

ExtGraph prévoit cette fonction. Mais le format n'est pas compatible, donc il faudra utiliser ExtGraph aussi pour l'affichage.

Bah, je ne comprends pas trop pourquoi tu t'obstines à prendre une librairie qui ne propose pas les fonctions dont tu as besoin quand il y en a une qui les propose...