Genlib modulaire au run-time - Page 1

yop,

je pensais à un truc. y aurait pas moyen d'avoir genlib chargé au run-time par morceaux ? Parce que les 20 ko pour avoir les gris synchros et des bigs sprites, ça fait beaucoup

Je 'mexplique un peu plus. Il pourrait y avoir le découpage suivant :
- niveaux de gris (initialisation, screens, dscreens)
- sprites (tous les formats)
- IO (clavier et link)
- plans (toutes les fonctions de planes, et vu leur déroulement, ce sont à mon avis celles qui explosent le plus la taille de la lib)
- misc (lignes, cercles etc...)

Ecrire des header du genre : genlib::line equ genlib5@0000. Comme ça, si le découpage est intelligemment fait, seules les bonnes parties seront chargées.
Par contre, ça casserait les vieux binaires... Une solution serait alors de faire une dll factice, avec juste des équivalences :
genlib:ut_plane:
jmp genlib4:utplane

Ca perdrait le temps d'un jmp (mais ça devrait pas être critique) et ça ne casserait rien normalement.
Sur le plan des binaires de la lib, il suffit de faire un pack archive pour que ce soit totalement transparent pour le end user.
Faut bien reconnaitre que genlib est très bien pour CF ou des jeux très orientés map, mais pour le reste, on ose pas y toucher à cause du poids...

[nosmile]

Tu as les sources

Je m'y attendais pas tiens Mais comme ça revient à forker, je voudrais ton avis avant. Pas comme quand je porte un de tes programmes pour GNU as et que je m'entends dire que tu t'en fous, quoi.

Je voulais le faire, mais ca s'annonce chaud techniquement à cause des dépendances inter procédurales.

Ah merde, si toi t'as échoué, alors... c'est le découpage en fait qui est chaud à mettre en place intelligemment je supopse, plus que la réorganisation des sources proprement dite ?

Sinon, parle-moi en quelques mots des difficultés que tu as rencontrées, je verrai si j'ai des idées une fois que j'attaquerai Et sinon, sur les concepts que j'ai donnés, tu penses quoi ? Ca assurrerait la compatibilité binaire et source si je me trompe pas.

Il y a peut-être moyen de réécrire des procédures utilisées par plusieurs fonctions de domaines différents, l'overhead pourrait ne pas être énorme, et au final ça gagnerait en modularité. Mais à voir ce que ça peut donner.

"Self Modifying Code"
Tout est là.

genlib n'arrete pas de se modifier sans arrêt de partout

Ah oui, donc aller faire du smc à plusieurs endroits au lieu d'un seul en serait pas génial, sans parler du risque d'erreur pour une lib qui est stable maintenant ...

Rien que l'init fait un reset des smc des autres fonctions.
La fonction fournissant l'ecran virtuel a utiliser fait du smc des autres fonctions.

J'ai aussi essayé de découper genlib dans le but d'en faire une librairie statique, j'ai laissé tomber, c'est trop bordélique, tout dépend de tout.

C'est mort quoi avant de commencer quoi PpHd, Genlib2 !!!

Mais pourquoi tu as besoin de ça ? C’est si dramatique de charger la dll complète de genlib ? 20 ko ce n’est pas si énorme…

Erf, ça doit être une maladie de courir après les octets.

Tiens, flemme de créer un autre topic, je suis en train de faire ma synchro. Le nez dans la doc, je lis ça :

— Global C Variable: unsigned long gl_timer
 — Global ASM Variable: long: genlib::timer
 
 It is the internal timer of genlib (a volatile unsigned long). You can read and write this variable. It is incremented each time the Genlib interruption (AI5) has
finished to display one screen. This timer is around 90 Hz. It is independent of the hardware of the calculators (or overclocked calculator). It is useful to
synchronize your code so that you have a constant frame rate in your program. It is also useful for benching a grayscale-graph routine. Why only
grayscale-graph routines? Because the interruption used the CPU to exchanged the screens, to emulating a gray screen. But on Hardware v2.00,
it is quite consuming... 
To do a 30 Hz waiting, you could do: 
          while (gl_timer <= 2);
          gl_timer = 0;
     
 — Global C Variable: unsigned short gl_frame_timer
 — Global ASM Variable: word: genlib::frame_timer
 
 It is the 2nd internal timer of genlib. It is incremented each time Genlib interruption (AI5) has finished to display one complete DScreen. This timer is around
30 Hz and it is independent of the hardware of the calculators (or overclocked calculator). It is useful to synchronize your code so that you have a constant
frame rate in your program. It is better than gl_timer because you synchronize your code with the DScreen and not the Screen swapping. 
To do a 30 Hz waiting, you could do: 
                  while (!gl_frame_timer);
                  gl_frame_timer = 0;

Alors faut utiliser lequel ? Un seul suffit ? J'ai déjà vu des exemples (et des conseils) avec les deux... Je croyais également que gl_timer était en rapport avec le fait qu'il y a une frame de retard entre ce qui est écrit et ce qui est affiché sur HW1.

J'ai besoin qu'on me ré-explique un poil les choses

si tu veux le meilleur, faut les deux.
cf les exemples.

Ok, merci.

Donc je récapitule en deux mots :

loop:
-> genlib::timer
-> gestion clavier + dessin sur le buffer non affiché
-> genlib::frametimer
-> swap des dscreens
-> bra loop

C'est bien ça ?

Autre question sur les variables :

long genlib::sprite_tile_adr                                           [Global ASM Variable]
word: genlib::sprite_scr_x                                             [Global ASM Variable]
word: genlib::sprite_scr_y                                             [Global ASM Variable]
  sprite tile adr is the address of the SPRITE 16 array used by gl_put_sprite_16 functions.
  sprite scr x and sprite scr y are the coordinates X,Y of the virtual sprite-plane. It is used
  by all sprite functions except fast-sprite ones.

sprite_scr_x/y sont utilisés également pour le simple affichage d'un sprite à l'écran, en-dehors du cadre de l'utilisation dans une map ? Ces variables sont-elles initialisées à 0 (garanti) ou faut-il le faire ?
(et à cause du bug de A68k qui oblige à écrire des genlib@1234 dans le code, c'est pas évident de savoir tout ce que fait l'init).

(ps : ah oui et en relisant rien que l'init, on a un aperçu des dépendances entre les fonctions )

Non :O

while for ever
Mise à jour de tout élément non graphique (gestion clavier, ...).
Mise à jour des Virtual Screen des plane
Synchro sur genlib::timer pour vérifier que l'interruption a pris en compte le changement d'écran.
Affichage de tout ce qui est graphique
Synchronisation sur le frame timer pour que le jeu soit à temps constant.
Swap des DScreen
Mémorisation de genlib::timer pour synchro ultérieure

Ma méthode va faire quoi ? Que je perds le temps jusqu'à ce que genlib::timer soit bon pour commencer à m'occuper de ce qui n'est pas graphique ? Je perds donc au pire une frame à ne rien faire, au lieu de faire des calculs, c'est ça ?

(et je déduis, si j'ai bien compris ta réponse, que c'est bien genlib::timer qui empêche les merdes sur HW1, qui apparemment n'existents pas avec les controlleurs d'écran >=HW2)

Oui

PpHd, toujours ausis concis, ça m'éclate à chaque fois

Bon ben ok, je ne gère pas de plane, mais je pourrai lire le joypad et calculer une position de curseur par exemple, ainsi que lse effets qu'il engendre, merci bien du tip.

bon, j'ai implanté la lecture du joypad proprement, mai j'aimerais savoir autre chose. Je suppose que pour lire une entrée au clavier (un nom ou autre chose), je vais pas me faire suer avec une analyse de Keyboard. Est-ce qu'il faut réactiver l'int 1 puis la redégager après, une fois qu'on a plus besoin que du joypad ? Ca me semble être la seule méthode propre, mais peut-être qu'il y a un truc que je n'ai pas vu.

Folco (./23) :
PpHd, toujours ausis concis, ça m'éclate à chaque fois

Tu voulais quoi ?

Folco (./24) :
bon, j'ai implanté la lecture du joypad proprement, mai j'aimerais savoir autre chose. Je suppose que pour lire une entrée au clavier (un nom ou autre chose), je vais pas me faire suer avec une analyse de Keyboard. Est-ce qu'il faut réactiver l'int 1 puis la redégager après, une fois qu'on a plus besoin que du joypad ? Ca me semble être la seule méthode propre, mais peut-être qu'il y a un truc que je n'ai pas vu.

Y'a pas une fonction de réactivation de l'int 1 ?

Si, il y a ça, mais c'est marqué outdated...

- genlib::use_int1
‘Input’
• A6 = Address of the function
• D0-D7/A0-A5 : same as the called function.
• Stack : same as the called function.
‘Output’
‘Destroy’
Same as called function
Same as called function
[Function ASM]
‘Description’
Call a function and restore the auto-int 1 during this call. You can use in C this

OSSetSR(0x0000);
suivi de
OSSetSR(0x3000);
devrait suffire.

Oui remarque, plus simple que de passer par le trap 12 en effet. J'oublie toujours ce romcall, merci bien.

Ca serait possible d'avoir des fonctions de string où l'on puisse spécifier la couleur ? Parce que la lib est pas très bien servie pour les petites et moyennes fontes, du coup on se retrouve à passer par le TIOS, c'est un peu domamge ...

Que veux-tu exactement ?