Entropie anthropique

Il est généralement admis qu'en Ruby on ne peut pas faire d'appels bloquants sur une ressource externe à cause des green thread. Pourtant, j'ai remarqué que les threads Ruby se comportaient très bien quand un autre attendaient sur un appel à "Kernel.select" (polling sur des sockets). Je ne sais pas trop par quelle magie cela fonctionne, mais ça ouvre une porte à s'affranchir du problème que j'avais lors des premières versions de Férus. Je vais donc pouvoir faire un thread OS qui s'occupe de copier la donnée dans une socket qui sera lue avec select par Ruby. C'est très hacké, mais ça devrait marcher avec relativement peu d'overhead (une ou deux copies). Je vais tacher de faire une proof of concept et puis après qui sait? une lib? le soucis d'une librairie c'est qu'il faut s'occuper à la place de l'utilisateur de tous les évènements qui peuvent arriver sur une socket. Bref, c'est bizarre, mais ça pourrait me débloquer, et donc permettre d'éviter de griller du processeur pour rien (ce qui rendait les jeu en Férus encore plus lent que Ruby ne peut le permettre).

Si j'arrive au bout de cette aventure. L'architecture d'un programme férus, devrait ressembler à ça.

Férus est mon futur Framework de développement de jeux SDL. Il utiliser Ruby comme langage de scripts (les outils), et le C pour le codage du jeu lui même. Il y a donc à la fois une librairie en C et des outils d'assistance en Ruby. Ces outils sont bien entendus optionnels. Le but avoué et de rendre plus accessible, le codage de jeux SDL, tout en restant un outil productif pour les projets plus gros.

Dans une première phase, le workflow serait (dans la ville idyllique "san bug-isco") le suivant: - l'utilisateur défini un schéma de son jeu (les noms des écrans de jeux, les actions successives et les réponses aux touches) - on exécute un script qui transform ce schéma en un squelette de codes sources en langage C - on rempli les bouts manquants en C - on compile

La seconde phase sera de permettre également de coder la logique applicative directement en Ruby. On aurait ainsi un double export possible du schéma de base. Ça permettrait aux gens de rapidement coder un jeu en Ruby, et s'ils ont besoins de plus de performances, recommencer en C, mais avec la même "logique" en tête.

En parallèle, Férus devrait fournir des raccourcis pour les outils et algorithmes simples et utiles (les menus, les échiquiers) voire peut-être plus compliqués (le réseau, le pathfinding), et des outils fantaisistes (exports des schema dans des fichiers visuels, chunky baconiseur et export de projets).

Et si vraiment tout se passe pour le mieux et que des tas de développeurs et créateurs se joignent à Férus, pourquoi ne pas en faire une plateforme de jeu, avec un serveur de téléchargement des jeux, sauvegarde des high-scores etc.