Bonjour, je commence à réfléchir à la conception d'une librairie graphique en lisaac ( http://fr.wikipedia.org/wiki/Lisaac(...) ). L'ambition de cette librairie est de couvrir tous les services apportés par SDL+ OpenGL+OpenAL ou encore DirectX.
Ma volonté première est d'aller vers un maximum de simplicité, de confort d'utilisation, mais surtout de doter ce langage d'une librairie graphique/jeu. Je ne suis pas attiré par recopier bêtement une librairie. Dans l'esprit OpenSource, je préfèrerai demander aux développeurs ce qu'ils aimeraient utiliser.
Lisaac étant un langage objet de haut niveau, il n'y a pas de pointeurs. Il est intégralement objet dans son paradigme (il ressemble beaucoup à Eiffel).
On dispose d'ors et déjà des méthode de base en graphisme et gestion d'évènements.
Vous êtes surement un utilisateur de librairies graphiques comme SDL, Glut, DirectX même (qui sait ?!), etc...
Si vous êtes dans ce cas quels sont les diverses remarques positives ou négatives que vous feriez sur tel ou tel librairie ?
Quel serait à vos yeux la librairie taillée pour le jeu, de vos rêves ?
Journal Spécifier une nouvelle librairie graphique
20
juin
2005
# juste comme ca ...
Posté par jaroug (site web personnel) . Évalué à 6.
s/librairies/bibliothèques/g
PS: oui j'aurais pu le faire en une expression :p
# Ma petite experience
Posté par Adrien BUSTANY (site web personnel) . Évalué à 3.
Le problème à mon avis, c'est que à trop faire de trucs pré définis, on allourdit la bibliothèque, et on réduit la liberté de codage. Je vois pas trop comment laisser l'accès aux manipulations de bits par exemple avec un tel niveau d'abstraction ou l'allocation mémoire n'existe même plus pour le programmeur.
[^] # Re: Ma petite experience
Posté par Ontologia (site web personnel) . Évalué à 3.
Attention, lisaac n'est pas un langage objet à classe : tu n'instancie pas un objet, tu le clone. Donc pas besoin de définir un héritage, etc...
Tu le clone, tu lui met ses octets de bitmap dedans et terminé.
Quand au pointeur, tu fait ma_liste_de_sprite : LINKED_LIST[SPRITE];
et ensuite tu y accède avec des opérations du style
(ma_liste_de_sprite.item i.hitTest).if {"Touché\n".print;};
Pour la problématique du niveau d'abstraction,
1) Chacun pourra se contenter de se servir des briques de bases et de manipuler des bits si ça lui chante
2) Lisaac est un langage haut niveau conçu pour le système, il est très à l'aise avec ça
3) Le compilateur est le compilo objet le plus optimisé à l'heure actuel : il produit du code dont les performances atteignent celles du C.
4) Le haut niveau d'abstraction n'est là que pour simplifier la vie à ceux qui ne veulent pas rentrer dans les détails.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Encore
Posté par ndv . Évalué à 5.
Et partir sur un langage peu utilisé voir inconnu ne risque pas de t'amener beaucoup de développeurs tiers... Sans compter les bindings supplémentaires à faire pour que ta lib soit utilisable par d'autres langages plus populaires...
[^] # Re: Encore
Posté par Ontologia (site web personnel) . Évalué à 2.
Je parle de spécification. Pour le code, on verra. De toutes façons, on code 15 fois plus vite en lisaac qu'en C++
Ensuite, je me concentrerais sur les fonctionnalités de base au début, reprenant des remarques intéressantes du style de celle d' Adrien Bustany là haut. Pour concurrencer SDL, on verra plus tard.
> Et partir sur un langage peu utilisé voir inconnu ne risque pas de t'amener beaucoup de développeurs tiers...
Ce langage est inconnu pour l'instant, mais ça va changer.
> Sans compter les bindings supplémentaires à faire pour que ta lib soit utilisable par d'autres langages plus populaires...
Ils se débrouilleront avec les sources C que le compilateur cracheras.
Cela dit, on pourra trouver d'autres solutions. Je ne cherche qu'à spécifier une librairie pour ce langage.
De toutes façon, importer une librairie construite dans un logique d'objet à prototype dans un langage à classe risque de poser quelques problème à la marge.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Encore
Posté par RodZilla . Évalué à 10.
C'est génial ça. Tu vas pouvoir aller coder en Pologne pour venger nos plombiers.
[^] # Re: Encore
Posté par Obsidian . Évalué à 10.
# Bindings
Posté par pshunter . Évalué à 2.
P.S. Au fait, comment dire "binding" ? Liaison ?
[^] # Re: Bindings
Posté par Ontologia (site web personnel) . Évalué à 2.
L'objectif est de concevoir une nouvelle bibliothèque, conceptuellement.
Si tel était mon intention, je n'aurai pas posté ce journal :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Bindings
Posté par bobefrei . Évalué à 2.
Je pense qu'il faut placer ta librairie à un plus haut niveau, cad proposer des fonctionnalités telles qu'un scenegraph, un moteur physique, la gestion des ressources (textures, sons, objets 3D, scripts...), du jeu en réseau,etc.
A bas niveau, il ne reste qu'un domaine qui est mal couvert (par le libre en tout cas): les calculs "vectoriels" utilisant MMX, SSE et co.
[^] # Re: Bindings
Posté par Ontologia (site web personnel) . Évalué à 1.
Cette librairie a vocation à être multiplateforme : Lisaac est le langage qui permet d'écrire l'OS Isaac. Isaac tourne d'ors et déjà sur cinq architectures différentes.
Comme c'est un OS, il faudra réécrire les drivers.
Sur PC effectivement, on se reposera sur des bindings, mais c'est un cas particulier.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# En tout cas merci
Posté par Anonyme . Évalué à 5.
[^] # Re: En tout cas merci
Posté par Ontologia (site web personnel) . Évalué à 1.
Il ya plein de choses à faires, du code, faire avancer l'OS, le compilo, les nouveaux concepts, tout ça... ;o)
Donc n'hésite pas :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Pourquoi Lisaac ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 4.
Juste une question : pourquoi Lisaac comme langage objet à prototypes. Il existe des langages à prototypes bcp plus avancés que Lisaac actuellement : io et slate pour ne citer que ces deux là par exemple.
[^] # Re: Pourquoi Lisaac ?
Posté par Ontologia (site web personnel) . Évalué à 1.
A première vu je remarque :
1. Ils sont plus avancés que Lisaac sur certains points, mais il est prévu de les implémenter dans le langage. Tu connais le système de recherche français, et tu peux aisément imaginer que l'auteur du compilateur est englué dans la paperasse depuis pas mal de temps alors que ses collègues travaillent et construisent.
Ce n'est qu'une question de temps :)
Et ca va venir vite ( la 0.2 est pour bientot)...
2. Sauf erreur de ma part ces deux langages sont chacuns basés sur une VM, le fervent utilisateur de Squeak que tu es n'est pas dérangé par cet aspect. Nous on ne veut pas de VM, ou tout au moins la possibilité de ne pas avoir à s'en servir.
3. Et c'est lié avec 2, lisaac est un langage objet à prototype compilé ce qui n'est pas le cas de io et slate sauf erreur de ma part. Faire un langage hyper puissant est bel et bon mais si ça rame autant que Java c'est beaucoup moins intéressant déjà...
4. A part le design "acteur" dans io et les librairies beaucoup plus étoffées (c'est facile, c'est une VM...) je vois pas en quoi il y a plus de choses en Lisaac (on peut faire beaucoup de camlrie en lisaac). Es-tu sûr d'avoir bien évalué tout ce qu'est capable de faire Lisaac ? Son auteur m'a confié plusieurs fois que le compilateur était loin d'être totalement exploité dans les possibilités offertes.
Note : j'arrive pas à compiler slate :(
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pourquoi Lisaac ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Sinon, les langages objet à VM ne sont pas tous peu performant. En fait, il n'y en a qu'un dont les perfs sont lamentables : Java.
Ceci est dû en partie à une différence de conception mais aussi d'approche. Dans Java, la VM est juste une machine à exécuter une application. Dans Smalltalk ou slate par exemple, la VM est plus un conteneur à objets ; en fait c'est bien une véritable machine dédiée à la gestion du cycle de vie des objets (c'est donc un véritable environnement d'exécution objet).
A part ceci, effectivement je n'ai pas très bien évalué les possibilités de Lisaac. Je me suis juste amusé un peu comme ça. Il y a un petit truc qui me dérange dedans, c'est son orientation "structure des objets". Avec io ou slate, le dév est orienté plus sur les objets eux-mêmes en tant que tel que sur leur structuration sous forme de prototype ; c'est une approche plus "dynamique" (ce que sont les objets, des entités avant tout dynamique).
[^] # Re: Pourquoi Lisaac ?
Posté par Ontologia (site web personnel) . Évalué à 1.
L'objectif (entre autre)de lisaac est de rendre le C inutile (pour les non réfractaires à l'objet bien sûr).
Quand au conteneur à objet, IsaacOS en est un, par nature, mais natif lui. Le système est intrinsèquement et intégralement un système objet, tandis qu'avec une VM tu "applati" ton modèle mémoire en utilisant de la pagination classique.
Slate et Io ne me semblent pas offrir les possibilités d'héritages dynamique de lisaac, mais j'ai du le louper.
La morale de tout cela est pour moi la suivante : Les auteurs de Slate et Io qui ont commencé leur travail à peu près en même temps que Benoit, ne se sont pas concentrés sur le compilateur, mais sur le langage, il n'est donc pas étonnant que les résultats soient aussi intéressant.
Lisaac, lui est avant tout un compilateur qui résout la problématique d'un code "haut niveau pour le système aussi rapide que du C". Cela signifie que plus 90 % du travail s'est concentré sur le compilateur et comment supprimer la liaison dynamique, sans oublier la spécialisation de code et l'inlining ultra poussé.
Après, c'est très stimulant, il y a d'autres langages de ce genre ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pourquoi Lisaac ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Par exemple, la VM de Squeak a été codée directement en Smalltalk. Un traducteur, toujours en Smalltalk, se charge en ligne de le traduire en du code C mathématiquement correct. Ce qui signifie que la VM peut-être modifiée en directe dans l'environnement Squeak.
Il y a des projets intéressant de construire un OS objet au vrai sens du terme : un environnement dans lequel vivent des objets. IsaacOS en est un et j'attend qu'il soit suffisamment avancé avant de l'essayer. Il y en a d'autre, comme Unununium qui est écrit en Python.
Sinon, je suis d'accord avec toi sur le fait qu'avec une VM on ajoute juste une couche "applatie" au-dessus souvent d'un micro-noyau. C'est le cas par exemple de L4io (un OS construit avec io au-dessus de L4k)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.