30

OK, edites le fichier c.bat et remplace les f:\ par des c:\ sur les lignes suivantes :

set PATH=[b]c:[/b]lynx\newcc65\bin

cc65 -I[b]c:[/b]lynx\newcc65\include\ "%1.c"

link65 "%1.obj" "%1.olb" "[b]c:[/b]lynx\newcc65\lib\c.olb" "[b]c:[/b]lynx\newcc65\lib\lynx.olb" -o "..\%1.o"

Et relances c test ensuite

31

ha maintenant g un nouveau message d'erreurs:
[URL=http://img456.imageshack.us/my.php?image=pb2oz4.jpg][IMG]http://img456.imageshack.us/img456/7610/pb2oz4.th.jpg[/IMG][/URL]

32

Il y a juste un petit oubli dans l'endroit ou tu dois générer le fichier obj.
Corrige la ligne suivant dans c.bat

ra65 "%1.m65" -o "[b]c:\lynx[/b]projet\%1\%1.obj"

33

Ho putain ça marche!!!!
Ma 1ere rom lynx!!!
Mille merci Fadest!!!!!

M'en vais en faire plein d'autre histoire de bien me faire la main dessus.

34

RYGAR (./33) :
Ma 1ere rom lynx!!!


magic

Alors, ça fait quel effet ?

J'ai pas le temps pour une session d'explication de source, source de 2° niveau vu que c'est l'après midi des enfants wink

Mais tu peux te lancer dans le kit aventure (bon, il faut aussi adapter les .bat aussi je pense pour le PATH et programme.bat de la même manière que c.bat) si tu veux wink

35

Ca y est je maitrise a fond la technique!

Maintenant ce qu'il me faudrait c'est un petit programme qui me permet de compiler plusieur images et de pouvoir les faire défiler à ma guise.

Cela existe t'il?
Peut etre en aurais tu un sous le coude Fadest?!

36

avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

37

Oula!

C'est un peu brut tous ca pour moi!
En quoi cela va t'il m'aider?

Ce que j'aimerais (idealement) c'est un *.bat qui compil tout seul source et image pour me donner un *.o exéutable.

38

On va prendre le problème à l'envers...

Fournis les palettes que tu obtiens et je te dirais quelles sont les couleurs correspondantes
avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

39

Peut etre en aurais tu un sous le coude Fadest?!

Je peux te donner des indices si tu veux wink

Déjà, il te faut, plusieurs images. Puis générer chaque objet Lynx avec sprpck.
Ensuite, il te faut générer la librairie contenant tous tes objets.

Ensuite, si on revient au niveau du programme, je vais ajouter en rouge ce qu'il faut que tu fasses.

#include <stdlib.h>
#include <lynx.h>
#include <lynxlib.h>
#include "inc\fond.pal"

/* LYNX-specific #defines: */
#define JOY_RIGHT 0x10
#define JOY_LEFT 0x20
#define JOY_DOWN 0x40
#define JOY_UP 0x80

#define BUTTON_OPTION1 0x08
#define BUTTON_OPTION2 0x04
#define BUTTON_INNER 0x02
#define BUTTON_OUTER 0x01

#define BUTTON_PAUSE 0x01

char SCREEN[8160] at (MEMTOP-16320);
char RENDER[8160] at (MEMTOP-8160);

extern char fond[];
/* là, il faut que tu déclares toutes tes images, par exemple, si en plus de fond, tu as fond1 : */
extern char fond1[];


extern char SCB[];
#asm
_SCB dc.b $c0,$10,$20
dc.w 0,0
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef
#endasm

// assembler vertical retrace syncronisation routine
void Vsync()
{
#asm
vretrace:
lda $fd0a
bne vretrace
#endasm
}


/**************************************************************************
** **
** **
**************************************************************************/
char main()
{
InitIRQ();
CLI;

SetBuffers(SCREEN, RENDER ,0);

/* set the palette */
SetRGB(pal);
DrawFBox(0,0,160,102,0);
SCBX(SCB) = 0;
SCBY(SCB) = 0;
/* la ligne suivante, c'est pour dire quel sprite affiché (fond dans ce cas là)*/
SCBDATA(SCB) = fond;
/* les 3 lignes suivantes, c'est pour afficher le sprite, puis afficher le tout à l'écran */
DrawSprite(SCB);
Vsync();
SwapBuffers();
/* donc, en fait, ce qu'il te manque, c'est attendre que l'utilisateur appuie sur le bouton */
/* puis recopier le bloc de 4 lignes + haut pour afficher une autre image */

for(;wink;
}


J'ai cru comprendre que tu n'avais aucune notion en C, donc je pense que tu ne couperas pas à un cours sur les bases du C (boucles, conditions, fonctions...). Ca doit se trouver sur le net.
En attendant, il te faut donc :
détecter l'appui sur un bouton. Le kit BLL gère la variabl joystick qui contient l'info sur le pad et les boutons (direction, boutons...).
Le plus simple pour attendre que l'utilisateur appuies sur le joystick ou un bouton, c'est d'ajouter la ligne suivante :
while(!joystick);
ensuite, il faut attendre qu'il ait fini d'appuyer (sinon, la console réagit trop vite)
whiel(joystick);

Petite explication : while, c'est une boucle "tant que"
! c'est une négation, donc while(!joystick); ça veut dire tant que joystick vaut 0

Grosso modo, ça te fera quelque chose comme ça :

SCBDATA(SCB) = fond;
DrawSprite(SCB);
Vsync();
SwapBuffers();

while(!joystick);
while(joystick);
SCBDATA(SCB) = fond1;
DrawSprite(SCB);
Vsync();
SwapBuffers();


for(;wink;


que je te conseillerais de faire plutôt comme ça :

for(;wink
{
SCBDATA(SCB) = fond;
DrawSprite(SCB);
Vsync();
SwapBuffers();

while(!joystick);
while(joystick);
SCBDATA(SCB) = fond1;
DrawSprite(SCB);
Vsync();
SwapBuffers();


while(!joystick);
while(joystick);

}


le for(;wink c'est une boucle, le pavé qui se trouve entre les { sera exécuté indéfiniment (tu boucleras sur tes images).
La sayntaxe exacte de for est la suivante :
for (condition initiale; condition de fin; incrément)
par exemple for(i=0;i<10;i++) exécutera la boucle 10 fois (la variable i commence à 0, est incrémentée de 1 unité tant qu'elle est inférieure à 10)

Attention, en C, toutes les variables doivent être initialisées, donc il te faudra une ligne
int i;
quelque part en local ou global (je pense qu'un cours de C sur le net serait utile car je détricote tout là...)



Et recopier le bloc en bleu pour chaque nouvelle image (attention, si ton test.o fait plus de 40ko, ça ne devrait plus marcher, pas assez de ram dans la Lynx).


Il te restera un problème : si toutes tes images ont la même palette, c'est bon, ça ira, sinon, elle seront affichées avec la palette de fond.bmp et ça fera moche.
Je te laisse faire l'essai pour te rendre compte, et on voit après comment déclarer plusieurs palettes wink

Et aussi bouger/zoomer une image à l'écran bientôt grin

40

vince (./38) :
On va prendre le problème à l'envers...

Fournis les palettes que tu obtiens et je te dirais quelles sont les couleurs correspondantes

Tu n'as pas inversé les topics wink ?
Les palettes, c'est sur l'outil de jeu d'aventure, non ?

Et tu as mis 2 fois le même lien, il a du y avoir un pb de copier/coller

41

RYGAR (./37) :
Ce que j'aimerais (idealement) c'est un *.bat qui compil tout seul source et image pour me donner un *.o exéutable.

Non non, il faut souffrir pour apprendre. Et essayer pour souffrir wink

42

Encore une fois merci à toi! top

Pour le language C je me suis téléchargé un petit tuto histoire de comprendre les bases et la syntaxe.

Je vais tester tes explications dés se soir... En ce moment j'y passe mes journées et mes nuits!
A ce rythme dans 1 semaine je me fait virer de mon boulot et ma femme demande le divorce!





43

Bon bah impeccable j'ai fait un petit diapo qui marche super!

Mais comme tu le disais Fadest les palettes sont parties en vrille et je me retrouve avec des images dégeulasses.
J'ai trouvé qq code source je vais essayer de bricoler qqchose pour aranger cela.

Mon tuto sur le C m'a bien aidé, en plus je me rend compt que c'est pas si éloigné du basic que j'avais survolé voila 10 ans (bon là je parle en gros, style: "si press A"; print "tu as appuyé sur A").

A force je commence à comprendre le déroulement de la création et du cout les autres posts me parraissent plus comprehensibles (bonne nouvelle pour moi).

Je retourne m'amuser en attendant que tu m'expliques comment changer de palette et bouger dans une image.

44

En plus, il est vrai que je programme pas mal en style Basic-like, déjà parce que mes habitudes de hobbyiste, c'est plus le GFA, et qu'au boulot, c'est plus RPG (et là, paradowalement, ce serait plus proche de l'assembleur, mais en civilisé grin)
Et aussi parce que je ne suis pas certain du fonctionnement du compilo C Lynx dès qu'on aborde certains trucs C (pointeur sur fonction, structures, ...), même si ça a l'air de marcher.

Pour les palettes, je t'expliques ça dans la journée.

45

Chose promise, chose due :

Ce sont les lignes suivantes qui vont nous être utile
#include "inc\fond.pal"
Ceci sert à inclure le fichier palette généré par sprpck

SetRGB(pal);
Ceci sert à changer la palette de la Lynx.

Donc, si tu as plusieurs images, tu auras plusieurs fichiers .pal.
La première idée serait de multiplier les ligne
#include "inc\fond.pal"
pour inclure toutes les palettes dans ton programme.

C'est presque bon, il faut juste auparavant intervenir manuellement sur les fichiers .pal supplémentaires.
Un fichier .pal est constitué ainsi :
char redir[]={0x01,0x23,0x45,0x67,0x89,0xAB,0xCD,0xEF};
char pal[]={
	0x0F,0x0D,0x0A,0x00,0x05,0x06,0x0B,0x02,0x0D,0x0B,0x06,0x08,0x0E,0x08,0x0F,0x00,
	0xFF,0xFF,0x90,0x61,0x5B,0xA5,0xEC,0x83,0x7F,0xAF,0x2F,0xC8,0x80,0x7F,0x6F,0x00};

Les deux choses importantes à voir sont les 2 tableaux déclarés : redir[] et pal[] (qui contient la défintion de la palette - les valeurs hexadécimales sont expliquées dans le lien donné par Vince plus haut)

On remarque donc que dans chaque fichier, on aura un tableau redir[]. Donc, on aura une erreur à la compilation car on ne peut pas déclarer plusieurs fois le même tableau.
Il faut donc, dans tous les fichiers .pal sauf un, supprimer la ligne suivante :
char redir[]={0x01,0x23,0x45,0x67,0x89,0xAB,0xCD,0xEF};


Deuxième chose, la définition de la palette est toujours faite dans un tableau pal[]. Idem, ça ne passer pas à la compilation.
Il faut donc renommer les différents tableaux pal[]
par exemple pal_fond[], pal_2[]
Un peu comme vous voulez en fait, de manière à ce que ce soit le plus simple possible pour vous plus tard.

Donc, maintenant, en ayant une ligne #include... par fichier .pal, il n'y aura plus de problèmes à la compilation.


La deuxième chose, c'est de changer la palette de la Lynx.
Avant l'affichage de chaque image, il faut donc charger la palette correspondante.
Celà se fait avec la fonction SetRGB() en passant en paramètre le tableau correspondant.
Par exemple
SetRGB(pal);
SetRGB(pal_fond);
SetRGB(pal_2);

Je vous laisse inclure ces lignes au bon endroit dans le programme.

Une fois compilé, et à l'exécution, vous noterez que le changement de palette est perceptible sur l'image précédente un chouia de temps (le temps d'afficher la suivante).
Il y a plusieurs possibilité pour éviter ça :
effacer l'écran avec la commande DrawFBox(0,0,160,102,0); ça affichera un rectangle de la couleur 0 sur tout l'écran (si vos 2 palettes n'ont pas la même couleur 0, ça fera un flash)
Déclarer une palette ne contenant que du noir par exemple, et temporairement utiliser celle-là.
...

46

Petit exercice commenté pour suivre : afficher et déplacer un sprite à l'écran.

Pour celà, il faut un fond d'écran et un sprite plus petit (utilisant la même palette vu que les 2 seront affichés à l'écran simultanément).
La génération/gestion d'un sprite se fait de la même manière qu'un fond d'écran, à quelques nuances prêt :
SPRPCK -t6 -S016032 -p0 sprite.bmp
Dans cet exemple, je pars du principe que le sprite fait 32 pixels de haut et 16 pixels de large, si le votre est différent, adaptez la valeur -S016032
De plus, je pars du principe qu'il est en haut à gauche du fichier bmp (on verra une autre fois comment marche SPRPCK en détail)
Si votre sprite n'est pas rectangulaire, vous souhaiterez qu'il y ait un effet de transparence (c'est à dire qu'on voit le fond derrière le sprite là ou il n'y a rien, par exemple, qu'une balle soit ronde, par un cercle sur un carré, on illustrera plus tard). Bref, le fond doit être la couleur 0 de la palette, c'est important.

Une fois les 2 objets générés, seul le fichier .pal du fond sera utile (vu que les 2 sont les mêmes), par contre, copiez les 2 fichiers .obj dans le répertoire OBJ et générez la librairie.

Au niveau du programme, reprenez celui donné en page 1 (affichage d'une seule image).
Vous allez devoir le modifier de la façon suivante :
- déclarer le sprite (de la même manière que vous déclarez les images supplémentaires dans le slide-show)
- déclarer un nouveau controleur de sprite pour le sprite.
Qu'est ce qu'un controleur de sprite, c'est ce qui correspond à ce bout de code :
extern char SCBs[]; 
#asm          
_SCBs      dc.b $c7,$10,$20 
          dc.w 0,0 
          dc.w 0,0,$100,$100 
          dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef 
#endasm 

La déclaration se fait en 2 temps. Tout d'abord, en C, déclarer l'objet (ici SCBs), puis en assembleur, l'initialiser.
Vous noterez la valeur $c7 dans la première ligne de type dc.b, je reviendrais dessus un peu plus tard.


Ensuite, dans le programme principal, qui ressemblait à :
char main() 
{ 
  InitIRQ(); 
  CLI; 
 
  SetBuffers(SCREEN, RENDER ,0); 
 
  /* set the palette */ 
  SetRGB(pal); 
  DrawFBox(0,0,160,102,0); 
  SCBX(SCB) = 0; 
  SCBY(SCB) = 0; 
  SCBDATA(SCB) = fond; 
  DrawSprite(SCB);  
  Vsync(); 
  SwapBuffers(); 
  for( ; ; );
 } 


On va ajouter l'initialisation de notre sprite :
SCBX(SCBs) = 50;
SCBY(SCBs) = 50;
SCBDATA(SCBs) = sprite;

SCBX() et SCBY() servent à définir les coordonnées X & Y de l'objet à l'écran, ici, on le place en (50,50).
SCBDATA() sert à associer un objet au controleur de sprite
On va mettre l'affichage du tout (d'abord le fond, puis le sprite) dans une boucle infinie :
for( ; ; )
{
  DrawSprite(SCB);  
  DrawSprite(SCBs);  
  Vsync(); 
  SwapBuffers(); 
} 


Arrivé là, on affiche le sprite par dessus le fond.
Pour déplacer notre sprite, on va utiliser 2 variables x et y (à déclarer en type int au début du programm), et les gérer au joystick :
la variable joystick est un octet ou chaque bit correspond à une valeur du pad (direction enfoncée oui/non, bouton enfoncé oui/non)
Pour des raisons de facilité, on avait déclarer ce bloc au début du programme :
/* LYNX-specific #defines: */ 
#define JOY_RIGHT		0x10 
#define JOY_LEFT		0x20 
#define JOY_DOWN		0x40 
#define JOY_UP			0x80 
 
#define BUTTON_OPTION1	0x08 
#define BUTTON_OPTION2	0x04 
#define BUTTON_INNER	0x02 
#define BUTTON_OUTER	0x01 
 


Donc, pour sire que si on va à droite, on incrémente x, on tape le bloc suivant :
if (joystick & JOY_RIGHT)
x++;

le & signifie qu'on fait un test binaire entre joystick et JOY_RIGHT, si ça marche, ça veut dire que la direction droite est enfoncée.
Il faut ensuite, grâce à SCBX() changer la position du sprite à l'acran.


On a donc un corps de programme principal qui ressemble à ceci :
char main() 
{ 
  InitIRQ(); 
  CLI; 
 
  SetBuffers(SCREEN, RENDER ,0); 
 
  /* set the palette */ 
  SetRGB(pal); 
  DrawFBox(0,0,160,102,0); 
  SCBX(SCB) = 0; 
  SCBY(SCB) = 0; 
  SCBDATA(SCB) = fond; 
  SCBX(SCBs) = 0; 
  SCBY(SCBs) = 0; 
  SCBDATA(SCBs) = sprite; 
  x = 50;
  y = 50;

  for( ; ; )
  {
    DrawSprite(SCB);  

    if (joystick & JOY_RIGHT)
      x++;

    SCBX(SCBs) = x; 
    SCBY(SCBs) = y; 
    DrawSprite(SCBs);  

    Vsync(); 
    SwapBuffers(); 
  } 


 } 


2 petites choses :
- seule la direction à droite est gérée, je vous laisse gérer la gauche, le haut et le bas,
- il n'y a pas de test de sortie d'écran, à vous de l'ajouter si vous voulez.



Revenons un instant sur le fameux $c7
C'est ce qui indique que le controleur de sprite affichera l'objet en mode transparent (rappelez vous la balle).
Si vous voulez voir la différence, remplacer ce $c7 par $c0 (comme le fond).

Bon exercice.
Si vous voulez, vous pouvez essayer d'afficher plus de sprites, voire de les controller par la console (aller/retour à la space invaders par exemple).

47

Bon j'ai bien travaillé! Voila mes réalisations d'aujourd'hui:

http://pageperso.aol.fr/firenzemouss/mes%20essais.zip

Bien évidement j'ai encore pas mal de questions:

-Dans la démo clown, comment reduire l'espace de déplacement autorisé des yeux seulement aux orbites?

-Dans la démo ovni, pourquoi les couleurs de la soucoupe on telles disparu? J'ai deja pas mal touché au fichier .pal de l'objet ovni mais je n'arrive pas à influer sur ses couleurs.
(pour crée mes fichiers, j'ai pris une image pour le fond d'ecran *.bmp 16 couleurs
et j'ai utiliser 3 de ses 16 couleurs pour dessiner la soucoupe)

-Dans la démo texte, j'ai recopier des chose que j'ai trouvé sur un fichier c d'une rom contenant du texte, pour l'affichage des deux premiere page pas de probléme mais lorsque la troisieme page s'affiche, la premiere revient egalement à l'ecran et je ne comprend pas pourquoi.

48

- sur ovni la flèche droite ne marche pas, c'est normal ?
- texte, y'a des fautes de francé cheeky

avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

49

Pour clown :
if (x>80) x=80; 
if (y>52) x=52; 
if (x<60) x=60; 
if (y<32) x=32; 

(autorise un déplacement de 10 pixels max dans chanque direction par rapport au départ)

Ces lignes sont à insérer à chaque fois entre le if(joystick&touche) coord++; et SCBX(SCBs) = coord;
(et tu devrais tenter de mutualiser, ça sert à rien de refaire le drawsprite entre chaque test de direction, une seule fois pour les quatre suffirait)


Pour ovni à froid comme ça (l'heure doit aussi y être pour qqchose) je ne vois pas... je tâcherais de regarder plus tard mais probablement un conflit de palette zzz


Pour Texte le fonctionnement est "normal".

1) tu écris sur le buffer masqué ton premier texte
2) tu échanges tes deux buffers (masqué/affiché) on voit donc d'un coup ton premier blabla
3) tu écris sur le buffer masqué ton second texte
4) tu échanges les deux buffers => ton premier écran écrit redevient le buffer masqué
5) tu écris le troisième texte sur le masqué (il vient donc surcharger le premier)
6) tu échanges donc on a les textes 1 & 3 affichés l'un sur l'autre qui apparaissent...

int 5) ou tout simplement de dessiner un rectangle de couleur unie : DrawFBox(0, 0, 160, 102, 3); //x1,y1,x2,y2,index de couleur dans la palettepour "corriger" ça, c'est "simple" il suffit de vider le buffer avant le po
avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

50

Moi j'ai craqué à 2h mes yeux saignaient à force de lire de (SBC char[] et autres pal_fond25)....
vince (./48) :
- sur ovni la flèche droite ne marche pas, c'est normal ?
- texte, y'a des fautes de francé mod.gif



Pour ovni c'est le bouton B qui commande la direction droite (c'était histoire de voir qu'elle etait le nom de se bouton).
Des fautes de fançais? Ce serai bien la 1ere fois que cela m'arrive! boing


Pour ce qui est de tes explications j'ai tout compris et cela marche nickel sauf pour les yeux du clown qui en deplacement Y ont une sorte de bug qui fait qu'ils ne s'arretent pas la ou il devrais. (Mais je suis sur le coup!)


Sinon pour ce qui est des problémes rencontés ce jour:

J'arrive à faire déplacer un sprite par la console (il suffit de retirer l'indication "if (joystick & JOY_X) mais je n'arrive pas à le faire tourner en boucle (genre des allé retour de droite a gauche de l'écran). Moi je lui disais tu es en X0 va en x100(ca marche) puis, tu es en X100 va en X0(ça marche pas)! J'imagine bien quel est le pb (2 ordre qui s'opposent) mais malgré pas mal de tentative impossible de résoudre ce pb pourtant simple.

Le programme clown2 c'est un clown dont les yeux reprennent leurs place. J'ai inseré ce programme dans le programme texte et le probleme c'est que les yeux ne bouge plus (bien evidement je n'ai pas compris pourquoi).

(vous aviez vu que l'on pouvais enlever le soutient gorge de la fille! grin )

51

tu peux ajouter/modifier ton code avec ça :

int dir_x; // pour direction

dir_x=1; // on prends une valeur positive pour commencer

x=x+dir_x; //au lieu de x++;

if (x>80) {
    x=80; //on fixe le maximum
    dir_x=-1; //on change de direction, vers bas !
}
if (x<60) {
    x=60; //on fixe le minimum
    dir_x=1; //on change de direction, vers haut !
}


avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

52

Wouh, tu avances vite, en plus, tu as l'air d'avoir plein d'idées wink

Pour le problème du clown qui ne bouge pas ses yeux, ton code ressemble à ça :
  DrawFBox(0, 0, 160, 102, 0);
  SCBDATA(SCB) = 0; 
  SetRGB(pal);  
  DrawFBox(0,0,160,102,0);  
  SCBX(SCB) = 0;  
  SCBY(SCB) = 0;  
  SCBDATA(SCB) = clown;  
  SCBX(SCBs) = 0;  
  SCBY(SCBs) = 0;  
  SCBDATA(SCBs) = oeil;  
  x =0;
  y =0; 

 DrawSprite(SCB); 

      x++; 
      if (x>70) x=70;
   SCBX(SCBs) = x; 
   SCBY(SCBs) = y; 
   DrawSprite(SCBs); 
    
      y++; 
      if (y>42) y=42;
   SCBX(SCBs) = x; 
   SCBY(SCBs) = y; 
   DrawSprite(SCBs); 
  
   Vsync();  
   SwapBuffers();  
 


Donc, tu ne passes qu'une fois sur le x++ et le y++ (pas de boucle contrairement à la version autonome ou l'ensemble est pris dans un for( ; ; ) )

Donc, tu devrais modifier de cette manière (par exemple, il y a plein de solution)
  DrawFBox(0, 0, 160, 102, 0);
  SCBDATA(SCB) = 0; 
  SetRGB(pal);  
  DrawFBox(0,0,160,102,0);  
  SCBX(SCB) = 0;  
  SCBY(SCB) = 0;  
  SCBDATA(SCB) = clown;  
  SCBX(SCBs) = 0;  
  SCBY(SCBs) = 0;  
  SCBDATA(SCBs) = oeil;  
  x =0;
  y =0; 
 
 while ((x < 70) && (y < 42))
{ 
 DrawSprite(SCB); 

      x++; 
      if (x>70) x=70;
   SCBX(SCBs) = x; 
   SCBY(SCBs) = y; 
   DrawSprite(SCBs); 
    
      y++; 
      if (y>42) y=42;
   SCBX(SCBs) = x; 
   SCBY(SCBs) = y; 
   DrawSprite(SCBs); 
  
   Vsync();  
   SwapBuffers();  
} 


Petite remarque, quand tu fais :
y++;
if (y>42) y=42;

Tu fais l'opération d'ajout, puis le test, puis éventuellement l'initialisation (donc 2 puis 3 lignes exécutées à chaque fois).
Ce serait plus rapide de faire :
if (y<42) y++;
Le test sera toujours fait, mais l'incrémentation ne sera faite que 42 fois (donc 2 puis 1 ligne exécutée à chaque fois)

Ca ne changera rien à ton programme, mais sur un programme complexe impliquant pas mal d'opération entre 2 affichages, ce genre de détails mis bout à bout permet de gagner du temps machine et de faire plus de trucs (ou d'améliorer la rapidité du tout)


Pour le coup de la palette de l'OVNI, je ne suis pas certain que le rouge fasse parti de la palette du fond. Mais j'aime bien l'effet obtenu, avec un peu de transparence, ça fait très effet spétial de SF wink (et ouais, quelquefois, on trouve des trucs intéressants par erreur)

53

Mon clown bouge les yeux! enfin un peu de vie!

Maintenant je bloque sur la multiplication des sprits,
J'ai tenté cela:

extern char SCBs[];
#asm
_clown dc.b $c7,$10,$20
dc.w 0,_clown
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef


_ball1 dc.b $c7,$10,$20
dc.w 0,_ball1
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef

_ball2 dc.b $c7,$10,$20
dc.w 0,_ball2
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef
#endasm


Mais le resulta n'est pas probant, je peux afficher chaqu'un des sprits mais pas deux ou trois à la fois.

Autre question est t'il possible de faire tourner un sprite (comme les aiguilles d'une horloge)?

Et puis je le redis encore une fois: Un énorme merci à vous deux de banaliser la prog sur lynx d'une manière aussi clair et efficace même pour un néhophyte comme moi!

54

pour chainer un sprite, il faut préciser le suivant(en rouge) et 0 pour la fin de chaine, ça donne :


extern char SCBs[];
#asm
_clown dc.b $c7,$10,$20
dc.w _ball1,_clown
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef


_ball1 dc.b $c7,$10,$20
dc.w _ball2 ,_ball1
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef

_ball2 dc.b $c7,$10,$20
dc.w 0,_ball2
dc.w 0,0,$100,$100
dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef
#endasm


Ainsi dans ta structure tu précises que le premier sprite "clown" a pour suivant "ball 1" que "ball1" a pour suivant "ball2" et que "ball2" n'a pas de suivant (donc c'est le dernière de la liste chaînée)
avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

55

L'avantage, c'est que de cette manière, tu as juste à afficher clown, Suzy gérera automatiquement le fait que après clown, il faut afficher ball1, puis ball2.


Bien sur, tu dois avoir les 3 déclarations de sprite
extern char clown[];
extern char ball1[];
extern char ball2[];

Pour les yeux qui tournent, la trigonométrie, ça te rappelle quelque chose ?
Bon, je ne sais pas si le compilo C a les fonction sinus et cosinus et souvent, quand on a ce genre de boucles (cercles, sinusoidales), on peut ne pas les faire en temps réel, mais soit en précalculé (par le programme au début du lancement, ou par le programmeur lors de l'écriture du programme). Ensuite, les coordonnées (x,y) sont stockées dans 2 tableaux (courbex et courbey par exemple) ou un tableau de structure pour faire plus C, et on gère un compteur sur ce tableau.
Ensuite, le changement de coordonnées à l'affichage se fait de cette manière :
SCBX(ball1) = courbex[i];
SCBX(ball1) = courbey[i];

Si ton 2° oeil est juste un peu à droite par rapport au premier, tu peux utiliser le même tableau en faisant :
SCBX(ball2) = courbex[i] + decalage;
SCBX(ball2) = courbey[i];


puis un bloc pour l'incrément du compteur
i++;
if (i == valeur_max)
   i = 0;

(ou gérer un 2° compteur pour le 2° oeil pour avoir un effet différent sur chaque oeil - qui louche, rotation dans l'autre sens, plus rapide)

Par exemple, j'avais fait un exemple de démo à la Intro ST avec une courbe sinusoidale, tu devrais pouvoir la retrouver pour regarder le source.

56

(les opérations trigos ne sont pas dispo de base)
avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

57

C'est bien ce que je pensais.

58

(et le moteur mathématique possède quelques bugs)
avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

59

Mais pourquoi ça ne marche pas ?

http://pageperso.aol.fr/firenzemouss/clown2.zip


C'est quand meme trés compliqué la programmation!
Malgré le tuto sur le c il y a encore le probléme de la syntaxe qui diffère entre les deux language (genre on ne peut pas copié un programe c directement sur le fichier *.C pour la lynx, elle ne comprend rien et n'affiche que des error error error)

Bon suis fatigué, vais dormir.


60

Je viens de jeter un oeil à ton source.
Visiblement, tu veux créer 6 sprites en plus du fond.
Tu fais également une confusion entre les objets sprites (oeil, ball1, ...) et les descripteur de sprites (objets de type SCB) qui leur seront associés (edit : il faut dire que mon post explicatif précédent a du t'induire en erreur au niveau des noms, désolé).
Rien ne t'oblige à avoir 1 SCB par objet (sauf si tu veux chainer les objets pour des raisons de performance).
1 seul SCB opaque (le fond, déclaré en $c0) et un transparent (déclaré en $c7) peuvent suffire.
Mais il faut dans ce cas :
afficher le fond avec DrawSprite
associer le sprite 1 au SCB transparent (avec SCBDATA)
afficher le SCB avec DrawSprite
associer le sprite 2 au SCB transparent (avec SCBDATA)
afficher le SCB avec DrawSprite
associer le sprite 2 au SCB transparent (avec SCBDATA)
afficher le SCB avec DrawSprite


De la manière dont tu es parti (en chainant les SCB), tu dois déclarer les 6 structures (en C avec une déclaration de tableau extern char... + en assembleur pour charger le tableau)
Là, tu déclares une structure SCBs et en assembleur les 6 controlleurs avec des noms différents (qui en plus sont ceux de tes objets, donc tu effaces tes sprites.
Tu dois donc remplacer
extern char SCBs[];

par
extern char SCBoeil[];
extern char SCBball1[];
extern char SCBball2[];
extern char SCBball3[];
extern char SCBball4[];
extern char SCBball5[];
(mets bien SCB pour les distinguer devant sinon, c'est le même nom que tes objets)
Dans la partie assembleur; tu devrais avoir ça :
#asm           
_SCBoeil     dc.b $c7,$10,$20  
          dc.w _SCBball1,_oeil  
          dc.w 0,0,$100,$100  
          dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef  

_SCBball1     dc.b $c7,$10,$20  
          dc.w _SCBball2,ball1  
          dc.w 0,0,$100,$100  
          dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef  

_SCBball2     dc.b $c7,$10,$20  
         dc.w _SCBball3,ball2  
          dc.w 0,0,$100,$100  
          dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef

_SCBball3     dc.b $c7,$10,$20  
         dc.w _SCBball4,ball3  
          dc.w 0,0,$100,$100  
          dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef 

_SCBball4     dc.b $c7,$10,$20  
         dc.w _SCBball3,ball4  
          dc.w 0,0,$100,$100  
          dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef  

_SCBball5     dc.b $c7,$10,$20  
          dc.w 0,_ball5  
          dc.w 0,0,$100,$100  
          dc.b $01,$23,$45,$67,$89,$ab,$cd,$ef     

#endasm 



Ensuite, dans le corps du programme :
tu ne dois plus faire référence à SCBs qui n'existe plus mais à SCBoeil, SCBball1, ...
Note : vu que dans ta déclaration assembleur, tu as déjà associé SCBoeil l'objet oeil, c'est inutile de faire un SCBDATA().
SCBX(SCBoeil) = 50;
SCBY(SCBoeil) = 50;
idem pour SCBball1, SCBball2, ...

Pour les DrawSprite, tu dois seulement faire le:
DrawSprite(SCB); // affiche le fond
DrawSprite(SCBoeil); // affiche tous les sprites vu qu'ils sont chainés


Voilà, j'espère que c'est plus clair. C'est vrai que la gestion de la mémoire en C est assez différente du GFA (moins masquée dirons nous)