Bonjours / bonsoirs, comme le titre l’indique je vais tenter de vous donner les clefs pour pouvoir programmer des add-in (langage C / ASM) tournée multijoueur (avec le câble 3-pin donc ).

Quelques petits points :
1.je ne prêtant pas à être le meilleur programmeur du monde ni même un bon programmeur.
2.Je ne détiens pas la science infuse il est donc possible que je dise des bêtises.
3.Ne voyer pas ce tuto comme LE cour pour apprendre tous les protocoles du monde.
4.Je ne vais pas vous apprendre à coder, plutôt comment penser à une structure pas trop mal foutue pour du multi.
5.Il est fort possible qu’ils y aient des fautes d’orthographe car je suis dyslècon...dys...dysle...xique.:D



Les débuts : les syscalls.
Si vous programmez en C sur Casio, vous utilisez sûrement MonochromeLib.h ou Usefull.h et, si vous êtes comme moi, vous avez déjà essayé de comprendre comment là/les librairies fonctionnent.
Vous auriez donc déjà remarqué que les deux librairies cité plus haut utilisent des trucs du style :


J’ai mis pas mal de temps avant de comprendre ce que c’était que ces chiffres poser au piff dans une liste. Bah c’est un syscall.
Pour faire un (gros) résumer (de ce topic) un syscall est un code en assembleur permettant d’effectuer une action précise comme par exemple connaître l’adresse de la VRAM (ce qui est super pratique pour les jeux et ce qui évite au développeur de réécrire le code pour tous les OS).

Celui-ci, cité plus haut, est le syscall (0x0135) qui permet de trouver la VRAM.
je ne vais pas m’étendre sur le sujet vu qu’il y a un topic qui en parle déjà.
Après des recherches sur ces fameux syscalls j’ai trouvé la documentation qu'Andreas Bertheussen et Simon Lothar on fait (merci encore à eux) ainsi que le syscall.src qu’il ont mis a disposition...et en lisant le syscall.h je suis tombé sur ça :


Avec un max de fonction derrière, j’ai donc viré tout ce qui ne m’intéressait pas pour garder seulement les fonctions sur le port série .
Puis j’ai lu la documentation pour lire:



J’ai donc créé un tableau test[]={0, 9, 0, 0, 0};
Puis un Serial_Open(test) ;
(En gros j’ai demander d’avoir d’avoir un BaudRate le plus rapide possible, pas de parité, 8bit, 1bit de stop).

Et j’ai commencé à bidouiller des programmes.
Mon premier fut un programme qui envoie les touches pressées a une autre calto puis après j’ai commencé à faire des jeux (comme un début de Street Fighter multijoueur et bien d'autres jeux qui ne verront jamais le jour).
PS : N’oublier pas le Serial_Close(0); a la fin de votre programme sinon vous risquez d’avoir des ennuies .



La structure :
Après plusieurs tests j’en suis arrivé à faire fonctionner des programmes pas trop foireux (qui ne plante pas tous les 2 secondes).
Il nous faut une calto qui fasse office de SERVEUR et une autre qui fasse office de CLIENT.

Le SERVEUR va se charger de tout calculer (déplacement, collision, etc…) puis d’envoyer les résultats au CLIENT.
Le CLIENT va juste envoyer les touches pressées par le joueur et recevoir les nouvelles valeurs du jeu (calculer par le SERVEUR).
Donc en gros :


Le truc super-important ici c’est les fonctions de [synchronisation].
Pour synchroniser les caltos ont leur demande d’attendre l’autre, par exemple le CLIENT attend que le SERVEUR lui envoie une valeur précise.
Car 95% du temps c’est ce qui fait cracher l’add-in, le CLIENT (qui n’a pas grand-chose a calculer) vas « plus vite » que le SERVEUR et au bout d’un moment chaque calto vas attendre une info ce qui vas bloquer le jeux.
Bon, voila a quoi ça ressemble en code:(ce sont une partie du code de Dungeons)






Les fonction utiles
Comme je l’ai dit plus haut la synchronisation est super-importante.
J’ai mis longtemps avant de trouver des fonctions fiables à long terme.
C’est pourquoi je vous les donne, mais je vous conseille de les comprendre et de réécrire à votre façon.
Avant ça je vais vous dire toutes les fonctions que j’utilise et qui font appel à des syscalls :


J’ai réécrit toutes les autres fonctions (ou simplement pas utiliser pour éviter d’être dépendant des syscalls).

Fonctions réécrites :

Cette fonction permet d’attendre un certain nombre d’informations (préciser via sizeWait).
Pendant qu’on attend on envoie à l’autre calto un code pour lui indiquer qu’on attend bien des infos.



Cette fonction attend le code envoyer par wait_data_event().
C’est une fonction qui permet de glander de manière précise .

Souvent j’écris trois autres fonctions :
send_DataPack(), set_DataPack() & receive_dataPack() ;
Je reviendrai sur ce qu’est un DataPack après.
Pourquoi je vais pas donner les codes de ces fonctions ?
Car elles ne fonctionneront probablement pas avec votre programme.
Je vais juste dire que :
send_DataPack() : permet d’envoyer le DataPack à l’autre calto.
set_DataPack() : permet de créer le DataPack.
receive_dataPack() : permet de recevoir le DataPack.



Les DataPacks
J’en ai parlé très rapidement pus haut.
Un DataPack représente une grande liste où l’on va mettre des valeurs importantes de manière logique.
Par exemple si j’ai un personnage qui bouge le DataPack sera :
(On peux dire que le bout de code est une partie de la fonction set_DataPack()).


C’est pourquoi plus haut j’ai dit « elle ne fonctionneront probablement pas avec votre programme » car le DataPack change en fonction des besoins et du programme.

Je n’ai personnellement pas réussi a faire fonctionner Serial_WriteBytes() qui permet d’envoyer une liste.
Je l’ai donc réécrite :

Cette fonction envoie le DataPack, et pour la réceptionner il suffi de changer Serial_WriteByte() par Serial_ReadByte() puis de bourrer comme un gros sagouin les valeur reçus dans une liste.


Mon avis sur la programmation de jeux Multijoueur
Je pense que si vous avez envie de programmer un jeu en Multijoueur, LISEZ DES SOURCES comme (Dungeons ou Mupong ).
Les jeux multijoueur sont encore trop rares et pourtant pas si compliquer à mettre en œuvre.

Les difficultés que j’ai rencontrées sont nombreuse : déjà il n’y avait que Mupong comme source et je ne programme absolument pas comme Theernest570 j’ai donc eu des problèmes pour commencer.
De plus ai pas réussi à faire fonctionner certaines fonctions comme Serial_ReadBytes(), Serial_WriteBytes(), j’ai donc piffé pendant longtemps.

J’ai mis pas mal de temps à piger comment synchroniser les caltos.
Et surtout le DEBUG est juste horrible : Il faut compiler, connecter les deux caltos à l’ordi, transférer le programme sur les 2 caltos...pour enfin voir que l’octet modifié ne fonctionne pas :D.
je ne vais pas vous mentir, quand le programme fonctionne...c’est génial !

Donc faites des jeux en multijoueur ! Ils sont encore trop rares !


FICHIER JOINS
Je vous donnes les liens directement:
L'ad-in de test + sources + librairie: https://www.planet-casio.com/Fr/programmes/voir_un_programme_casio.php?showid=3572
La doc de Andreas Bertheussen et Simon Lothar: http://downloads.sourceforge.net/fxsdk/fxreverse-docs-1.pdf
La doc de Lephenixnoir: https://www.planet-casio.com/files/forums/tuto-syscalls-14544.pdf

Dans le fichier joins vous trouverez Le plus important a lire: La librairie serial.h original, la documentation faites par Andreas Bertheussen et Simon Lothar + la doc de Lephenixnoir sur le désassemblage de syscalls.
Ainsi qu’une librairie écrite par moi-même qui s’appelle ‘mySerial.h’ ou dedans vous trouverez :


Pour résumer j’ai réécrit les fonction de serial.h (que j’utilisais) en C.
J’y ai ajouter une fonction synchroTest(), est permet de synchroniser deux caltos ensemble il faut juste lui indiquer si la calto est le serveur (‘who’!=0) ou le client (who==0)

Je fourni la lib avec un add-in de test bien sur