Notifications
Clear all

glOric v1.2 est disponible  

Page 1 / 2
  RSS

JiBe
 JiBe
(@jibe)
Membre Redacteur
Inscription: Il y a 12 mois
Posts: 38
6 juin 2020 14 h 36 min  

Bonjour à tous,

glOric v1.2 est disponible dans le répertoire release du dépôt glOric

Les changements par rapport à la v1.1 concernent principalement l'amélioration des performances.

J'ai fait relire mon code par Dbug et il m'a donné plein d'astuces pour faire en sorte que glOric aille plus vite:
- code modifié dynamiquement dans les routines de rasterisation
- usage de la page zéro pour accélérer les accès à certaines variables internes
- tampon de stockage intercalés pour éviter des incréments lors des parcours
- diminution drastiques des sauvegardes de contexte.
- dépliage de boucle pour économiser des cycles CPU
J'ai aussi mis en place une astucieuse méthode pour calculer les coefficient directeur des segments et ainsi pouvoir mettre en place une saturation pour accélérer le remplissage et le clipping des faces.

glOric v1.2 apporte aussi de nouvelles fonctionnalités:
- la fonction glDrawParticules est désormais inclue dans le code assembleur de glOric (il n'est plus besoin de la définir en C).
- deux fonctions essentielles de glOric sont désormais rendues accessibles en C : zplot et projectPoint. En utilisant ces fonctions, il devient très facile d'incorporer dynamiquement votre propre contenu aux scène 3D (tels que des tiles, un fond, un ciel, un horizon ou autre ..) tout en bénéficiant de la puissance de glOric pour ce qui est de la projection ou de la gestion de la visibité.

Consultez le code source du 3D Walkthrough Template si vous souhaitez en savoir plus sur comment utiliser glOric dans vos propres créations. Et n'hésitez pas à poser vos questions et faire vos remarques ici ou sur le fil forumactif

 


Quote
jede
 jede
(@jede)
Membre
Inscription: Il y a 1 an
Posts: 146
6 juin 2020 16 h 25 min  

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.


RépondreQuote
JiBe
 JiBe
(@jibe)
Membre Redacteur
Inscription: Il y a 12 mois
Posts: 38
7 juin 2020 11 h 38 min  

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 ?


RépondreQuote
JiBe
 JiBe
(@jibe)
Membre Redacteur
Inscription: Il y a 12 mois
Posts: 38
8 juin 2020 7 h 57 min  

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 ?


RépondreQuote
jede
 jede
(@jede)
Membre
Inscription: Il y a 1 an
Posts: 146
8 juin 2020 10 h 45 min  

@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).


RépondreQuote
jede
 jede
(@jede)
Membre
Inscription: Il y a 1 an
Posts: 146
8 juin 2020 10 h 51 min  

@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).


RépondreQuote
assinie
(@assinie)
Membre
Inscription: Il y a 1 an
Posts: 21
8 juin 2020 13 h 53 min  

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.


RépondreQuote
assinie
(@assinie)
Membre
Inscription: Il y a 1 an
Posts: 21
8 juin 2020 14 h 19 min  

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.


RépondreQuote
JiBe
 JiBe
(@jibe)
Membre Redacteur
Inscription: Il y a 12 mois
Posts: 38
8 juin 2020 14 h 23 min  

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.

 

_fbuffer:
    .res    1040,$00
_zbuffer:
    .res    1040,$00

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"


RépondreQuote
assinie
(@assinie)
Membre
Inscription: Il y a 1 an
Posts: 21
8 juin 2020 15 h 44 min  

@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

 


RépondreQuote
JiBe
 JiBe
(@jibe)
Membre Redacteur
Inscription: Il y a 12 mois
Posts: 38
8 juin 2020 16 h 54 min  
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 ..

 


RépondreQuote
jede
 jede
(@jede)
Membre
Inscription: Il y a 1 an
Posts: 146
8 juin 2020 17 h 05 min  

@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.

 

 

 

 


RépondreQuote
assinie
(@assinie)
Membre
Inscription: Il y a 1 an
Posts: 21
8 juin 2020 18 h 02 min  

@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?


RépondreQuote
JiBe
 JiBe
(@jibe)
Membre Redacteur
Inscription: Il y a 12 mois
Posts: 38
8 juin 2020 19 h 52 min  
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:

#undef USE_C_ZPLOT
#define  USE_ASM_ZPLOT

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

#define USE_C_ZPLOT
#undef  USE_ASM_ZPLOT
 
Bien sûr j'ai préalablement entouré la définition de la fonction zplot des #ifdef correspondant.
 
#ifdef USE_C_ZPLOT

void zplot( ... ){
...
}

#endif
 
et dans le code assembleur:
 
#ifdef USE_ASM_ZPLOT

_zplot:
.(
...
.)
    rts

#endif ;; USE_ASM_ZPLOT
 
 

RépondreQuote
JiBe
 JiBe
(@jibe)
Membre Redacteur
Inscription: Il y a 12 mois
Posts: 38
8 juin 2020 20 h 30 min  

 

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:

.proc _une_fonction
    lda #SCREEN_WIDTH
    rts
.endproc
Au début du fichier gl65_s.s,  j'ai mis les lignes suivantes
 
.import SCREEN_WIDTH
.import SCREEN_HEIGHT
Car sinon il me disait que le symbol était inconnu.
 
Aurais-tu une idée de ce que j'ai mal fait ?

RépondreQuote
Page 1 / 2
Share: