240

RYGAR (./239) :
Ultime tentative avec ton code vince et non ça marche pas MAIS ! si je rajoute un "int i;" ça marche !!

Merci à vous deux les gars. Je reviens vers vous d'ici 4-5 jours avec tout un tas de questions histoires de comprendre vraiment le fonctionnement du truc.

Philippe apparemment tu n'utilise pas la même méthode que vince et j'aimerais pouvoir comprendre aussi comment tu fais donc si tu pouvais m'expliquer dans mon code deux poste plus haut pourquoi cela n'as pas marché je suis preneur.

Merci encore à vous deux et à dans qque jours wink
tu as oublié de mettre la boucle principale avec cette commande:
while(1)



Et après compteur = 99; tu met les lignes suivantes:
SCBDATA(SCBc0) = c0; SCBDATA(SCBc1) = c1; SCBDATA(SCBc2) = c2; SCBDATA(SCBc3) = c3; SCBDATA(SCBc4) = c4; SCBDATA(SCBc5) = c5; SCBDATA(SCBc6) = c6; SCBDATA(SCBc7) = c7; SCBDATA(SCBc8) = c8; SCBDATA(SCBc9) = c9; char compteur; SCBX(SCB_UNITES) = 81; SCBY(SCB_UNITES) = 50; SCBX(SCB_DIZAINES) = 74; SCBY(SCB_DIZAINES) = 50;
alors que c'est inutile.



Pour décrementer, utilise une autre variable, comme:
au début:char tempa;

après char main() :compteur = 99; tempa = 8;

dans la boucle principale :tempa-=1; if (tempa==0) { tempa=8; compteur-=1 if (compteur==0) compteur=99; }
et si tu as oublié de mettre un sprite pour le fond, met donc un DrawFBox(0,0,160,102,0);
au début de la boucle principale :while(1) { Vsync(); SwapBuffers(); DrawFBox(0,0,160,102,0);
code complet:// jp 17/12/2012 #include <stdlib.h> #include <lynx.h> #include <lynxlib.h> #include "inc\c0.pal" #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); // ------------------------------------ char tempa, compteur; int i, unite, dizaine; // clip du sprite chiffres: 0123456789 extern uchar c0[]; extern uchar c1[]; extern uchar c2[]; extern uchar c3[]; extern uchar c4[]; extern uchar c5[]; extern uchar c6[]; extern uchar c7[]; extern uchar c8[]; extern uchar c9[]; uchar *chtab[10] = {c0, c1, c2, c3, c4, c5, c6, c7, c8,c9}; uchar SCB_UNITES[]; // déclaration d'un nouveau controleur de sprite uchar SCB_DIZAINES[]; // déclaration d'un nouveau controleur de sprite #asm _SCB_UNITES 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 _SCB_DIZAINES 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 // ------------------------------------ void Vsync() { #asm vretrace: lda $fd0a bne vretrace #endasm } char main() { InitIRQ(); CLI; SetBuffers(SCREEN, RENDER ,0); SetRGB(c0_pal); SCBX(SCB_UNITES) = 81; SCBY(SCB_UNITES) = 50; SCBX(SCB_DIZAINES) = 74; SCBY(SCB_DIZAINES) = 50; SCBNEXT(SCB_UNITES) = SCB_DIZAINES; // chainage de sprite compteur = 99; tempa = 8; // ********************* Boucle principale ********************* while(1) { Vsync(); SwapBuffers(); DrawFBox(0,0,160,102,0); tempa-=1; if (tempa==0) { tempa=8; compteur-=1; if (compteur==0) compteur=99; } unite = compteur % 10; dizaine = compteur / 10 % 10; SCBDATA(SCB_UNITES) = chtab[unite%10]; SCBDATA(SCB_DIZAINES) = chtab[dizaine%10]; DrawSprite(SCB_UNITES); // un seul drawsprite jean-philippe } // ********************* Fin de la Boucle principale ********************* }
avatarTravaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx

241

Désolé, pas trop eu le temps de regarder...

Par contre : 095 unite = compteur % 10; 096 dizaine = compteur / 10 % 10; 097 SCBDATA(_SCB_UNITES) = chtab[unite%10]; 098 SCBDATA(_SCB_DIZAINES) = chtab[dizaine%10];
Ca module à fond là grin

Au niveau perf, un modulo est pas forcément ce qu'il y a de plus efficace, alors le faire 2 fois sur chaque variable unite et dizaine, c'est pas forcément utile. Déjà, sur dizaine, c'est pas utile à partir du moment ou compteur est < 100 (cf ce que fait Vince, qui est équivalent, mais sans la redondance).

Une solution, pour se passer du modulo serait :
dizaine = compteur/10;
unité = compteur -10*dizaine;
(mais je ne sais pas quelle solution est la plus efficace, en terme de performance et de taille de code généré)

242

Oui je n'ai pas voulu aborder cette problématique, système D en déplaçant simplement l'accolade:
tempa-=1;
if (tempa==0)
{
tempa=8;
compteur-=1;
if (compteur==0) compteur=99;

unite = compteur % 10;
dizaine = compteur / 10 % 10;
SCBDATA(SCB_UNITES) = chtab[unite%10];
SCBDATA(SCB_DIZAINES) = chtab[dizaine%10];
}// je déplace l'accolade ici, le 6502 sera ainsi moins sollicité.
avatarTravaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx

243

Vu que ta variable C s'apelle _SCB_UNITES, dans ton code assembleur, ne devrait-elle pas s'appeler __SCB_UNITES ?
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

244

vince (./243) :
Vu que ta variable C s'apelle _SCB_UNITES, dans ton code assembleur, ne devrait-elle pas s'appeler __SCB_UNITES ?
corrigé, bien vu vincent. smile
avatarTravaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx

245

Super tout ça top

Bon 7h de retard pour mon vol du soir je suis claqué mais dés demain je reprends tout cela.

246

J'ai enfin réussis à utiliser des fichiers externes ! chante
Il fallait mettre les .spr dans lynxer50 (et non pas dans le dossier OBJ). Deux années pour y arriver, je suis bien le plus nul des coders lynx.
avatarTravaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx

247

Beaupixel (./246) :
Deux années pour y arriver, je suis bien le plus nul des coders lynx.


En tout cas tu es un des plus tenace wink

Pour en revenir sur le compte à rebours cela m'a permis de comprendre vraiment beaucoup de choses et c'est agréable. Le "tempa" est vraiment super pratique car il permets de régler la vitesse du timer le plus simplement du monde.


248

on ne lâche rien ! wink

Ben oui, une petite variable et hop, c'est fait. Les pro utilisent des timers, mais notre console a une architecture fixe, c'est pas comme sur PC. La commande Vsync et sa copine Swapbuffers sont deux amies vraiment formidable. smile
avatarTravaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx

249

oulah, la lynx a beau avoir une "architecture fixe", elle a 8 timers indépendants à disposition du développeur, à titre de comparaison, sur un processeur x86 il faut souvent se contenter de l'INT8... L'utilisation de vsync peut se révéler être un piège, vu qu'on peut changer la fréquence d'affichage, ça impactera directement le rythme des vsync d'une part et d'autre part, si tu as dépassé le temps d'une frame alors vsync attendra la fin de la frame suivante, à manier avec précaution donc.
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

250

vince (./249) :
oulah, la lynx a beau avoir une "architecture fixe", elle a 8 timers indépendants à disposition du développeur, à titre de comparaison, sur un processeur x86 il faut souvent se contenter de l'INT8... L'utilisation de vsync peut se révéler être un piège, vu qu'on peut changer la fréquence d'affichage, ça impactera directement le rythme des vsync d'une part et d'autre part, si tu as dépassé le temps d'une frame alors vsync attendra la fin de la frame suivante, à manier avec précaution donc.
Justement, j'ai testé mon pac man sur la console, et il y a un soucis qui est lié à l'utilisation du tableau de x sprites de 11 octets. Il y a de larges bandes noires, ou blanches, horizontales qui clignotent rapidement, donc un problème de rafraichissement.

code du tableau de 112 sprites de 11 octets (que fadest m'avait conseillé dans le post "un nouveau glouton" pour l'affichage des nombreuses pastilles) :
extern char SCB[112][11] at (0xfff8-16320-112*11); // spr0 est le "modèle" de sprite de 11 octet pour initialiser une occurence de SCB2[] extern char spr0[11]; // init_scb est le premier sprite à afficher, en fait, il pointe sur un sprite vide // j'aurais aussi pu le faire pointer vers le background // l'important dans le _init_scb, c'est dc.w _SCB2 // qui fait pointer le sprite suivant vers le premier du tableau SCB extern char init_scb[23]; #asm ; init_scb est utilisé pour initialiser les registres du SpriteEngine ; avec les paramètres adéquats (palette...) ; Using this trick, the 8*11 spr[]-SCBs only need 11 Bytes each! _init_scb: dc.b $c1, $10, $20 dc.w _SCB ; PTR_NEXT pointe vers le 1° sprite visible (SCB[0]) dc.w dummy ; PTR_DATA pointe vers un sprite "inexistant" dc.w 200, 200 ; x,y -> on affiche en dehors de l'écran dc.w $100, $100 ; pas de zoom dc.b $01, $23, $45, $67, $89, $ab, $cd, $ef dummy: dc.b 0,0,0 ; le sprite "inexistant" ; spr0 sert de modèle au sprites du tableau SCB _spr0: dc.b $c4, $08, $02 ; CTL0, CTL1 = réutilise la palette, COLL dc.w 0, 0 dc.w 0, 0 #endasm
J'ai eu l'idée de remplacer le vsync() par le VSYNC de Matthias Domin (sprdemo4), mais le problème est toujours là.

avatarTravaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx

251

le code présenté a l'air correct, je ne suis pas sûr de comprendre ton problème...
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

252

Le probleme ne doit pas venir de ta déclaration de liste chainée.
Celle ci est elle bien termininée (SCBNEXT du derneir qui est égal à 0)?

253

Alors, j'ai enlevé un setbuffer situé après celui qui est juste après le main(), oui j'avais mis deux setbuffer, et j'ai mis le couple irq (install et enable) et plus haut les déclarations de variables complexes de l'exemple sprdemo4.

Mais pour un autre jeu en préparation j'ai du modifier la valeur 16320-112*11 pour 20400-112*11.
Le dernier scbnext=0 et après je le lie à un autre contrôleur de sprite (pour un zoom indépendant).
pour le pacman je n'ai pas encore testé, les journées sont trop courtes..
avatarTravaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx

254

Tu sais à quoi sert SetBuffer ? parce que la plupart du temps, tu en as besoin de 2 : écran physique et écran logique. On peut ajouter 1 3° si on veut gérer les collisions.
On peut n'en utiliser qu'un pour un jeu calme (texte only) car dans ce cas, tout se dessine direct à l'écran, donc si c'est jeu qui bouge un peu, ce n'est pas fluide…

255

oui je sais, mais j'ignore pourquoi j'avais rajouté un setbuffer. Cela fonctionne bien maintenant, j'ai mis une vidéo sur le post "un nouveau glouton".
avatarTravaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx

256

Sympa la vidéo ! Le jeu a bien avancé !!!!

257

Le lynxer50 est toujours limité à 16 fichiers externes, ou bien existe-il une version plus évolué ? Le code source est dispo ou pas ? Parce qu'avec si peu de fichiers externes, difficile, voir impossible de faire un jeu riche à base de tiles.

J'ai aussi besoin d'une routine asm pour du tir orienté. Mais je sais seulement faire des additions ou soustractions, j'ai aucune idée comment faire une multiplication ... Vous avez récupéré du code venant de la nes ou du c64 avec des jeux de tirs genre 1943 ? J'ai regardé des vidéos des jeux 1942 et 1943 sur nes, et on voit bien l'évolution sur ce dernier, avec beaucoup plus de bullets orientés vers le shiplayer.
avatarTravaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx

258

Je crois qu'il doit exister une version de lynxer à 128 fichiers externes modifiée par Sage, mais je ne l'ai pas.
Lorsque j'avais eu besoin de plus de 14 fichiers externes, je m'étais bricolé une solution à base de librairie...
Je faisais une librairie avec tous les objets inclus dedans. Grâce à une option, je pouvais lister les adresses et tailles de chaque objet, par la suite, dans mon code, j'incluais ça sous forme de tableau, et quand je voulais l'objet n, je me positionnais à l'offset qui allait bien et je lisais les x octets...

Je ne sais plus si j'ai encore un code source d'exemple (c’était pour un test utilisant les graphs de dungeon master, mais la majeure partie a été perdue), et pas ici en tous cas...

259

Fadest (./258) :
Je crois qu'il doit exister une version de lynxer à 128 fichiers externes modifiée par Sage, mais je ne l'ai pas.
Lorsque j'avais eu besoin de plus de 14 fichiers externes, je m'étais bricolé une solution à base de librairie...
Je faisais une librairie avec tous les objets inclus dedans. Grâce à une option, je pouvais lister les adresses et tailles de chaque objet, par la suite, dans mon code, j'incluais ça sous forme de tableau, et quand je voulais l'objet n, je me positionnais à l'offset qui allait bien et je lisais les x octets...

Je ne sais plus si j'ai encore un code source d'exemple (c’était pour un test utilisant les graphs de dungeon master, mais la majeure partie a été perdue), et pas ici en tous cas...
128 fichiers c'est plus confortable, je vais voir avec lui, merci pour ta réponse,

up: en fait la limite est plutôt de 11 fichiers externes, c'est plus grave que je croyais ! Je laisse ici mon code (faut au bas du programme faire 11 tests dans la boucle incluant LoadCartDir, et bien sûr désactiver le dernier SCBDATA pour que ça marche)
http://www.mirari.fr/fb67
Je précise que j'ai deux lynxer, l'un de 1999 et l'autre de 2004, mais les deux refusent d'aller plus loin que 11 fichiers externes... c'est la vie.

Projet_ext1
http://www.mirari.fr/Wz9c
avatarTravaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx

260

Sur le site de Sage:
http://bjoern.spruck.net/lynx/
il faut télécharger le lynxdir 1_6 (Lynxdir ROM Cartridge Creator). Et aussi newcc65_mod.tgz
Si j'ai bien compris, il a fait une nouvelle bibliothèque newcc65

concernant mon code il a identifié un problème:
The problem is the following: Entry #16 is not existing. Now it depend on your version of LoadFile, if it is skipping this entry automatically or not. if not, you the next files after 15 is 17, and you have to take care yourself in your code.
>>> LoadCartDir(2+cpti);LoadCartBlock(FileEntry[0], tatab[cpti%12]);

This is not the best way to do that!
You better use LoadFileTo(number, adress).
Là il me recommande d'utiliser la commande LoadFileTo à la place de LoadCartDir et LoadCartBlock

Et de remplacer le code file.c hélas, je ne vois pas où est placé ce code, donc où le mettre ?

http://www.mirari.fr/RGtc

ensuite d'autres explications mais je suis perdu là:
If you do _not_ want to change your lig/code, the simplest way for you is to use lynxdir in compatibility mode, thus you stay with BLL directory structure, but without the troyan horse.
lynxdir contains example mak files for several possible variations of ROM image building.
I will send you examples fitting for your case if needed.

But teh first question you have to answere yourself: Stay with the file code in the newcc65 lib or use a different one. The one in newcc65 lib is _only_ for BLL styledirectory and 1024bytes/block ROMs (max 256k). If you have different requierements, you have to exchange the code with mine (for example).

et aussi:
a few more infos

http://www.atariage.com/forums/topic/191897-rom-directory-creator

and, here is the mak file for lynxdir:

;
; Example file, BLL compatible (newload)
; but using the EPYX encryption, NOT the troyan
; for compatibility, file 16 is the troyan, still
; if not, remove the TROYAN entry below
;
#TROYAN
#HACK1024
#BLOCKSIZE 1024
#DIRSTART 410
#EPYX
insert.o
main.o
#BLL
#DIROFFSET 896
#COPY0
#COPY1
sprite1.dat
sprite2.dat
avatarTravaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx