Pleins d'autres questions bêtes - Page 1

Salut,

Voici donc une petite compilation de mes nombreuses interrogations.
Le précédent sujet (...de "questions bêtes") étant plutôt orienté linux et environnement de développement, j'ai pris la liberté d'ouvrir ce nouveau sujet.

Je code et je compile sans trop de soucis et j'obtiens des résultats déhà fort intéressants. Je code principalement en C même si un petit bout d'ASM ne me fait pas trop peur (mais hors de question de coder 100% en ASM). Voici mes questions :

1. A propos de BLL ; ra65 versus lyxass.
J'ai commencer par lire le "tutorial" du sujet "J’aimerais m’y mettre mais j’ai besoin d’aide". Je me suis rendu compte rapidement que le kit BLL installé dans c:\lynx n'était absolument pas nécessaire pour compiler mes programmes. Donc au final, le compilo cc65 (NEWCC65) donné par fadest est-il le compilo de BLL ou bien un autre compilo cc65 ? Les fichiers lynx.olb et c.olb du compilo cc65 sont-ils issus de ce même kit BLL (il semblerait que oui au vu des fichiers .h). Bref j'arrive à compiler sans problème mais qq éclaircissements ne seraient pas de refus . De la même façon pourquoi y a t'il deux linkers différents ? Quels sont les différences justement entre lyxass et ra65.

2. Les fonctions sprintf, sscanf, etc. ne sont pas dans le kit n'est ce pas ? De la même façon, itoa semble dans le kit (déclaration dans le stdlib.h) mais ne semble pas implémenté (erreur lors du linkage) kesako ?

3. Pas de time() ? Comment disposer d'un timer alors ? En asm (je me débrouillais dans le temps en asm, mais ce n'est plus trop le cas ) ? J'ai vu qu'il existait une structure timer définit dans le stdlib.h... A quoi sert-elle ?

4. Les IRQ ? InstallIRQ et consorts, ca sert a quoi en fait ? J'ai bien compris que le 0 et le 2 étaient réservés aux interruptions VBL et HBL, mais quid des autres ? Si je fais un InstallIRQ(4), ca me sert à quoi ?

5. (question à réponse facultative ) En regardant les différents codes, j'ai constaté qu'il y avait au moins deux façon d'écrire VSYNC (voir la méthode de mathias domin par exemple). Laquelle est la plus "juste" ?


Voila c'est tout pour le moment ! Merci d'avance !

1/ De mémoire, j'avais du remplacer le compilo c qui était livré dans le kit BLL par une version plus récente.
Comme je l'avais mentionné, j'avais zippé ce que j'avais sur ma clé USB, mais c'est clair que c'est tout sauf propre (surtout qu'à la base, j'ai commencé par un truc nécessitant cygwin, puis Panther, puis le kit BLL, puis un upgrade des compilos...)
Après, BLL, c'est surtout une librairie que les outils de développements.
lynx.olb et c.olb devaient effectivement être fournis avec le kit BLL
lyxass et ra65 sont 2 assembleurs 6502, l'un est destiné à compilé le code généré par cc65 (ce doit être ra65 de mémoire), l'autre à compilé du code écrit à la main. En effet, le code généré par cc65 ne passe pas dans lyxass... Je n'ai jamais bien su pourquoi.

2/ non, pas de printf & co. Pour écrire du texte, il y a juste Textout et Textout2 qui permettent d'écrire du texte (mais, il s'agit en fait d'une fonction qui affiche des sprites, ces sprites étant l'alphabet, mais pas au complet)
itoa, c'est integer to ascii, c'est ça ? Je ne sais pas si la fonction existe ou pas...
Mais bon, vu que dans je ne sais plus quel exemple (et dans mes sources), on retrouve une fonction à la mano pour le faire...

3/4/5/ joker, au moins pour le moment, ça fait trop longtemps que je n'ai pas jeté un oeil à un source Lynx

Sinon, le "nouveau" kit C (celui mentionné dans le topic plus Linux) doit surement offrir tout ce que tu cherches (printf, ...) vu que les librairies sont plus standards, (mais peut-être un peu moins proche du hard ?)
Depuis le temps que je dis, faudrait vraiment que je l'installe ce kit

1)
Ok c'est ce que je pensais... Bon pour info ca compile très bien, il y a juste qq bugs avec le compilo (genre tous les commentaires avec d'avoir du code C doivent être c-style /* ... */, mais une fois qu'on a mis du code C on peut y aller avec le double slash // ). Enfin on survit une fois qu'on a saisi les subtilités ! Puisque lynx.olb et c.olb linkent toute les fonctions "C" de BLL je suppose que ca ne sert à rien que je me penche trop la dessus. En revanche pour la stdlib c'est vraiment une implémentation partielle, et donc le itoa (entier to string) ne semble pas implémenté bien qu'il soit déclaré dans l'en tête de stdlib.h.

2)
Pour textout je l'avais déjà vu, mais cela suppose de faire toutes les opérations de manipulation de texte à la main. D'ailleurs textout me semble être extrêmement lent !

3) J'ai trouvé une solution pour connaître le raffraichissement de l'écran, ce qui me permet de synchroniser pas mal de chose, mais je ne suis pas absolument sûr de la pertinence de ma méthode (je compte le nombre de VBL "à vide", cad sans aucun traitement autre que le comptage proprement dit, puis j'utilise cette valeur que je compare alors au nombre de VBL par raffraichissement d'écran).

Sinon :
"Depuis le temps que je dis, faudrait vraiment que je l'installe ce kit"
Pour avoir lu, disons 95% des sujets du forum developpeur, tu as du écrire cela une bonne centaine de fois J'avoues avoir aussi regarder et n'avoir pas trouvé cela très "user-friendly" et c'est pas faute de me débrouiller en anglais !

On est sur une machine assez peu puissante et sans OS, donc il faut s'attendre à des limitations par rapport à du c sur des machins linux (ou je sais pas quoi) modernes...
Donc soit on a des trucs standards assez lents et génériques, soit on fait soi même des choses spécifiques, optimisées et plus rapides

C'est vrai, ceci dit on pourrait s'attendre à ce que les fonctions de BLL soient justement optimisées Et je suppose que c'est le cas pour la plupart d'entre elle.

lordkraken (./3) :
Sinon :
"Depuis le temps que je dis, faudrait vraiment que je l'installe ce kit"
Pour avoir lu, disons 95% des sujets du forum developpeur, tu as du écrire cela une bonne centaine de fois J'avoues avoir aussi regarder et n'avoir pas trouvé cela très "user-friendly" et c'est pas faute de me débrouiller en anglais !

En fait, je me suis tellement habitué aux fonctions BLL, que changer de librairie reviendrait en quelque sorte à changer de machine cible. Et du coup, tant qu'à faire l'effort d'apprendre une nouvelle librairie, autant le faire pour une autre bécane (la Jaguar par exemple).
Et puis, j'aime bien la simplicité des fonctions BLL, manque juste une meilleure gestion de la ROM (encore que, je sais faire à peu près ce que je veux avec les données, mais le nouveau kit permet de charger/décharger du code) et des fonctions Comlynx pour les nuls.

Pour Textout, comme je l'ai dit, ce sont des sprites, mais je ne sais pas s'ils sont affichés linké ou 1 par 1...

Mais ils y a du monde dans la section dev lynx en ce moment ! C'est cool ça !

Bon courage aux nouveaux et ne lâchez pas la Lynx avant de nous avoir fait au moins un petit jeu ou deux

Fadest (./6) :
Pour Textout, comme je l'ai dit, ce sont des sprites, mais je ne sais pas s'ils sont affichés linké ou 1 par 1...

De mémoire il s'agit en effet d'une chaine de sprites géré par le moteur "hardware".

Probablement...Mais comme ce sont des sprites transparents ca ralentit bien quand même... Heureusement sur Lynx on n'a pas des jeux pour intello donc ca va

Le problème ne se poserait pas.

En effet comme le disait Fadest, quand tu as des besoins particuliers, tu développe du code particulier et pour reprendre l'exemple du texte, les jeux ne vont pas l'utiliser tel quel et préférer des solutions moins génériques mais plus performantes...

c'est fadest qui a dit ça ?

Nan mais c'est quand même ce que j'ai fait dans certains cas.
Et de toutes manières, la fonte standard de Textout est plutôt moche et ça bouffe environ 2ko de RAM donc si le but est juste d'afficher des scores par exemple, on gagne à se faire sa propre fonction.