Hello, Avatar!

Second Life et Programmation Créative

Aller au contenu | Aller au menu | Aller à la recherche

SLTris fonctionne sur OpenSim

C'est une bonne soirée : mon jeu fétiche, SLTris, écrit il y'a plus d'un an fonctionne (enfin) sur un OpenSim.

OSTris.png

Il a été rebaptisé pour l'occasion "OSTris" :)

Dans la foulée, je travaille sur une version édulcorée de Bubble Breaker (27 prims...) qui exploitera une nouvelle fonction de LSL, llDetectedTouchFace, qui permet d'obtenir le numéro de la face sur un prim qui vient d'être touché... Malheureusement, cette dernière n'est pas encore implémentée dans les moteurs de scripts d'OpenSim, ce qui ne saurait tarder.

Commentaires en blocs

Un truc souvent pénible avec LSL, c'est l'impossibilité de définir des blocs de commentaires, comme on le ferait dans à peu près n'importe quel langage traditionnel.

Par exemple, pour commenter un bloc de code, il faut se fader à taper "//" devant chaque ligne. LSLEditor le fait automatiquement, mais pas l'éditeur in-world, et c'est très pénible. On aimerait pouvoir écrire "/*" et "*/" à la fin comme en C#, par exemple, mais bon, on peut pas...

//    integer i = 0;
//    do
//    {
//        integer Idx = llListFindList(NewXYList, llList2List(OldXYList, i, i+1));
//        if (Idx % 2 > 0)
//        {
//            i += 2;
//        }
//        else
//        {
//            OldXYList = llDeleteSubList(OldXYList, i, i+1);
//            NewXYList = llDeleteSubList(NewXYList, Idx, Idx+1);
//            Count -= 2;
//        }
//    }
//    while(i < Count);
//    }

L'astuce que j'utilise est la suivante : j'ajoute "if (false) {" au début du bloc que je ne souhaite pas exécuter, puis "}" à la fin.

if(false) { //*
    integer i = 0;
    do
    {
        integer Idx = llListFindList(NewXYList, llList2List(OldXYList, i, i+1));
        if (Idx % 2 > 0)
        {
            i += 2;
        }
        else
        {
            OldXYList = llDeleteSubList(OldXYList, i, i+1);
            NewXYList = llDeleteSubList(NewXYList, Idx, Idx+1);
            Count -= 2;
        }
    }
    while(i < Count);
} // */

C'est plutôt dégueulasse, mais ça fait son boulot facilement et rapidement :-)

Mono, concrètement

mono_logo.png

Depuis quelque temps, la main grid autorise les scripts LSL à être compilés en utilisant la technologie Mono.

Super ! On nous promet une vitesse d'exécution multipliée par 200, et c'est tout à fait pertinent. Mais avant de crier au miracle, il faut bien comprendre en quoi consiste Mono, pour se faire une idée plus précise de la sauce à laquelle nos scripts LSL vont être mangés.

C'est quoi Mono ?

Mono n'est pas un nom de code inventé par Linden Labs.
Mono, c'est le confrère libre et open source de la plateforme de développement .NET conçue par... Microsoft, dans le but de concurrencer Java sur le terrain des applications d'entreprises. C'est un peu ce qu'OpenSim est à ce qui tourne sur les serveurs de Second Life. .NET est une technologie fiable et éprouvée qui fait tourner des centaines de milliers d'applications dans le monde, et Mono le devient de plus en plus.

Concrètement, Mono, ça marche comment sur la grille ?

Sans Mono

Les scripts sont éxécutés par une machine virtuelle. Une sorte de gros programme qui analyse les scripts, et déroulent leur éxécution. C'est très lourd, et relativement lent, surtout lorsqu'il y'a beaucoup de scripts. En cas de grosse montée en charge, ajouter plusieurs machines virtuelles et les faire tourner en même temps ne fait que reculer le problème. Les premières générations de programmes en Java tournaient de cette manière.

Imaginons, dans la vie réelle, une sorte de gros androïde chargé de traiter des dossiers dans un bureau. Imaginons que l'androide est une machine virtuelle, que les dossiers à traiter sont des scripts, et le bureau est le serveur. Plus il y'a de dossiers, plus l'androïde aura du mal a les traiter rapidement. Si on rajoute des antroïdes pour répartir le travail, ils risquent de se trouver à l'étroit dans le bureau...

Avec Mono

Les scripts utilisent la technologie Mono, et sont convertis très rapidement dans un langage directement compréhensible par la machine. Plutôt que d'avoir une machine virtuelle monstrueuse, chaque script devient un "vrai" petit programme qui bénéficie directement des possibilités de la machine, sans être en quelque sorte bridés par la machine virtuelle.

Imaginons, dans la vie réelle, le même bureau et les mêmes dossiers. Le gros androïde a été remplacé par un machiniste chargé de piloter une machine de marque Mono. Les dossiers qui arrivent pour être traités, passent dans cette machine, et se transforment alors en tout petits androïdes très légers, taillés et calibrés juste assez pour faire le travail demandé.

A noter que sur OpenSim (écrit en Mono...), il se passe à peu la même chose ! Sauf que les androïdes sont pour le moment un peu plus gros, un poil plus lourds, et surtout, bien moins disciplinés... ;-)

Alors ça va lagger beaucoup moins ?

Pas sûr... Comme expliqué sur SecondWorld, ce n'est pas parce que la vitesse d'execution des scripts est grandement accrue que les informations vont circuler plus vite entre nos viewers et les serveurs de Second Life. Il convient que rappeler que chaque changements d'états in world se traduit par une avalanche de données transmises à chacun des viewers actuellement connectés sur la région. Un changement d'état, c'est un avatar qui bouge, qui parle, un prim qui change de couleur, se déplace, un son, une nouvelle texture... Et à ça, Mono ne pourra rien changer.

En revanche, les avantages de Mono sont immédiatement perceptibles pour :

  • De gros calculs IntraWorld
  • Les listeners, détecteurs, les outils de communications (Requêtes HTTP, XMLRPC...)
  • Une grande quantité de scripts tournant en même temps

Voilà. Bien sûr, dans la réalité, c'est toujours un peu plus compliqué que ça, mais j'espère vous avoir aidé à démystifier Mono sur SL, et à relativiser un peu les promesses faites par les Linden.

Si vous connaissez des ressources par rapport à mono sur SL (optimisations des scripts, limites techniques... etc...), les commentaires sont à vous !

InterCom 2.1 : Lave plus blanc !

InterCom.jpg

Il y'a peu j'avais publié le code source d'un InterCom pour communiquer entre deux grilles.

Cette version améliorée est plus robuste, plus commentée, et surtout, elle affiche au dessus du prim toutes les régions ou se trouvent les InterComs connectés au même canal.

Retrouvez ici l'intégralité des codes sources

L'InterCom entre Grids : le code source

[Update 16/07/2008] : Nouvelle version 2.1 ici

InterCom.jpg

J'avais bricolé vite fait un InterCom pour chatter entre la Maingrid de Linden Labs et la Francogrid. J'ai repris ce proto pour l'élargir à toute grilles OpenSim.

Comme j'étais parti sur un truc un peu compliqué et assez lourd pour être publié ici, j'ai pensé très fort à Keru, qui est radio-amateur, si je ne m'abuse, et je suis revenu sur quelque chose de plus simple : un genre de poste de radio qui permet de communiquer avec toutes les personnes qui possèdent un équipement identique, pourvu qu'ils soient connectés sur le même canal.

Comment ça marche ?

L'utilisation de l'InterCom est on ne peut plus simple :

  • touchez le pour afficher le menu qui permet de l'allumer ou de l'éteindre,
  • tapez une commande dans le chat pour changer son numéro de canal.
    Par défaut, l'InterCom utilise le canal 0. Tapez /100 250 dans le chat, et le numéro de canal sera le 250.

Pour que deux InterComs puissent communiquer entre eux, qu'ils soient sur la Maingrid des Lindens ou sur la Francogrid, ou l'OSGrid, ou la NewWorldGrid, ou la Machingrid... il faut qu'ils utilisent le même numéro de canal.

Le Script !! Le Script !!

Retrouvez l'intégralité des codes sources ici.

Voilà. Amusez-vous bien avec l'InterCom ^^ !

- page 1 de 3