J’aimerais m’y mettre mais j’ai besoin d’aide. - Page 5

Bon je voudrais d'ici peu (faut se motiver), commencer à programmer un peu pour lynx.
J'aimerai savoir qui ici utilise une chaine de dev sous Linux?
Je trouve bcp de liens morts pour le kit BLL, pas d'Handy compilé pour Linux, ni de sources...
Et puis toute la doc Epyx NE fait PAS référence à BLL (ce qui est totalement logique ^^) mais comment fait-on pour transposer toutes ces informations avec BLL ?
Aidez-moi :-D?

512*512 maxi ?
Pour mes panoramas j’ai pu utiliser une image de maxi 450*102 (20-25 ko). Au-delà la conversion avec SPRPCK est impossible.

Fadest, ton code me produit une "Error:Bogus line". Erreur fatal que je rencontre souvent lorsque je veux chainer des sprites...


Petit hors sujet destiné à Fadest, Je trouve tes explications étonnement claires et malgré tout très technique. La programmation pour toi est-ce un métier ou juste une passion?

Alors dans le désordre, je ne suis pas sur des limites à 512 par 512, je pense qu'on peut aller plus loin.
Ensuite, il y a des possibilités de tricher, en recalculant toute la suite d'un niveau arrivé à un certain point.

Par sprites chainés, c'est assez simple, connais tu le principe de listes chainées en C ?

Si non, imagines une chaine, elle est composée de maillons.
Au début, tu ne vois que le premier maillon, si tu tires dessus, tu auras le second, et ainsi de suite, jusqu'au bout de la chaine.
Une liste chainée, c'est un peu pareil, tu commences par le premier élément, dans celui ci, il y a un lien vers le second, et ainsi de suite, jusqu'au dernier ou il n'y a plus de lien.
Des sprites chainés, ou plutôt, une liste de sprites chainés, c'est le même principe, il y a le premier sprite, celui ci a un lien vers le second, et ainsi de suite jusqu'au dernier.

Donc, quand on dit à la Lynx de dessiner le premier sprite, elle va se débrouiller toute seule pour lire la chaine et afficher tous les suivants. C'est donc beaucoup plus efficace que faire une boucle et demander les affichages individuels. Maintenant, pour de spremiers essais, et des petits programmes, ce n'est pas forcément très utile, mais dès qu'on gère un certain nombre de sprites, c'est nécessaire.

Pour Unix et le kit BLL, je ne sais pas trop, Handy doit exister (je crois que c'est ce que Romu et Damdam utilisait). Sinon, je pense que le nouveau kit de Karri doit exister en version Linux, il faudrait lui demander sur Atari Age. Ce kit est sans doute plus puissant, plus standard, mais pas compatible avec les fonctions BLL, c'est pourquoi je n'ai pas migrer.
Pour la correspondance entre la doc Epyx et les fonctions BLL, généralement, elles sont assez implicites de mémoire, je n'ai pas relu la doc Epyx récemment, mais je crois qu'ils parlent de SCBNEXT, SCBX, ...

Pour Rygar, en fait, les 512x512 ne correspondraient pas à la taille d'un seul sprite, mais de l'ensemble de la "map" de fond. D'ailleurs, il est surement préférable de découper un grosse image en bandelettes, pour justement profiter du clipping de la Lynx (= les sprites totalement hors écrans ne sont pas pris en compte)

Pour le bogus line, je vais essayer de compiler, pour voir.

Pour le HS, je suis informaticien (maitrise + école d'ingé) et c'est donc mon métier, mais je fais plutôt dans le texte vert sur fond noir (autrement appelé AS/400 ou Iseries pour les plus jeunes) . Ce qui a l'avantage de ne pas être trop C geek, mais a l'inconvénient de ne pas être trop C geek (ou ASM poulpiste)
Mais effectivement, j'ai commencé à programmer pour moi il y a plus de 20 ans, par passion, en GFA sur le ST. Donc, c'ets un peu des 2 en fait

sprites chainés : dans la structure de sprite attendu par le moteur de la lynx, tu as à la fin un emplacement réservé pour mettre l'adresse du suivant, ainsi tu peux "chainer" tes sprites et le moteur se charge de tous les afficher en une fois...

Ok, j'ai réussi à compiler.
En fait, l'erreur vient de la routine Vsync()
En effet, il faut mettre des espaces devant les lignes assembleur.
donc, remplace juste la routine Vsync() par :

void Vsync()
{
#asm
vretrace:
   lda $fd0a
   bne vretrace
#endasm
}

Faut pas chercher, ça fait partie des susceptibilités de l'assembleur ra65, il y a des endroits ou il faut des espaces, des endroits ou il n'en faut pas

Quand on fait un copié/collé de code les espaces disparaisent du coup ton bout de code était bon dés le départ mais encore faux dans ta solution /124.

Heureusement tu avait precisé que le pb était lié aux espaces manquants. J'ai compris et corrigé.

Et d'ailleur il faut obligatoirement des espaces aussi devant:

#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

En fait, c'est pour ça qu'il y a la balise [pre] ;) (j'ai édité le ./124, c'est plus clair maintenant) sinon non, pas besoin d'espace lors de la déclaration de ton SCB. Sinon, le programme marche comme tu veux ? Parce que je l'ai juste compilé, pas testé, il faut peut-être ajuster la direction de déplacement et il peut y avoir un effet de saut lors d ela remise de hoff à 0 ou 450.

Fadest (./127) :
Sinon, le programme marche comme tu veux ? Parce que je l'ai juste compilé, pas testé, il faut peut-être ajuster la direction de déplacement et il peut y avoir un effet de saut lors d ela remise de hoff à 0 ou 450.

Oui ca marche très bien, je n'ai pas vue de différence avec la 1ere solution si ce n'est qu'il n'est plus nécessaire d'initialiser les x, y et autre dir_x... .
Je mets le dossier complet en zip.

Fadest (./127) :
sinon non, pas besoin d'espace lors de la déclaration de ton SCB.

Si il en faut. J'ai refais le test (les résultats sont aussi dans le zip).

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

Fadest (ou vince) pourais tu m'aider pour effectuer un zoom sur un sprite.

En gros j'aimerais la ligne de code qui va bien...

dans la structure du sprite, tu n'as que la valeur de zoom à modifier, rien de plus

Il faut utiliser SCBHS (zoom horizontal) et SCBVS (zoom vertical) car en fait, les 2 sont indépendants.
Par exemple :
SCBHS(SCB3) = zoom;
SCBVS(SCB3) = zoom;

Attention, il s'agit de valeur hexadécimales (les 2 $100 dans la déclaration du SCB). Donc, en décimal, la taille normale (sans zoom), c'est 256.
Zoomé 2 fois, c'est 512, et 2 fois plus petit, (50, c'est 128.

L'extrait du cours que j'avais fait pour Revival consacré au gestionnaire de sprite :

Le Sprite engine – le gestionnaire de sprite

Pour rappel, un sprite est défini par une structure de 23 octets (le Sprite Control Block) et s’affiche par l’ordre DrawSprite(). Dans ce cours, nous allons examiner plus en détail certains paramètres du SCB.

La définition des différents bits de SPRCTL0 et SPRCTL1 a déjà été donnée dans le cours précédent. La gestion des collisions fera l’objet d’un cours prochain.
SCBX et SCBY servent à positionner le sprite au sein du monde virtuel.
SCBHS et SCBVS permettent de définir le zoom horizontal et vertical géré en hard par la console. La valeur décimale 256 ($100) correspond à 100%.
Deux autres fonctions hard du gestionnaire de sprites ne sont pas définies dans la librairie du kit BLL, il s’agit de stretch (qui déforme le sprite un peu à la manière du texte défilant dans les introductions des films Star Wars) et tilt. Pour pouvoir les utiliser, nous allons définir 2 nouvelles macros-fonctions à l’image de celles existantes pour SCBHS par exemple :
La valeur de stretch correspond aux octets 15 et 16 de la structure du sprite.
La valeur de tilt correspond aux octets 17 et 18 de la structure du sprite.
On définit donc les 2 fonctions de la manière suivante :
#define SCBSTRETCH(a) (*(uint *)((a)+15))
#define SCBTILT(a) (*(uint *)((a)+17))

Toutes ces fonctions sont définies par rapport au point d’action du sprite. Si dans un carré de 15x15, vous dessinez un cercle, le centre du cercle se trouvera donc aux coordonnées (8,8).
Il est dans ce cas plus simple de définir le point d’action du sprite en (8,8).
De cette manière, on positionne directement le centre du cercle à l’écran avec les coordonnées SCBX et SCBY. L’exemple dans le dessin ci-contre montre de quelle manière le zoom est affecté par la définition du point d’action.
[note maquette : inclure ici l’image action.gif si possible]
Le point d’action est défini par SPRPCK à la génération de l’objet sprite avec le paramètre –a.
Par exemple :
SPRPCK –t6 –S015015 –r001001 –a008008 –p0 cercle.bmp
définira le point d’action du sprite cercle aux coordonnées (8,8).
N’hésitez pas à faire des tests en particulier avec stretch et tilt qui permettent d’obtenir des effets étonnants en fonction du point d’action.

Il est également possible de redéfinir l’ordonnancement de la palette au niveau de chaque SCB. Par exemple, si la couleur 2 de la palette correspond au vert et la couleur 3 au rouge et que vous avez besoin de 2 sprites identique mais de couleurs différentes (vert et rouge), il suffit de créer 2 SCB avec un ordonnancement distinct de la palette.

Palette Lynx	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
Palette Sprite 1	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
Palette Sprite 2	0	1	3	2	4	5	6	7	8	9	A	B	C	D	E	F

La même couleur peut être utilisée plusieurs fois dans la redéfinition de la palette du sprite.
De plus, la couleur de transparence est la couleur 0 de la palette Lynx. Ainsi, vous pouvez donc facilement définir n’importe quelle partie d’un sprite en transparent.

Edit : comme ça, tu va pouvoir faire des tests avec le strecth et le tilt en bonus

Merci messieurs.

Encore une soirée que je vais passer seul devant mon ordi a tester tout ça !

(Je suis au bord du divorce avec ces conneries moi...!)

Et bien cela marche plutôt pas mal !
Ma première rom avec zoom !
Fichier joint : ZOOM.o

J’ai toujours un peu de mal avec le c, mon objectif initial était de faire en sorte que le poisson taille normal soit affiché à l’écran, si on appui sur croix haut le zoom se fait et quand on lâche croix haut le poisson taille normal se réaffiche, puis idem avec croix bas pour un zoom arrière (ne serait ce pas avec la fonction while et le !)

De plus existe t’il un moyen pour que le zoom soit progressif (que l’on ne passe pas de la taille 1 à 10 directement mais plutôt de 1 à 2 à 3 à 4 à 5 à 6 à 7 à 8 à 9 à 10) ?

oui, tu peux faire varier le zoom comme tu faisait varier la position de ton sprite dans ton programme précédent... un appui sur une flèche augmente ou diminue le facteur

En utilisant la fonction comme ceci "SCBHS(SCBpoi1) = zoom++;" ou SCBHS(SCB3) = zoom--;"?

J'ai repris mon apprentissage du zoom.

vince (./135) :
oui, tu peux faire varier le zoom comme tu faisait varier la position de ton sprite dans ton programme précédent... un appui sur une flèche augmente ou diminue le facteur

(Je precise que je bien lu mais que je n'ai pas compris ton explication Vince.)

Mon but est de faire apparaitre une image reduite à la taille minimale du pixel et de zoomer dessus jusqu'a ce qu'elle occupe tout l'écran.


Je peux y arriver en faisant comme cela :

char main()
{
InitIRQ();
CLI;

SetBuffers(SCREEN, RENDER ,0);

/* set the palette */
SetRGB(pal);
DrawFBox(0,0,160,102,0);
SCBX(SCB) = 80;
SCBY(SCB) = 51;
SCBHS(SCB) = 1;
SCBVS(SCB) = 1;
SCBDATA(SCB) = titre;

for(;
{

for(i=5; 10 > i; i++) {
SCBHS(SCB) = 2;
SCBVS(SCB) = 2;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=10; 15 > i; i++) {
SCBHS(SCB) = 4;
SCBVS(SCB) = 4;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=15; 20 > i; i++) {
SCBHS(SCB) = 6;
SCBVS(SCB) = 6;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }

for(i=20; 25 > i; i++) {
SCBHS(SCB) = 8;
SCBVS(SCB) = 8;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=25; 30 > i; i++) {
SCBHS(SCB) = 10;
SCBVS(SCB) = 10;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=30; 35 > i; i++) {
SCBHS(SCB) = 12;
SCBVS(SCB) = 12;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }

for(i=35; 40 > i; i++) {
SCBHS(SCB) = 14;
SCBVS(SCB) = 14;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=40; 45 > i; i++) {
SCBHS(SCB) = 16;
SCBVS(SCB) = 16;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=45; 50 > i; i++) {
SCBHS(SCB) = 18;
SCBVS(SCB) = 18;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }

for(i=50; 55 > i; i++) {
SCBHS(SCB) = 20;
SCBVS(SCB) = 20;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=55; 60 > i; i++) {
SCBHS(SCB) = 22;
SCBVS(SCB) = 22;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=60; 65 > i; i++) {
SCBHS(SCB) = 24;
SCBVS(SCB) = 24;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }

for(i=65; 70 > i; i++) {
SCBHS(SCB) = 26;
SCBVS(SCB) = 26;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=70; 75 > i; i++) {
SCBHS(SCB) = 28;
SCBVS(SCB) = 28;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=75; 80 > i; i++) {
SCBHS(SCB) = 30;
SCBVS(SCB) = 30;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }

for(i=80; 85 > i; i++) {
SCBHS(SCB) = 32;
SCBVS(SCB) = 32;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=85; 90 > i; i++) {
SCBHS(SCB) = 34;
SCBVS(SCB) = 34;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=90; 95 > i; i++) {
SCBHS(SCB) = 36;
SCBVS(SCB) = 36;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }

for(i=95; 100 > i; i++) {
SCBHS(SCB) = 38;
SCBVS(SCB) = 38;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=100; 105 > i; i++) {
SCBHS(SCB) = 40;
SCBVS(SCB) = 40;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=105; 110 > i; i++) {
SCBHS(SCB) = 42;
SCBVS(SCB) = 42;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }

for(i=110; 115 > i; i++) {
SCBHS(SCB) = 44;
SCBVS(SCB) = 44;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=115; 120 > i; i++) {
SCBHS(SCB) = 46;
SCBVS(SCB) = 46;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }


for(i=120; 125 > i; i++) {
SCBHS(SCB) = 48;
SCBVS(SCB) = 48;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }

}
}


Le problème c'est que c'est long et lourd en terme de Ko.

J'ai essayer d'initialiser HS et VS pour faire qqchose du style for HS=1; 256>HS;HS++ mais cela ne donne rien.

Et pourquoi pas tout simplement ?

for(i=1; i<=256; i++) {
SCBHS(SCB) = i;
SCBVS(SCB) = i;
DrawSprite(SCB);
Vsync();
SwapBuffers(); }

Pfff c'est dingue comme c'est simple !

Je voudrais que ma séquence ne soit jouée que deux fois, alors j'ai fais :

for (z=0; z<2; z++)
{

for(aa=0; 340 > aa; aa++) { (plein de petites images arrivent sur l'écran)

DrawSprite(SCBfond);

y++;
if (y>25) y=25;
DrawSprite(SCBt1);
SCBX(SCBt1) = x;
SCBY(SCBt1) = y;

w++;
if (w>25) w=25;
DrawSprite(SCBt2);
SCBX(SCBt2) = v;
SCBY(SCBt2) = w;

s++;
if (s>25) s=25;
DrawSprite(SCBt3);
SCBX(SCBt3) = r;
SCBY(SCBt3) = s;


u++;
if (u>25) u=25;
DrawSprite(SCBt4);
SCBX(SCBt4) = t;
SCBY(SCBt4) = u;



a++;
if (a>39) a=39;
DrawSprite(SCBt5);
SCBX(SCBt5) = a;
SCBY(SCBt5) = b;



c++;
if (c>59) c=59;
DrawSprite(SCBt6);
SCBX(SCBt6) = c;
SCBY(SCBt6) = d;


e--;
if (e<79) e=79;
DrawSprite(SCBt7);
SCBX(SCBt7) = e;
SCBY(SCBt7) = f;



g--;
if (g<99) g=99;
DrawSprite(SCBt8);
SCBX(SCBt8) = g;
SCBY(SCBt8) = h;



j--;
if (j<59) j=59;
DrawSprite(SCBt9);
SCBX(SCBt9) = o;
SCBY(SCBt9) = j;

l--;
if (l<59) l=59;
DrawSprite(SCBt10);
SCBX(SCBt10) = k;
SCBY(SCBt10) = l;


n--;
if (n<59) n=59;
DrawSprite(SCBt11);
SCBX(SCBt11) = m;
SCBY(SCBt11) = n;


q--;
if (q<59) q=59;
DrawSprite(SCBt12);
SCBX(SCBt12) = p;
SCBY(SCBt12) = q;

Vsync();
SwapBuffers();
}
(Ca y est toutes les images sont en place maintenant je place une nouvelle image et je la zoom)

for(i=129; i<256; i++) {
SCBHS(SCBtitre) = i;
SCBVS(SCBtitre) = i;
DrawSprite(SCBtitre);
Vsync();
SwapBuffers();
}

for(i=340; i<500; i++) {
DrawSprite(SCBtitre);
Vsync();
SwapBuffers();
}
(je garde à l'écran mon image "titre")


}

}


Mais cela ne fonctionne pas.
Au final le programme aprés affiché "titre" jusqu'au time aa=500 réafiche l'image "titre" en position de zomm 129 puis plus rien.

Là comme ça, je ne vois pas le problème...
Par contre, tu as des trucs un peu superflus, mais rien de génant à priori.

aa et i sont définis comment ?

si tu n'as pas spécifié, il les défini sur 8 bits par défaut donc 0 à 255, donc comportement spacy si tu testes 340 ou 500...

Pour aa et i je n'ai rien fais de plus que les "int aa;" et "int i;" en début de programme.

Les entier (int) sont sur 1 octet sur Lynx?

Non, les char sont sur 1 octet
Un int, c'est 2 octets

Donc c'est "normal" et ils vont jusque 32 767.

Et donc je ne comprend pas ceci.

vince (./142) :
aa et i sont définis comment ?

si tu n'as pas spécifié, il les défini sur 8 bits par défaut donc 0 à 255, donc comportement spacy si tu testes 340 ou 500...

Si on ne spécifie pas de type le type est char?

Tu te lance dans la prog sur lynx PowerMarcel ?!

PowerMarcel (./146) :
Donc c'est "normal" et ils vont jusque 32 767.

Et donc je ne comprend pas ceci.

vince (./142) :
aa et i sont définis comment ?

si tu n'as pas spécifié, il les défini sur 8 bits par défaut donc 0 à 255, donc comportement spacy si tu testes 340 ou 500...

Si on ne spécifie pas de type le type est char?

nan, si tu spécifies pas le type est en erreur pour du C...

je me suis mal exprimé mais la question concernait en effet int ou char...

Oki, tout est donc "normal", on est dans du C standard

Pour ce qui est du développement pour le moment il n'est pas prévu que je m'y mettes mais comme j'ai fait du C/C++ par le passé j'ai suivi le post par curiosité

Sinon, le nouveau compilo C utilisé par Karri dans son kit est en fait un compilo 6502 avec des librairies pour toutes (ou presque) les bécanes ayant utilisé ce processeur. Donc les 8 bits Atari aussi

http://www.cc65.org