glOric v1.2 est disponible

Le lien dans le post vers github est cassé.

Concernant la dispo, l'idéal serait d'avoir un .lib et juste le header. C'est possible avec cc65 avec ar65. Mais c'est plus compliqué de faire des libs avec xa.

Ainsi, il suffirait de fournir le .lib et l'include et hop, on pourrait linker.

Coucou @jede,

Merci de ton intérêt pour glOric.

Saches en premier lieu que je suis dépité de ne pas encore pouvoir arborer fièrement une version Orix de glOric. Non seulement parce que j'ai très envie de pouvoir faire de la 3D sur Orix .. mais aussi parce que j'ai déjà consacré pas mal d'effort pour faire en sorte que cela soit possible et je n'en suis pas loin.

J'ai plusieurs fois eu des versions qui fonctionnaient sur Orix .. mais jamais au même moment que celles qui fonctionnaient avec OSDK .. 🙁 ..

J'ai abandonné l'idée d'avoir une version commune des sources entre la version OSDK (xa65) et la version Orix (ca65).. et j'ai décidé de revenir à ma stratégie initiale : faire un portage de glOric vers ca65 en bon et due forme. Je compte aussi sur ce portage pour me permettre d'attaquer le marché d'autres cibles 6502 notamment à travers une intégration à 8bits-unity.

Pour cela, j'ai démarré le projet gl65 .. qui se veut être une version multi-platforme de glOric:

J'ai posé les bases ici:

https://github.com/jbperin/gl65/tree/develop

Pour l'instant cela ne fait que compiler, avec cc65/ca65, une version majoritairement C de glOric à destination d'un atmos. Normalement, avec le makefile que j'utilise, il suffira de rajouter la cible telestrat pour que ça compile à destination d'Orix.

Ma stratégie c'est de partir d'une version C qui marche (ça c'est déjà fait) .. et de faire, petit à petit, des versions ca65 de chaque fonction C ... en utilisant le code dont je dispose déjà en xa65.

Je pourrais ainsi m'assurer de la non regression à chaque étape en vérifiant que ma petit démo fonctionne.

C'est une méthode qui va prendre du temps .. mais c'est une méthode qui va me permettre d'obtenir une version ca65 avec une réelle maîtrise du portage .. et un très bon degré de confiance dans l'assurance d'arriver à quelque chose d'opérationnel.

Concernant la disponibilité sous forme de .lib .. c'est ce que je pensais faire au début.. mais j'ai un peu revu ma position sur le sujet.

Il y a des paramètres du moteur de rendu qu'il est beaucoup plus efficace de régler par des directives de compilation que par des paramètrage dynamique. Et ce type de paramètrage ne peut pas se faire facilement sous forme de .lib (à part à faire une version par valeur possible du paramètre).

Par exemple, la taille du viewport est actuellement définie par des #define. Un développeur qui veut changer la taille du viewport (pour ajoutter une interface autour) peut normalement changer ces constantes dans le code assembleur .. et tout le moteur de rendu sera adapté lors de la compilation de son projet.

Alors que si je peux faire un .lib, il faut que je fasse une fonction qui permette de changer dynamiquement la taille du viewport à l'initialisation du moteur de rendu.

Déjà ça me fait reprendre tout le code ou ces constantes sont utilisées pour en faire des variables.

Ensuite ça veut dire faire des calculs supplémentaire pour tenir compte dynamiquement de ces paramètres. Et là, tout l'édifice de performance que j'ai édifié s'écroule. Car ça rajoute des méchantes division et multiplication que je me suis évertué à éviter à tous les niveaux de la conception et de l'implémentation (aujourd'hui, il n'y aucune multiplication dans glOric et une seul division .. ultra simplifiée car c'est une division par la constante 3)

Tout cela pour dire que je pense finalement fournir un .s et .h aux utilisateurs de ca65 .. plutôt qu'un .lib et un .h

Je vais laisser le soin à l'utilisateur de se faire une lib une fois qu'il aura tuné les paramètres du moteur comme il le voudra.

Qu'en dis tu ?

Juste un petit post pour signaler que j'ai essayé et que je confirme que pour compiler gl65 pour Orix il suffit de taper les commandes suivantes:

git clone -b develop --depth=1  https://github.com/jbperin/gl65.git 

cd gl65
make TARGETS=telestrat

cp gl65.telestrat /path/to/Orix/usbdrive/bin/demoGl65

Ensuite il faut lancer Orix (Oricutron avec les ROMs qui vont bien) et taper la commande:

demoGl65

Ça rame .. c'est normal .. c'est la version C de glOric qui est actuellement utilisée sur gl65.

Maintenant, le but du jeu pour moi, c'est de remplacer les fonctions C contenues dans le fichier src\gl65_c.c par leur équivalent assembleur dans src\gl65_s.s. Je ne pars pas de rien pour cela puisque j'ai déjà les versions assembleur 6502 en xa65 dans glOric_v12.s.

Après cela, on devrait avoir à peu près le même niveau de performance qu'avec glOric (à peu près car je ne pense pas pouvoir disposer d'autant de place en page zéro que sur OSDK)

J'ai une question concernant la possibilité de faire coexister des versions C et assembleur des même fonctions en pouvant switcher de l'une à l'autre.

Sur la version OSDK de glOric, je peux switcher entre les versions C et assembleur en définissant de macros de type:

#define USE_C_FONCTIONMACHINTRUC

ou

#define USE_ASM_FONCTIONMACHINTRUC

et le préprocesseur s'occupe du reste ..

Y'a-t-il moyen de faire pareil en cc65/ca65 ?

@jibe J'ai toujours suivi glOric car cela m'a toujours beaucoup intéressé. Je n'ai pas le temps de regarder car je suis déjà sur mes projets, mais je ne désespère pas de trouver du temps pour tester.

Concernant la choix de faire une lib ou non. Je vois un peu le problème de linke. Mais il me semble qu'on peut linker de manière conditionnelle aussi avec le .lib (il faudrait vérifier).

@jibe Normalement, tu peux le faire en ligne de commande. Plutôt que de faire des defines, tu peux le faire en ligne de commande.

Pour en revenir au .lib, ld65 permet la définition de define en ligne de commande. Donc, il faudrait tester, mais à mon avis il est possible de relinker correctement car le .lib est une archive des objets ca65 qui permettent d'être relinkés correctement en fonction de certains params.

Je n'ai pas vérifié. Et je ne suis pas expert sur cette partie là. J'ai fait des libs cc65, mais je n'ai jamais eu à tester le passage de define au link. Si Assinie passe par là, il pourra sans doute confirmer ou pas (s'il a déjà utilisé cette partie).

Je n'ai pas testé la définition de symboles avec ld65.

De ce que je comprends, cela permet de définir la valeur d'un symbole déclaré dans le fichier de configuration pour la cible ou comme symbole importé.

Dans ton code tu utilises des defines pour déclarer la taille d'un tableau, il faudrait faire un test en déclarant ces tableaux dans le fichier de configuration avec une taille qui serait précisée par un define en ligne de commande.

Je ne sais pas si c'est possible mais je peux tester si tu veux.

Une autre solution pourrait être de déclarer ces tableaux en externe pour la librairie et de les définir dans le programme principal. Je n'ai pas vérifié si tu te sers de la taille de ces tableaux pour autre chose que pour en définir la taille avec une pseudo instruction .res.

Pour les directives du type

#define USE_ASM_FONCTIONMACHINTRUC

elles deviennent inutiles si tu utilises une librairie, ld65 ajoutera automatiquement les fonctions utilisées par le programme et uniquement celles-ci, c'est l'avantage des librairies.

Autre chose, tu peux simuler en partie une librairie avec xa.

Au lieu de mettre dans le programme principal des instructions:

#define USE_ASM_FUNCTIONxxx

et d'encadrer tes fonctions par:

#ifdef USE_ASM_FUNCTIONxxx
...
#endif

il suffit d'encadrer tes fonctions par:

#iflused functionxxx
....
#endif

ensuite tu ajoutes un include des sources glOric.

Au moment de l'assemblage, xa ajoutera automatiquement les fonctions utillisées dans ton programme

C'est ce que j'utilise avec ma librairie pour le ch376: ch376

Un exemple d'utilisation: cd

L'include de la librairie est à la fin du programme d'exemple.

coucou @assinie

Merci pour ta réponse

En regardant la doc de ld65, je constate qu'effectivement il y a une option -D sym=value, --define sym=value

Je ne m'attendais pas à trouver ce genre d'option au moment du link car cela relève généralement du préprocesseur. Il y a des quelques explications ici:

https://cc65.github.io/doc/ld65.html#SYMBOLS

Sur gl65, j'ai mis un fichier oric.cfg que j'ai récupéré du jeu d'échec qu'a porté ISS.

Et dans le fichier plateforme platOric.s, il est fait recours à des constantes définies dans le fichier de config.

Il me semble que c'est justement le principe qu'évoque Jede et je dois reconnaître que je ne connais pas bien ces aspects là .. j'ai repompé ce qu'a filé ISS.

Mais du coup je comprends un peu mieux maintenant comment fonctionne ce passage de paramètre au link.

Mais il reste à savoir s'il est possible d'utiliser ce genre d'astuce pour dimensionner un tableau en mémoire.

NB: je réalise que j'ai codé en dur la taille comme un gros porc ..

Mais l'idée c'est de remplacer le 1040 par SCREEN_HEIGTH*SCREEN_WIDTH en ayant ces deux valeurs définies soit par un -D au moment du link .. soit par édition du fichier .cfg

Je dois pouvoir faire l'essai moi même, je te tiendrai au courant.

Concernant la solution pour le switch entre les versions C et ASM, je ne suis pas certain de  bien comprendre.

Actuellement, ce que j'ai sur glOric que je compile avec OSDK, c'est que j'ai les deux versions C et ASM dans le code source. Et j'utilise des macro #define pour embarquer ou pas le code de la version C ou ASM.

Je cherche un moyen de pouvoir switcher facilement d'une version à l'autre d'une fonction (du C vers l'ASM ou de l'ASM vers le C) sans avoir à mettre en commentaire / décommenté la version que je n'utilise pas.

C'est pour pouvoir disposer des deux versions dans le code source, sans pour autant qu'il y ait d'erreur disant "symbol redifined"

@jibe

Est-ce que tes variables comme _zbuffer, _fbuffer, doivent être obligatoirement être déclarées dans glOric ou est-ce qu'elles peuvent être déclarées dans le programme qui utilise glOric?

Tu peux tout à fait utiliser un -D en ligne de commande pour définir les valeurs de SCREEN_HEIGTH et SCREEN_WIDTH.

Je ne comprends pas ce que tu entends par

Posté par: @jibe

Je cherche un moyen de pouvoir switcher facilement d'une version à l'autre d'une fonction (du C vers l'ASM ou de l'ASM vers le C) sans avoir à mettre en commentaire / décommenté la version que je n'utilise pas.

Est-ce que tu as des fonctions qui ont le même nom mais qui sont définies en C et en ASM dans le même fichier?

L'astuce avec #iflused permet de n'inclure que les fonctions qui sont appelées par le programme.

Par exemple, si dans le programme il y a:

jsr fonctionxxx
jsr fonctionyyy

et dans glOric:

#iflused fonctionxxx
fonctionxxx:
        lda #$10
        ...
        rts
#endif

#iflused fonctionyyy
fonctionyyy:
       lda #$11
       ...
       rts
#endif

#iflused fonctionzzz
fonctionzzz:
       lda #$11
       ...
       rts
#endif

Lors de l'assemblage, xa ajoutera le code de fonctionxxx et fonctionyyy mais pas celui de fonctionzzz

Posté par: @assinie

@jibe

Est-ce que tes variables comme _zbuffer, _fbuffer, doivent être obligatoirement être déclarées dans glOric ou est-ce qu'elles peuvent être déclarées dans le programme qui utilise glOric?

Tu peux tout à fait utiliser un -D en ligne de commande pour définir les valeurs de SCREEN_HEIGTH et SCREEN_WIDTH.

Je ne comprends pas ce que tu entends par

Posté par: @jibe

Je cherche un moyen de pouvoir switcher facilement d'une version à l'autre d'une fonction (du C vers l'ASM ou de l'ASM vers le C) sans avoir à mettre en commentaire / décommenté la version que je n'utilise pas.

Est-ce que tu as des fonctions qui ont le même nom mais qui sont définies en C et en ASM dans le même fichier?

Pas dans le même fichier mais oui j'ai des fonctions qui ont le même nom en C et en ASM .. Par exemple, je vais avoir une version C et une version ASM de la fonction glDrawLines()

Si je veux revoir l'algorithme de glDrawLines pour tester une autre approche, je voudrais pouvoir switcher vers la version C et prototyper l'idée en C .. et une fois que j'ai une version C de l'algo qui me donne satisfaction, je reporte sur la version assembleur et je switch sur la version  assembleur à la compilation.

C'est comme ça que j'ai fait sur OSDK .. et ça m'a vraiment aidé .. du coup je me demandais s'il était possible d'obtenir ce genre de confort dans l'environnement cc65/ca65 ..

Au pire je mettrais en commentaire les fonctions que je ne veux pas utiliser .. mais ton idée de #iflused est très intéressante .. je ne connaissais pas .. ça fonctionne avec cc65/ca65 ou avec cpp/xa65 ?

Concernant les buffers évoqués zbuffer et fbuffer, ce sont des buffers interne à gOric .. je ne sais pas si ce serait intéressant de reporter sur le programme utilisateur la responsabilité de les définir ..

@jibe Je ne sais pas si tu as essayé en jouant sur le link tel que :

asm_maroutine.s (contenant l'assembleur avec un  .proc _maroutine/.endproc)

ex :

.export _maroutine

.proc _maroutine

; bla

  rts

.endproc

et un

maroutine.c (contenant l'équivalent de ta fonction maroutine  mais en C)

Dans ton Makefile, tu vas assembler asm_maroutine.s où tu auras asm_maroutine.o et dans une autre partie tu vas compiler pour avoir un objet maroutine.o

Au link, tu as besoin de spécifier soit asm_maroutine.o soit maroutine.o mais la référence sera la même car dans les 2 fichiers tu auras le label _maroutine exporté.

Cela résoud le pb des fonctions, mais pas des buffers.

@jibe #iflused c'est pour xa, le but était de pouvoir simuler à l'assemblage l'équivalent de l'utilisation d'un fichier librairie mais au niveau du source du programme.

Du coup, à quel moment tu fais le choix de la version en C ou de celle en ASM, c'est le makefile ou dans le source du programme de test en incluant un fichier plutôt qu'un autre?

Posté par: @assinie

@jibe #iflused c'est pour xa, le but était de pouvoir simuler à l'assemblage l'équivalent de l'utilisation d'un fichier librairie mais au niveau du source du programme.

Du coup, à quel moment tu fais le choix de la version en C ou de celle en ASM, c'est le makefile ou dans le source du programme de test en incluant un fichier plutôt qu'un autre?

J'ai un fichier config.h dans lequel je définie, entre autre, les fonctions C ou ASM que je veux utiliser.

C'est ici.

par exemple si je veux utiliser la version ASM de la fonction zplot. Alors je définie:

et si je veux utiliser la version C de la fonction zplot. je définie:

J'ai essayé de définir les symbol grâce à un -D et cela fonctionne pour le C. Mais il me met une erreur pour l'assembleur.

$ make TARGETS=telestrat
cl65 -t telestrat -c --create-dep obj/telestrat/gl65_c.d -D SCREEN_WIDTH=40 -D SCREEN_HEIGHT=26 -o obj/telestrat/gl65_c.o src/gl65_c.c
cl65 -t telestrat -c --create-dep obj/telestrat/main.d -D SCREEN_WIDTH=40 -D SCREEN_HEIGHT=26 -o obj/telestrat/main.o src/main.c
src/main.c(271): Warning: Constant is long
cl65 -t telestrat -c --create-dep obj/telestrat/gl65_s.d -D SCREEN_WIDTH=40 -D SCREEN_HEIGHT=26 -o obj/telestrat/gl65_s.o src/gl65_s.s
src/gl65_s.s(667): Error: Range error
make: *** [makefile:299 : obj/telestrat/gl65_s.o] Erreur 1

à la ligne 667 du fichier gl65_s.s , j'essaie d'utiliser une des constantes: