Bon, je trouvais que de mettre du code python sans formatage, c'était un peu cheap. Malheureusement c'est rester coincé quelque part dans mon cerveau et impossible pour moi de dormir. Donc, après une petite séance de vidage de cerveau, voici le même code généré, toujours pas fonctionnel, mais cette fois formaté style IDLE:
## Avance le robot de x unite
classAvanceCommand( BaseCommand ):
""" Avance le robot de x unite """def__init__(self):
CommID = 1
nbrParam = 2
Unite = 0 #BaseInitType
Vitesse = 0 #BaseInitType
defdecode(self, bytearray ):
Unite = bytearray[0] #BaseInitType
Vitesse = bytearray[1] #BaseInitType
defencode(self, bytearray ):
Unite = 0 #BaseInitType
Vitesse = 0 #BaseInitType
## Fait tourné le robot sur x degree
classTourneCommand( BaseCommand ):
""" Fait tourné le robot sur x degree """def__init__(self):
CommID = 2
nbrParam = 2
Degree = 0 #BaseInitType
Vitesse = 0 #BaseInitType
defdecode(self, bytearray ):
Degree = bytearray[0] #BaseInitType
Vitesse = bytearray[1] #BaseInitType
defencode(self, bytearray ):
Degree = 0 #BaseInitType
Vitesse = 0 #BaseInitType
defHandleDecodeCommand( bytearray, commID ):
retcomm = None
if commID = 1:
retcomm = AvanceCommand()
retcomm.decode(byteArray)
elif commID = 2:
retcomm = TourneCommand()
retcomm.decode(byteArray)
return
Comme il reste une fonctionnalité à implémenter, je ne mettrai pas le code ici tout de suite, mais en gros c'est un petit script python qui prend un fichier en entré et qui génère un fichier HTML. J'ai utilisé les même couleurs que IDLE pour les mots réservés, méthodes intégrées au langages, commentaires et strings. En passant, il y a pygments qui fait en bien mieux le travail, a une interface web et un service web pour l'appeler directement en plus d'être installable localement via easy_install. Dans mon cas, c'était pour faire taire mon cerveau que j'ai fais ça.
Il y a un ordinateur embarqué dans tirobot et un microcontrôleur pour l'interface des senseurs et le contrôle des moteurs. Ici, on pourrait dire que le cerveau est le Raspberry Pi et le cervelet c'est le Arduino. Ce qui est bien, les deux peuvent se parler via USB, ce qui fourni aussi le courant au Arduino. Cependant, le Raspberry Pi sera programmé en Python et c'est du code C qui est compilé pour le Arduino. Il faut donc écrire un mini protocole de communication entre le deux. Tant qu'à ce définir un protocole, vaut mieux le développer tout de suite en introduisant les contraintes auxquels ont risque de faire face durant le développement et pourquoi pas penser au future avec des ajout possible.
Premièrement, il y a peu de mémoire sur le Arduino et ce n'est pas très puissant. Il font donc oublier le transfert via du texte. Il faut penser que le buffer de communication série du arduino ne fait que 64 octets et que sur le Uno Rev 3, il n'y a que 2 KBytes de RAM. Plus la taille des commandes sera petite, plus se sera rapide de les transférer sans oublier que convertir du texte en chiffre, c'est demandant pour le Arduino. Donc, se sera des commande binaire qui seront utilisées.
Le format est que j'ai implémenté est assez simple:
2 octets pour le numéro de la commande
1 octet pour la taille complète de la commande incluant sont numéro et l'octet de la taille ( valeur minimum de 3 finalement).
Liste de paramètre étant soit un octet signé ou non, 2 octet signé, 4 octets signé ou un virgule flottant sur 4 octet ( float).
Comme le format int du arduino Uno est un 2 octets signé, se sera le type le plus utilisé, mais si c'est possible de n'utiliser qu'un octet pour le transfert, pourquoi pas.
Pour ne pas avoir à trop coder pour chaque commande, je me suis défini un format bien simple pour décrire les commandes. J'utilise un classeur sous Google Drive que j'exporte en .CSV et j'ai du code Python qui transforme le fichier .CSV en code python et arduino capable de décoder et encoder en binaire la commande en plus de générer le squelettes des méthodes de traitement des commandes. Par exemple:
1
Avance
Avance le robot de x unites
2
a
Unite
i16
Vitesse
u8
La commande numéro 1, dont le nom est "Avance" ayant comme description "Avance le robot de x unites" a deux paramètres. Cette commande est envoyée vers le arduino ( "a" signifie arduino et "p" pour le code python et il est possible d'inscrire les deux). Le premier paramètre se nomme "Unite" et est un entier signé sur 2 octet ( int 16 bit ) et le deuxième paramètre se nomme "Vitesse" et est un entier non signé d'un octet ( unsigned byte ).
Le générateur de code a comme sortie deux fichier, un étant le code arduino et l'autre le code python.
Le fichier .CSV suivant:
1,Avance,Avance le robot de x unite,2,a,Unite,i16,Vitesse,u8,,
2,Tourne,Fait tourné le robot sur x degree,2,a,Degree,i16,Vitesse,u8,,
Permet d'avoir le code suivant en python:
## Avance le robot de x unite
class AvanceCommand( BaseCommand ):
""" Avance le robot de x unite """
def __init__(self):
CommID = 1
nbrParam = 2
Unite = 0 #BaseInitType
Vitesse = 0 #BaseInitType
def decode(self, bytearray ):
Unite = bytearray[0] #BaseInitType
Vitesse = bytearray[1] #BaseInitType
def encode(self, bytearray ):
Unite = 0 #BaseInitType
Vitesse = 0 #BaseInitType
## Fait tourné le robot sur x degree
class TourneCommand( BaseCommand ):
""" Fait tourné le robot sur x degree """
def __init__(self):
CommID = 2
nbrParam = 2
Degree = 0 #BaseInitType
Vitesse = 0 #BaseInitType
def decode(self, bytearray ):
Degree = bytearray[0] #BaseInitType
Vitesse = bytearray[1] #BaseInitType
def encode(self, bytearray ):
Degree = 0 #BaseInitType
Vitesse = 0 #BaseInitType
def HandleDecodeCommand( bytearray, commID ):
retcomm = None
if commID = 1:
retcomm = AvanceCommand()
retcomm.decode(byteArray)
elif commID = 2:
retcomm = TourneCommand()
retcomm.decode(byteArray)
return retcomm
Et celui-ci pour le arduino:
int DecodeAndHandleCommand(commID, char* databuffer)
{
switch (commID){
1: // Decode commande Avance
{
// Unite int// Vitesse int
Avance(*(int*)&databuff[0], (int)databuff[2]);
}
break;
2: // Decode commande Tourne
{
// Degree int// Vitesse int
Tourne(*(int*)&databuff[0], (int)databuff[2]);
}
break;
}
}
int Avance(int Unite, int Vitesse)
{
// Avance le robot de x unite
}
int Tourne(int Degree, int Vitesse)
{
// Fait tourné le robot sur x degree
}
Il ne reste que le code de gestion des ports séries et l'implémentation interne des commandes à écrire, le reste se génère seul. Possiblement que j'augmenterai le générateur avec d'autres fonctions tel la gestion d'enum ou encore de constante. Mais pour le moment c'est déjà un minimum intéressant, et pas débogué ni terminé en passant! Le code python n'est pas encore fonctionnel.
Bon sang que ça fait longtemps que je n'ai rien écrit ici! Pas que je suis resté tranquille c'est dernier mois. Je n'ai pas travailler sur ce que je pensais par contre. Je vais sûrement revenir au développement sur Android bientôt. Mais pour le moment, je suis tombé en amour avec Python! Ce qui m'a emmené à essayer plus sérieusement Python sont premièrement un projet au travail et une volonté d'utiliser mes raspberry pi sans avoir à me taper du C++ sous linux. Je voulais coder de quoi rapidement. J'avais déjà essayé Python il y a plusieurs années mais c'était trop lent pour ce que je voulais faire à l'époque et il n'y avait pas autant de librairies disponible. Maintenant, c'est tellement complet comme offre et tellement simple à programmer que je suis vendu Python. Je ne pense pas faire un jeux en Python, ça reste un langage interprété, mais pour bien d'autre utilisation où bien souvent la vitesse n'est pas un point important ou encore comme langage de haut-niveau qui permet d'interfacer plusieurs sous-système, c'en est merveilleux.
Tirobo-01 avec ses composants non fixés
Tout ça pour dire que mon projet en Python pour ne pas laisser mon 2e raspbery pi ramasser la poussière est un projet de petit robot. Petit, oui, mais combien impressionnant. J'ai fait mon shopping sur robotshop, shopping très instructif et je lève mon chapeau à un service après-ventre incroyable de leur part, et pour le prix de deux gros kit de lego ou megablock que monstre numéro 1 jouerait 2 ou 3 semaines avec et laisserait de côté, j'ai toutes les pièces pour fabriquer le jouet le plus techno qui soit. Voici en gros les pièces qui seront utilisées:
Évidemment, j'avais déjà certains composants ici dont le Raspberry pi, la clé wifi, DEL et bien des batteries rechargeables pour les moteurs. Mais pour environs 250$ et un peu de soudure, ça devient tout un petit robot. Mais pensez-y, le robot peu non seulement se brancher en HDMI et streamer des films en 1080p avec son surround, mais vous pouvez vous connecter réseau dessus, partir un session VNC avec desktop graphique qui inclus les environnements de développement pour le arduino mais aussi pour le code Python. Sincèrement, c'est vraiment impressionnant.
Une autre optimisation que je veux ajouter à mon engin graphique pour le jeu de monstre est en fait un vieil ami que j'ai côtoyé il y a plus de 20 ans lorsque je développais sur Mac, et je parle de mon vieux Mac Classic ! Les jeux de l'époque n'arrivait pas à faire plusieurs niveau de parallax puisque le fillrate était bien trop lourd, même en noir et blanc ( 1 bit par pixel ). Comme la plupart des backgrounds était fixes, le blit final pouvait être optimisé pour ne transférer que les parties qui ont été modifiées. Le truc était de séparer l'écran en tuiles, souvent 16 de large par 8 de haut, et masquer les bits correspondant à la tuile lorsque le sprite risque de la modifier. Ensuite suffit de blitter que les tuiles correspondant aux bit assigné C'est rapide et efficace, tant que le nombre de sprites n'est pas trop élevé.
Ici. comme le fillrate est un problème et la composition utilise justement plusieurs blits entre plusieurs images, chacune ayant plusieurs trou puisque ce n'est pas le background, ramener ce petit truc, surtout avec un nombre de sprites qui se veux limité, risque d'avoir un impact. Je ne sais pas à quel point bitshifter et masquer des unsigned short est optimisé en Java sous Dalvik, mais comme c'est le CPU qui va travailler pour aider un peu le GPU par la suite, ce devrait être tout de même gagnant.
Outre l'écran tactile, la position de l'appareil est quelque d'intuitif pour tout le monde. Il n'y a qu'a regarder quelqu'un qui n'est pas habitué à un contrôleur de jeu essayer de faire sauter un personnage en levant la manette. C'est justement ce genre de mouvement que l'accéléromètre permet d'interfacer. Ceci-dit, ce n'est si simple. Il y a plusieurs senseurs de disponible sur un appareil et ils ont tous leur particularité.
Pour justement m'amuser avec les senseurs, j'ai commencer une autre application qui va me permettre de lister les senseurs et valider leur utilisation. De plus, je vais lister le plus possible d'info disponible pour l'appareil ( processeurs, mémoire, support d'OpenGL, etc. ). Oui, il y a plusieurs application de disponible sur le PlayStore qui le font mais c'est pour me développer une boîte à outils et non faire un application qui va révolutionner le monde que je fais tout ça. Donc, ma première application sur le PlayStore sera... J'ai pas encore trouver le nom et j'ai pas trop regarder ce qui est nécessaire pour déployer une application, même gratuite, sur le PlayStore.
Le dernier gros morceau que j'ai optimisé est la résolution de la couche d'objet du centre. Étonnamment, l'optimisation à eu plus d'impact que je ne le pensais. J'ai aussi désactivé le lissage des couches d'ombres et de celle de la couche du milieu lors de la composition. Ici aussi le gain à été plus important que je ne l'aurais pensé. Puis tant qu'à faire, je configuré un scale pour la création des sprites d'ombre, ce qui devrait aider un peu lors du rendering des couches d'ombres. Ici le gains est marginal mais sûrement appréciable en terme d'utilisation de la mémoire.
C'est moins jolie mais une fois animé c'est beaucoup moins apparent.
Donc, après ces derniers essais d'optimisation qui ont ma fois plus que valus la peine, j'arrive à quelque chose de potable sur la Nexus 7 et totalement fluide sur mon Nexus S. Sur le téléphone, je peux augmenter la qualité sans problème, sur la Nexus 7, c'est borderline. Cependant, comme tout est configurable au runtime, je pourrai ajouter une méthode assez simple pour déterminé la qualité par défaut et permettre à l'usager de modifier les paramètres. Très probable qu'avec le temps je découvrirai quelque truc pour encore optimiser le rendering donc je considère que les deux couches d'ombres sont fonctionnelles et font partie du jeu. Je peux donc commencer à implémenter le jeu et faire plaisir à monstre no. 1 !!!
Donc, voici les paramètres modifiable pour le rendering:
Résolution de la couche d'ombre supérieure
Résolution de la couche d'ombre inférieure
Résolution de la couche d'image du centre
Lissage des couches d'ombres lors de la composition
Lissage de la couche d'image centrale lors de la composition
Résolution des sprites d'ombre
Les paramètres utilisés pour générer l'image ci-haut sont des résolution de 320x200 pour les couches d'ombre (25% taille originale), 640x400 (50% taille originale) pour la couche d'image centrale ( les nuages ), sprite d'ombre réduit de 50% et aucun lissage lors de la composition. C'est pas mal le plus cheap comme options.
J'ai tout de même essayé mais je ne pense pas que ce soit possible d'avoir deux couches d'ombre et de garder des animations fluides sur un Nexus 7, pas de la manière de je l'implémente en tout cas. J'ai retiré une couche de dessin temporaire et réduit du quart la taille des buffers d'ombre mais c'est toujours trop lent.
Même avec du filtering, des buffers temporaire à 1/4 de la résolution, ça parait
Il me reste tout de même quelques optimisations à faire et peut-être j'arriverai à quelque chose d'un peu plus potable mais pour le moment j'ai des doutes. Avec une seule couche d'ombre, c'est parfait mais le fillrate nécessaire pour la couche d'ombrage par dessus la couche du centre demande trop. Est-ce que c'est le setXferMode qui n'est pas optimisé sur le GPU qui ralentie tant que ça? Enfin, je vais laisser de côté le rendering des ombres pour stabiliser l'application et implémenter d'autre truc un peu plus utile. Monstre no. 1 s'impatiente de pouvoir jouer et comme les ombres ne l'intéresse pas trop...
Bon, j'ai un semblant d'engin graphique pour le jeu de monstre. Cependant, c'est un peu lent. En fait, trop lent pour être vraiment jouable. Sur mon téléphone c'est bien correct ( Nexus S ) mais sur un Nexus 7 2012, c'est trop demander. La résolution fait toute la différence. Comme il y a 4 buffers d'images temporaires en plus du rendering final, ça demande trop en fillrate. Il y a moyen de booster le tout en réduisant la taille des buffers d'ombre mais je ne sais pas si ce sera assez pour faire une véritable différence. Ensuite il faudrait limiter l'espace où les objets font de l'ombre ( genre seulement la partie basse de l'écran ) pour la couche la plus rapprochée. Il est aussi possible de tout simplement réduire à seulement deux couches d'objets et un seule couche d'ombre. Comme mon but c'est de développer le tout rapidement, je ne veux pas être obligé de tout recoder en OpenGL ES 2 et faire quelque passe passe en shader.
Enfin, le look dessiné à la main est bien et le calcul des ombres est dynamique. La lumière dans le screenshot est situé en plein centre de l'écran. Les feuilles sont sur la couche supérieure, les nuages au milieu et le soleil dans le fond. Évidemment, c'est beaucoup plus beau lorsque c'est animé.
C'est pas grand chose mais ça me permet d'apprendre Android et ses particularités tout en m'amusant avec monstre no. 1. Il a fait quelques dessins que j'ai scannés et j'ai commencé une structure de rendering en utilisant les appels graphique standard. J'avoue que c'est assez simple et supposément que depuis Android 3.0, tous les appels graphiques sont exécutés sur le GPU. Je n'ai pas fait de benchmark mais sur mon Nexus S, c'est smooth. Reste à voir sur le Nexus 7 2012 comment ça va réagir et surtout combien de sprites je pourrai utiliser.
Vous pouvez admirer mes talents de dessinateur avec le fond de l'image et les pommes! Les pieds, le tronc et la tête proviennent des images que j'ai scannées. Pour le moment, un swipe gauche ou droit permet de changer la tête du monstre. Autrement dit, j'ai du code de test pour le rendering de bitmap avec effet d'ombre et du code de test pour analyser la gestuelle. Ça amuse déjà monstre no. 1 et ça lui donne le goût de continuer à développer le jeu. Nous avons enregistré des sons de monstre avec mon téléphone et la prochaine étape est de faire jouer un son au hasard lorsqu'on tape sur la tête.
Comme la classe SoundPool s'occupe de gérer les effets sonores, ce ne sera pas grand chose à implémenter. Je vais surtout me concentrer à définir les sprites et l'engin de composition. Comme je veux gérer deux couches d'ombrage, il va y avoir des bitmaps offscreen pour le rendering des couches d'ombres et des couches d'images temporaires. Je me demande surtout s'il est plus utile de générer des bitmaps d'ombre pour chaque sprite ou reprendre le bitmap original et utilisant un shader pour ne dessiner que l'alpha. Il est terriblement simple de générer un bitmap d'ombre à partir d'une image. La méthode extractAlpha s"occupe de tout. J'imagine qu'elle retourne un bitmap en format ALPHA_8 ce qui sauve pas mal en mémoire. De plus, les bitmap temporaire pour le rendering d'ombre sont en format ALPHA_8. Je ne connais pas de tablette Android avec de la mémoire vidéo GDDR5, donc limiter l'accès mémoire devrait être un gain même si le processing GPU est le même. Enfin, on verra plus tard.
Avec monstre numéro 1 qui vient de commencer la maternelle, je me demandais comment utiliser son intérêt pour les jeux vidéos et l'aider dans sa nouvelle démarche académique ( c'est un peu pompeux dit comme ça ). J'ai pensé développer un tout petit jeu pour téléphone intelligent ce qui lui ferait voir les différente étapes et compétence requise pour réaliser un projet. Lui faire dessiner les sprites, enregistrer les son et appliquer la logique dans le gameplay. C'est tout de même une introduction à l'algorithmie, à la production de contenu et au suivi de projet.
J'ai tout de même dit "un petit jeu". Donc voici la première phase à réaliser, soit la création du monstre. Oui, le but du jeu est de fabriquer un monstre!!! Là aussi c'est dans le simple, il y a quelque choix pour la tête, le tronc et les pieds. Swipe gauche ou droit sur un des trois éléments et ça change. Si c'est un simple touch, alors il y a un son et une petite animation ( zoom et déplacement ). C'est simple mais ça fera la job.
Voici quelque caractéristique du projet:
développé sous Android 4
utilise les commande de dessins standard ( Canvas et bitmap ) et non OGL
gestion de couche d'ombre générer par du rendering offscreen sous format ALPHA_8
Enfin, reste à voir ce que j'arriverai à faire avec monstres numéro 1 avant qu'il se tanne du projet.
Ça fait un petit bout de temps que je n'ai pas programmé quelque chose qui s'apparente à un jeu vidéo, c'est le temps de m'y mettre je crois. Mon gros problème est de partir des projets trop complexes, manquer de temps et de motivation et tout laisser tomber, alors j'essais quelque chose de nouveau: j'essais l'open source.
En fait, j'ai envie de partir from scratch. Pas d'engin, pas d'outils, pas de librairie qui fait tout. Sauf que cette fois, j'essais de le faire dans un mindset open source. Donc IDE gratuit, multi-plateforme, code ouvert, fichier de donnée ouvert. Peut-être que d'ouvrir le tout va inciter quelques personnes à me joindre dans l'aventure et ça pourra aboutir à quelque chose. De plus, je documenterai le développement, ça fera un crash course du genre "how to make an open source video game".
Voici en bullet point les caractéristiques de la bête:
Programmé en C++
Utilise OpenGL et OpenGL ES pour le rendu
Fonctionne sur le Raspberry Pi ( l'engin en tout cas )
Fonctionne sous Linux et Windows ( je ne ferai pas la version Mac mais devrait être simple à porter )
Comme j'aimerais que ça tourne sur le Raspberri Py, on s'entend que ce sera de la 3D simple. Aussi, je vais privilégier des construction claire et du code verbose à l'optimisation et la vitesse. Donc bien des classes avec des méthodes virtuelles et peu de tableaux de valeurs hardcodées et appels ésotériques.
Bon, la OUYA est disponible en magasin, C'est sold-out sur Amazon fait que ce devrait être une version prête pour le grand publique qui fait la joie des gamers...
Bien, Best Buy ( et par la bande future shop ) a décidé de ne pas la vendre et attendre voir si ça va pogner. C'est pas bon signe. En fait, c'est assez grave. Oui, la console s'est améliorée depuis que j'ai reçu ma version de Kickstarter. Les boutons de la manette ne reste plus enfoncés pour la version en magasin. Le menu principal répond mieux, le wifi un peu plus stable et la manette prend du retard un peu moins rapidement. Reste que ce sont des points majeures qui ne devraient pas être encore là.
Oui, plus vous jouez longtemps à un jeu, plus la temps de réaction entre la manette et le jeu augmente. Je ne parle pas d'un frame ou deux, le plus long que j'ai vu c'est 2 secondes. C'est pas rien, c'est carrément injouable lorsque ça arrive. Pour ce qui est du wifi. Il faut fermer la console et pas seulement la mettre en veille pour être certains d'avoir du réseau. Si elle n'était qu'en veille, possible que lorsqu'elle se réveillera, le réseau sera kaput et impossible de se reconnecter. Il y a pire encore: plusieurs jeu crash! Soit c'est un retour au menu sans raison, soit ils ne veulent pas démarrer.
Mois qui pensais m'en servir comme media player, bien il faut faire du side loading pour avoir XBMC et il n'y a rien comme player, aussi merdique possible, de disponible. Supposé que Netflix et autres feront leur apparition dans le magasin d'application mais reste à voir quand.
Enfin, ça pogne tout de même avec les monstres. Pour des séances de jeu de max 20 minutes, ça passe, surtout que je n'ai pas acheté de jeu. J'ai pas vraiment envie de payer pour quelque chose qui ne marche pas vraiment. Parlant de payer, le prix des jeux n'est inscrit nul part, ni le type de paiement ( genre one shot deal ou micro transaction ). C'est seulement dans le jeu, lorsqu'on décide de payer que le prix est indiqué. Juste pour le fun, j'ai regardé le prix de Final Fantasy III. Alors qu'il est disponible à 7.99$ sur le Play Store, il est 14.99$ sur le OUYA. Le même estifi de jeu en passant, excepté pour l'icône des boutons. J'ai pas osé regarder le prix des autres.
Outre le problème de bouton qui reste collé, tous les autres problèmes peuvent être corrigés via un update du firmware et des autres logiciels, c'est le seul point positif. Un bonne mise à jour d'ici deux semaines, l'ajout de 3 ou 4 bons jeux, Netflix et un player de films/musique, et ce sera pas mal. Mais il faut vraiment faire vite, sinon la compétition risque des les rattraper! La rumeur veut que Google sorte un genre de Google TV /console de jeux, il y a le Gamestick qui sort bientôt ( et qui est moins dispendieux ), Mad Catz aura une console compatible avec ses accessoire nommé project M.O.J.O. ainsi qu'Nvidia qui sort une version portable d'une console Android utilisant un processeur Tegra 4 ( quoi que le shield est voué à l'échec selon moi ). Il va y avoir du monde à messe.
Tout ça pour dire que je code un petit quelque chose en Python qui va utiliser la température extérieure. Tout de même, 17 degrés à 2h du matin, ça commence à faire été !
Bon, j'ai reçu ma OUYA, mais je ne peux pas dire que je suis des plus enchanté. Disons que l'expérience n'a pas été des plus plaisante au début. J'avoue que de vouloir essayer une nouvelle console en soupant avec deux enfants, dont un n'à que deux ans, c'est courir après le trouble. Mais n'empêche qu'il y a certaines choses auxquels je ne m'attendais pas.
Monstre numéro 1 veux essayer la nouvelle manette!
Tout d'abords, pour une console requérant une connexion internet, la qualité du wifi est médiocre. Je n'ai réussi qu'a connecter ma OUYA de peine et misère sur le wifi le temps de downloader l'update de l'OS puis ensuite rien à faire, c'est intermittent et le réseau fini par n'être même plus détecté. Une maudite chance qu'avec le succès de Kickstarter ils ont ajoutés une connexion RJ-45. Mais reste que sans accès filaire dans le salon, la OUYA ne pourra y rester. En passant, mon téléphone, mon RaspberryPi avec une clé Wifi USB de 10$, mon vieux portable scrap. mon vieux portable un peu moins scrap. mon vieux ipod et tous les autres appareils wifi que plein de monde on apportés chez-moi on tous une bonne réception à plus du double de la distance du routeur que la OUYA!!!!
Ensuite, malgré le fait que mon nom d'usager soit réservé en tant que backer de Kickstarter, rien à faire, ma OUYA ne veut pas que je m'y connecte. Une fois sur le site, j'essais de faire un reset du mot de passe mais c'est comme si mon courriel n'est pas dans le système puisque je n'ai jamais reçu mon email pour effectuer mon changement. Pourtant, mon email est bien dans le système car:
1- J'ai reçu un courriel de confirmation pour mon nom d'usager à cette adresse.
2- Lorsque j'ai essayer de me créer un nouvel usager avec cette adresse, il refuse car le courriel est déjà lier à un autre usager.
De plus, comme la création du nouvel usager avait planté la première fois car le réseau n'était plus disponible. La console est restée liée à ce compte mais je ne pouvais me connecter car le compte n'était pas valide. J'ai dû faire un reformat ( relancer l'application Setup ) afin de pouvoir enfin faire quoi que ce soit avec la console.
Ce qui me dérange le plus avec la OUYA pour le moment, ce sont la disponibilité des jeux et la qualité du dashboard. D'abords, il n'y presque pas de jeux de qualité, et la je ne parle pas de jeux AAA, mais quelque chose d'un peu mieux que sur le XBOX Indie. Outre Final fantasy 3, ce sont des jeux style projet de fin de session au secondaire qui sont disponibles. Je m'attendais à plus de ports de jeux pas trop mal existant sous Android mais finalement, c'est pas des gros chars. Je suis très conscient qu'en si peu de temps, il n'y aurait pas de contenu exclusif de qualité, mais là, l'offre est à c@%!r. J'imagines que les développeurs préfères être prêts pour le lancement "grand publique" à la fin juin mais il faudra faire vite sinon la console sera associée à du contenus, bien que certains intéressant, pas très vendeur. Avoir une version de minecraft, même si c'est la même que sur le Playstore et au même prix ne ferait pas de torts. De plus, toujours pas de XBMC, Plex ou Netflix. Donc il faut encore attendre pour pouvoir l'utiliser comme lecteur de médias.
Ensuite, il y a le dashboard qui fait terriblement pitié. Il est lent, les images de jeux ne s'affichent pas tout le temps ce qui outre le nom en petit dans le bas, il n'y a qu'un carré gris pour l'identifier. Les fiches descriptives des jeux comportent quelques images dont on ne peut pas agrandir, donc ça reste de petit thumbnail, qui d'une certaine façon masque les graphiques cheapo des jeux disponibles. Il y a du son sur certains événements comme monter et descendre entre les images mais pas de gauche à droite, son qui n'est pas audible dans le reste de la navigation. Puisque ce sera du contenu indie, il faudra une catégorisation et une possibilité de recherche beaucoup plus sophistiquées pour ne pas perdre les bons, les intéressants et les essais prometteur des craps produites par deux ou trois ados avec un peu d'expérience en programmation qui ont un chummy qui dessine moyennement bien et qu'il veulent faire un autre jeux de style rétro mais dont les sprites font honte au vieux NES. Me semble que des suggestion selon les jeux que l'on a, que l'on a noté et si un jour il y a un côté social, selon nos amis et nos intérêt ne ferait pas de mal. Autre détails, dès qu'un compte est créé, il est demandé d'entrer les informations de carte de crédit. Le pire, c'est qu'il est écrit que sans cette information, il sera impossible de télécharger de jeux! C'est faux, j'ai fait skip et je télécharge des jeux sans problème.
Écran d'accueille de la OUYA
Enfin, le hardware pour ce type de console semble bien, excepter le wifi, mais d'ici deux ans il commencera à être désuet. Même s'il est annoncé qu'il y aura une révision hardware chaque année, est-ce que ce sera apprécié des acheteurs, des développeurs ou même viable en coût de développement pour la compagnie, c'est à voir.
Je n'ai pas trop regardé les SDK ni les particularités de la console et encore moins testé le développement d'application en branchant la console sur le PC mais j'imagine que ce doit être relativement identique au développement d'applications pour appareils Android, seul le packaging pour la distribution ( paiement, info du jeux, gestion de contrôleur ) doit être différent.
Les composants du OUYA démontés par iFixit
Je ne désespère pas tout de suite et ne crie pas au flop. Ce n'est pas, et ne sera jamais une console qui pourra rivaliser avec les grands comme Microsoft, SONY et même Nintendo. Il faut la prendre comme un jouet et non non comme une console pour hard core. Mais soit la console est sortie trop rapidement, soit l'intérêt des développeurs n'est pas encore là, soit il n'y a pas assez de main d'oeuvre ou il y a une mauvaise gestion du développement logiciel chez OUYA. Un espérant que ce ne sont pas toute ces réponses sinon je ne vois pas beaucoup d'autre OUYA produites outre celle allant aux backers sur Kickstarter!
Je fais parti des fous furieux qui ont contribué à la campagne de la OUYA sur kickstarter mais je n'étais pas de ceux de la vague originelle, donc je ne suis pas dans les premiers à la recevoir. En fait, je devrais la recevoir bientôt car le tracking de DHL indique qu'elle est arrivée au "sort facility EASTERN QUEBEC AREA" . Les premiers commentaires sur la console sont selon moi prometteurs puisqu'il disent que ce n'est pas grand chose comparé à un XBOX 360 et encore moins un PS4. Si je considère ça prometteur c'est que ce n'est justement pas comparable à un XBOX 360 ou un PS4. Il n'y aura pas de jeux AAA ( sauf peut-être des ports de vieux jeux ) mais c'est une plateforme pour développeur de jeux indépendant. Je vois ça entre le XBOX Live Arcade et le XBOX indie game. Trop complexe pour les indies vraiment amateurs mais pas assez viable pour des jeux à 20$. Il faut penser qu'il n'y a pas plus de 50 000 OUYA qui ont pris preneur avec kickstarter et on ne sait pas trop combien en ont précommandés via le site ouya,tv. Cependant, il sera disponible via amazon.ca au Canada et quelques magasins comme best buy, gamestop et target chez nos voisins du sud. Dommage de dire ça, mais sans Walmart, je ne pense pas que ce soit un succès mainstream. Donc disons 60 000 console d'ici la fin juin, c'est pas un nombre bien élevé quand on considère que 3.5 millions de Wii U est considéré comme un échec.
La machine n'est pas très performante, et la rapidité de développement de l'infrastructure logiciel ( SDK, magasins d'applications ) ne permet pas d'avoir un système top-notch dès sa sortie. Par contre, ce peut être le HTPC ultime. XBMC et Plex sont disponibles et la petite boîte à assez de humpf pour jouer le contenu en 1080p sans problème en plus de fournir une librairie de jeux cheap mais surtout des émulateurs et autres applications upfront qui sont seulement disponible sur une version hackée d'un apple TV. C'est cette ouverture à d'autres contenus et le support de standard ouvert ( autant que l'on peu considérer Android ouvert ) qui pourra permettre à cette petite machine de se démarquer. Mais s'il-vous-plaît, arrêter de comparer ça aux vraies consoles de salon. Surtout qu'à 50$ le contrôleur cheap supplémentaire, il n'y aura pas beaucoup de multiplayer sur le même écran. Comme le marché sera trop limité, il n'y aura pas de version moins dispendieuse par un autre fabricant et selon les commentaires, la qualité de la manette originale se compare aux manettes cheapo disponible pour XBOX. En plus, une OUYA plus un contrôleur supplémentaire coûte la même chose qu'un XBOX 360 arcade, fait que...
Ce que je m'explique mal c'est toute la presse positive que la OUYA à reçue depuis son dévoilement, un peu comme si personne ne voyait justement les limitations de la machine ou encore le côté "nous allons être une console pour les développeurs indépendants" dès le départ. Ensuite, c'est un quasi lynchage quant à la console qui n'est supposément pas à la hauteur. Shame on you journalistes incompétents.
Changement abrupte de sujet, j'ai écouté Coeur circuit 2 avec les monstres aujourd'hui et je me demandais ce que Johnny 5 deviendrait s'il serait créé maintenant. Il est mû par un désir constant de rechercher des données. Mettons que le gars se trouverait un lien réseau performant et passerait ses journées à browser le web. Surtout que la version du film n'a que 500 mégaoctets de mémoire, suffit de lui ajouter un SSD le plus cheap possible et impossible de mourir si les piles flanches. Ça limite les aventures en ville et les rencontres avec de gentils truands ou les vols de diamants. Finalement, le Terminator est un design de robot qui tiens encore bien la route.
J'ai eu la chance d'essayer quelques kits de réalité virtuelle au cours des années. Des premiers VFX1 durant l'époque de Doom ( dans mon cas c'était Marathon sur Mac qui était bien supérieur selon moi ) au dernier par Vuzix, l'expérience était plus du genre "un jour ça va être vraiment bien". Avec l'Oculus Rift, bien le jours est pas mal arrivé. Dans la doc publicitaire, Oculus parle du "day 0" pour la réalité virtuelle et je les crois. C'est la première fois que c'est réellement immersif. Tous les autres kit, non militaires en tout cas, donnait toujours l'impression de regarder à travers une fenêtre plus ou moins grande en plus d'avoir un assez long décalage entre le mouvement de la tête et le rendu. Cette fois, il n'y a plus de fenêtre, la bordure qui est tout de même visible en vision périphérique est si petite que le cerveau en fait abstraction et l'impression d'être dans la scène est complète. La qualité des senseurs d'orientation et du logiciel de prédiction est tel que je n'ai senti aucun lag. Ceci dit, le rift n'est pas un produit commercial. C'est un kit pour développeur dont certains points reste à améliorer. Parlons donc du kit
Close-up du Rift
L'Oculus Rift est un casque de réalité virtuelle permettant l'affichage en 3D stéréoscopique et la détection de l'orientation dans l'espace. Il fut lancé en tant que projet sur Kickstarter et il a été un véritable succès, surtout grâce aux support de vétérans de l'industrie tel que Jonh Carmack Le casque lui-même est connecté à une boîte d'interface qui nécessite du courant, une connexion USB avec l'ordinateur et un signal vidéo soit DVI ou HDMI.Il est livré dans une mallette de transport en plastique. Outre le casque, la boîte d'interface et l'adaptateur de courant, il inclus une panoplie de fils DVI, HDMI ( 3 pieds et 6 pieds ), USB et des convertisseurs pour prise électrique un peu partout dans le monde. Disons que c'est assez inhabituel de voir autant de connectique fournie out-of-the-box. De plus, 3 couples de lentilles sont disponibles pour accommoder différent type de vision et il est possible de déplacer la distance entre les lentilles et les yeux, tout spécialement pour accommoder ceux portant des lunette comme moi.
Les pièces composants le rift sont celles utilisées par l'industrie des téléphones intelligents ( écran, gyro, etc ). C'est leur intégration qui rend le rift si spécial. Premièrement, la déformation optique est compensée par le logiciel de rendu, il y a des lentilles pour chaque oeil qui déforment l'image projetée sur un écran de petite tablette ( 7 pouces ). Cette déformation de loupe sur l'écran est "inverser" par le logiciel. Donc pas d'optique ultra-complexe ou d'électronique ultra-coûteuse pour permettre d'afficher l'image générée tel quel. L'oeil est plus sensible et précis au centre de la vision alors qu'ici il y a le moins de précision justement au centre de l'affichage.
Tous les composant du Rift une fois démonté par iFixit
Comme c'est un kit de développement, il n'y a pas de jeux ou de logiciel fourni avec le Rift, il y a un SDK permettant l'intégration du Rift dans des engin de jeux existant et du code source pour l'intégrer dans un engin maison. Pour essayer le Rift, une scène simple a été réalisée avec Unity permettant de se promener dans une maison de Tuscany. Bien que simpliste et très limité, c'est tout de même renversant. Il y a une version de l'éditeur d'Unreal 3 qui est aussi disponible et il est possible d'essayer n'importe quel scène avec le Rift. Il y a Epic citadel bien connu sur téléphone intelligent mais aussi des tableau d'Unreal qui sont les plus complexe et visuellement impressionnant en plus de permettre de contrôler des véhicules. Être devant une statue de 12 pieds de hauts ou sauter d'une plateforme des 40 pieds prend une toute autre signification avec le Rift.
Je me sens tout petit!
Puisque que chaque moitié horizontale est affiché pour un oeil différent, il n'y a pas de d'alternance dans le rendu et l'affichage contrairement à les télé 3D ou au cinéma avec le système de RealD. L'image résultante est donc séparée en deux horizontalement et déformée pour compenser la déformation optique.
Ma première expérience avec le Rift se résume à être Flabergasté, me mettre à rire en essayant de suivre le petite boule de pollen et soudainement avoir des nausées. Oui, ça prend 3 minutes et si on ne sait pas trop comment contrôler notre déplacement, le mal des transports nous frappe. Il ne faut surtout pas essayer de se déplacer de côté ou encore compenser la rotation du personnage avec la tête, c'est une recette pour induire des vomissements. Rester la tête droite pendant que l'on déplace le personnage ( surtout les rotations ), ne pas marcher de côté ( straffer ) et si possible ne pas reculer, sont des conseils à suivre. Ceci dit, à force d'essayer et de s'habituer au genre de déplacement, en plus d'habituer notre cerveau à accepter ce genre de réalité, j'arrive à rester connecté beaucoup plus longtemps qu'au début, mais pas plus de 15 minutes encore. Il est a noter que le casque est confortable, pas trop lourd et mes lunettes ne cause pas de problème, quoi que je porte un modèle assez petit.
Leurs réactions n'est pas fake, c'est vraiment l'effet que ça fait
Je dois dire que j'ai été chanceux d'essayer le Rift ce week-end. Puisqu'Oculus envoie ses colis par UPS et que j'ai manqué la livraison, je pensais être obligé d'attendre à lundi prochain pour le recevoir, tout en étant obligé de travailler de la maison puisqu'il faut payer la douane sur réception. Heureusement, il y a un arrangement avec Purolator ici à Rimouski afin de pouvoir aller chercher et payer les frais de dédouanage, chose qui n'était pas indiquée sur le papier laissé sur ma porte mais qu'un ami m'a fait savoir. Parce que oui, UPS charge à fort prix leur dédouanage. Tellement qu'avec les plaintes des autres canadiens, Oculus à changer l'envoie vers le Canada en utilisant USPS ( la poste américaine ). Sincèrement, plus de 60$ de frais de dédouanage ( à part les taxes ) c'est vraiment exagéré.
Problématiques à résoudre pour la version commerciale du Rift
Intégration et support du Rift par les développeurs.
Contrairement au casque de Vuzix qui utilisait les drivers stéréo d'Nvidia, le Rift nécessite une modification à l'intérieur de l'engin de rendu. De plus, il faut ajouter le support du moteur de prédiction de mouvement pour avoir une meilleure intégration des senseur d'orientation. Il y a tout de même certains qui ont réussi à bricoler des drivers qui permettent à certains jeux existant d'être utilisé avec le rift comme vireio et vorpX, Il n'y a rien d'étonnant a ce que ce soit le cas et plusieurs développeur ont déjà annoncés l'intégration du Rift dans leur prochains produits. Même ceux qui n'on pas publiquement parlé du Rift en ont plusieurs dans leur bureaux De plus, plusieurs moteur de rendu ont déjà ajouté l'intégration du Rift dans leur version actuelle et future. D'ailleur, le kit de développement fourni une version d'Unreal et de Unity supportant le Rift. Le seul jeu présentement disponible pour le Rift est Team Fortress 2 de Valve. Hawken devrait sortir un update prochainement permettant d'être à l'intérieur du cockpit de leurs robots géants spécialement pour le Rift. Mojang est l'un des premiers développeur à recevoir des Rift pour l'intégrer à Minecraft. Tout ça pour dire que c'est probablement un problème qui n'en sera pas un. Alors que le Rift devait être livré avec une version de Doom 3 BFG, Zenimax ne semble pas avoir laissé Carmack mettre à jour le code qu'il avait fait pour la démo de l'ancien prototype. Cependant, le source de Doom 3 est ouvert et il y a une gang de mordu qui y travail déjà. Ce devrait donc être pour bientôt.
La résolution de la dalle LCD du Rift.
Alors que le Rift utilise un écran de 1280 pixels de large par 800 pixels de haut, cette résolution est coupée en deux horizontalement puisque chaque oeil n'en voit que la moité. Déjà donc, 640 par 800 pixels. Ensuite, la déformation sphérique grossit les pixels du centre et élague ceux en périphérie. Donc approximativement au centre 90% de pixels horizontale sont visible mais ceux du haut ou du bas sont quasi inexistants. Je dirais qu'environs le tiers des pixels sont visibles. Donc une résolution perceptible d'environs 480 par 400. Les pixels sont donc clairement visible et les détails de la dalle LCD le sont surtout au centre ( séparation des couleurs et bordure noir entre pixels ). Imaginez regarder un vieux téléviseur CRT de trop près avec un moustiquaire placer dessus. C'est une des amélioration prévue pour la version commerciale. Au minimum, une dalle de 1920 par 1080 ou encore quelque chose du genre retina display ( 2048 par 1536 ). Pouvoir doubler réellement la résolution serait bien ( 2560 par 1600 ). Autre problématique relié à la dalle LCD, la vitesse de rafraîchissement laisse des traces ( ghosting ). Alors que les écrans d'ordinateur sont entre 1 et 5 millisecondes, le Rift est à 30.
Le manque de positionnement dans l'espace.
Avec cette immersion visuelle quasi totale, tous les petits détails deviennent important. La rotation est si bien implémentée que le cerveau s'attends à ce que la position y soit aussi. Bouger la tête de gauche à droite ou se pencher ne change rien à ce qui est rendus à l'écran. C'est un manque que le cerveau n'aime pas et est une cause de mal des transports ( cinétose ). Il y a déjà des technologies pouvant être ajoutées au Rift facilement et qui risque fort bien de l'être pour la version finale. Il y a déjà beaucoup de gens qui utilise le Rift en conjonction avec le Hydra de Razer et Oculus à déjà fait mention de discussions faite avec Razer. Le Hydra sera probablement mon prochain achat d’ailleurs.
Standardisation de la configuration.
Oui, il est important de configurer le Rift, et ce pour chaque personne. Il y a la distance pupillaire ( la distance entre vos yeux ) qui sert dans le calcul du rendu. Pour le moment, seulement Team Fortress offre une interface pour configurer cette distance. Cependant, je ne sais pas si cette information est stockée pour l'usager ou seulement pour le jeu. Il serait bien de pouvoir configurer une seule fois et de pouvoir utiliser l'information pour tous les jeux, au minimum localement sur l'ordinateur. Si Steam, Live et autres services utilisant le cloud pour le stockage des info de joueurs emboîte le pas, se serait vraiment bien. De plus, d'un jeu à l'autre, le test de distance pupillaire doit être implémenté. Il serait bien que ce test soit fourni par Oculus, donc standard partout. De plus, des informations comme la taille du joueur pourrait servir, tout spécialement pour les premières incursions puisque d'avoir une taille différente dans un jeu comparativement à celle dans la réalité n'est pas facile à accepter par le cerveau. La plupart des engins permette de configurer ces valeurs mais elles sont cachées dans des fichiers de configurations obscures.
Les prochaines problématique sont cependant le plus difficiles à corriger
La cinétose induite par le style de jeu.
Oui, simplement intégrer le support du Rift dans un jeu n'est fait pas un bon jeu pour la réalité virtuelle.Tomber de 50 pieds puis tout simplement repartir à courir à environs 25 Km/h n'est pas quelque chose que le cerveau accepte facilement. Alors que c'est trippant dans un jeu comme Quake sur un écran d'ordi, ça rend malade la plupart des gens avec le Rift. Il va donc falloir non seulement modifier les jeux pour permettre une entré en matière mais il est nécessaire de désensibiliser le cerveau, tout comme pour ceux qui ont le mal de mer. Aussi, comme les jeunes de 2 à 12 ans sont le plus sensible, il leur sera déconseillé. De toute manière, la 3D stéréoscopique n'est pas recommandée pour eux non plus.
Le niveau de détail des mondes virtuels
Il y a plusieurs truc de rendu qui donne d'excellent résultat lorsque rendus sur un écran 2D. Cependant, ces techniques ne valent plus rien en 3D puisque le trucage est visible. La plupart d'effet de parallax ne passent pas car bien que la couleur est correct selon l'effet 3D, la géométrie elle reste plate ce qui est maintenant visible. Il faut le faire à la dure en utilisant plus de vertex. Alors que les nouvelles cartes vidéo supportent la tessellation en shader, ce n'est pas encore encré dans les pipelines de production. La prochaine génération de console va forcer l'adoption de ces techniques mais ça va prendre encore un peu de temps avant que ce soit répandu De plus, par le côté immersif de cette technologie, l'exploration des lieux devient plus intuitif et il faut donc plus de détails dans l'ensemble de l'univers représenté pour ne pas induire de discontinuité dans l'illusion ( suspension of disbelief ). C'est un peu comme le 48 images par secondes au cinéma. Tout les petits trucs utilisés qui donnent c'est impression spéciale au grand écrans s'estompent et le monde féerique devient ordinaire et cheap. Les changement de mipmaps sont terriblement apparent De plus, il n'y pas que le côté visuel mais aussi auditif qu'il faut travailler. L'immersion visuelle étant totale, le son devient étrange s'il n'est pas aussi immersif. Être dans l'eau et entendre le son de l'eau qui coule devant soit et non sous ses pieds parce qu'il n'y que deux ou 3 sources sonores de placées le long d'un cours d'eau ne marche plus.
Le besoin d'un séquence d'image constante ( frame rate )
Il est hyper important pour ne pas briser l'illusion d'avoir un minimum de 60 images par seconde, et ce synchronisée. Pas de teering en plein milieu de l'écran, donc pas le droit de changer d'image pendant l'affichage, en plus de demander une assez bonne résolution et un monde plus détaillé. Le Rift demande beaucoup à la carte vidéo. Alors qu'un PS3 n'a pas de problème à générer des images en Full HD, le Rift risque d'être taxant même pour le prochain PS4. Ma GT 650 arrive à peine à faire le travail avec des scène moyenne sur le kit de développement du Rift, elle ne sera jamais capable de fournir pour la version commerciale. D'ici deux ans, les cartes vidéos moyennes gamme devrait suffire mais j'ai l'impression que ce sera le haut de gamme qui sera nécessaire. Pas certains qu'une GTX 680 ou un HD 7970, bien que parfaite pour le kit de dev, soit assez performante pour la version commerciale. Je pensais que ce serait l'adoption du 4K qui serait le prochain catalyseur pour augmenter la puissance des cartes vidéos mais finalement ce sera plus l'adoption de la réalité virtuelle, si elle se fait, qui gonflera les portefeuilles de Nvidia de ce monde. Je serait curieux de voir un engin de raytracing utilisé au lieu d'un rasterizer standard. Non seulement les pixels non utilisés ne sont pas calculer mais comme il y a un poids visuel différent entre le pixel du centre et ceux en périphérie, il est possible de modifier le niveau de récursion et de d'aliasing par pixel, sans parler de la qualité visuelle. Peut-être qu'un engin hybride va faire du sens ( pré-calcul des map d'ombre, de réflexion et d'environnement avec la carte, rendu final via ray-tracing en GPGPU ).
La création de contenu spécifique pour la réalité virtuelle.
Alors que de plus beaux graphiques, plus de détails, une séquence d'image soutenue sont tous perceptible dans un contexte 2D, le style de jeux et de contrôle doit être modifié pour pour utiliser pleinement un casque comme le Rift. Pour certains, il suffit de mettre le joueur à l'intérieur d'un cockpit, ce qui non seulement aide à diminuer la cinétose en donnant un point de repère fixe au joueur, ça augmente le réalisme. Pour d'autre, il faut ralentir le déplacement ce qui a un impact sur le gameplay. Il va donc y avoir certains jeux qui ne seront pas portés en VR alors que d'autre ne seront pas intéressant dans un contexte de salon. Il est impossible de placarder directement les UI en 2D ( pointage, etc. ) puisque ce peut être une cause de cinétose, il faut donc que le UI soit 3D lui aussi. Reste à voir si l'adoption du Rift va permettre le développement d'un écosystème viable pour le développement de jeux spécialement conçus pour la VR. C'est un peu le problème de la poule et de l'oeuf. Il y a cependant certains style de jeux qui aurait tout avantage à implémenter le Rift:
Les jeux d'exploration et de puzzle:
Par défaut, le déplacement dans l'univers est calqué sur la réalité et l'attention au détails fait partie du gameplay. Les Myst, Dear Esther ou encore les survial horror du style du premier Residen Evil vont redevenir intéressant en VR.
Jolie chute d'eau à la sortie du château d'Epic citadel. L'effet de profondeur est saisissant.
Les RTS, stratégie et autre God game:
Avoir un point de vue surplombant l'aire de jeu et tout simplement tourner la tête pour voir les ennemis s'en venir ou rapidement voir la dispersion de ses unités devient tout un atout. Une fois les HUD modifiés et l'interface de contrôle adaptée, je me vois mal revenir jouer à quelque chose du genre sur un écran d'ordi.
Tout simulateur de véhicule:
Que ce soit des simulateur d'avions, bateaux, de gros robots, de voitures, de vaisseaux spatiaux ou même de tracteurs de ferme, pouvoir admirer de l'intérieur du véhicule le paysage extérieur donne une tout autre expérience. Probablement que les simulateur de F1 risque de donner le mal des transport puisque si près du sol, mais bon, on verra.
Conclusion
On est bien rendu là où les films des années 90 voulaient nous le laisser croire. Toute la technologie existe et est abordable. Utiliser un Kinect, le Hydra et le Rift permet de faire une interface d'immersion tel que vue dans des films ( OK, pas très bon ) comme Harcèlement avec Michael Douglas et Demi Moore ou même à la limite comme le Cobaye. Outre le jeu, il y a beaucoup d'espoir et de recherche pour aider les gens souffrant de phobies, d'autisme ou de syndrome post-traumatique avec la réalité virtuelle, donc oui ça affecte le cerveau beaucoup plus que l'on pense ce genre de technologie. Oublions le bout on ça développe les pouvoir paranormaux ;-)
Pour ceux qui veulent se procurer le kit de développement même seulement pour essayer le jeux et autres applications ( il y a des visionneuse d'image et de film 3D déjà ) qui seront développés d'ici à ce qu'une version finale soit disponible, bien il est possible de le pré-commander sur le site d'Oculus pour 300$ US. C'est difficile de donner une idée de ce que cette technologie permet de faire à moins de l'essayer soit-même. Mais sincèrement, attendez un peu, il y a encore pas mal de travail à faire avant que ce soit prêt pour monsieur et madame tout le monde. Possible aussi que d'autres joueurs comme SONY ou Vuzix décident d'y aller de l'avant avec leur propre casque qui supplantera le Rift à sa sortie. Ce n'est peut-être pas le Rift qui sera le vainqueur de la commercialisation de la réalité virtuelle mais c'est lui qui sera à l'origine de l'adoption de la réalité virtuelle par les développeurs.
Tellement de projets en cours. Tellement d'équipements qui dorment chez-moi. Tellement de jeux vidéo même pas essayés. Me semble que je devrais avoir mes soirées bien remplies. Finalement non, ça fait quelques jours que le cerveau est en sauce blanche. En même temps, je pourrais bien faire deux ou trois trucs ne nécessitant peu sinon aucune matière grise. Mais non, je perd mes soirées devant l'ordi à browser le web ou même jouer à Minecraft.
Il y a madame insomnie qui semble s'être installée chez-moi et ne semble pas pressée de repartir. Malheureusement, je suis juste assez fatigué pour ne pas être capable de me concentrer convenablement pour travailler sur un projet mais évidemment pas assez pour m'endormir.
Je me botte le derrière juste après avoir écrit ce post et vais faire un peu de peinture dans la salle de jeux de monstres. Quoi qu'il y avait un article pas vraiment intéressant mais que ...
J'essais de continuer à ajouter à chaque jours quelque chose sur la carte de Rimouski pour OpenStreetMap. Cependant, ça devient de plus en plus difficile. Ce qui est évident est fait ( ou à peu près ) et j'aimerais ajouter autre chose que les restaurants ou magasins. Je me suis dit, avec mon Nexus S, c'est sûrement possible de l'utiliser en tant que GPS et de modifier et d'ajouter directement sur le téléphone les informations. La réponse est oui. Il y a quelques applications permettant d'éditer le contenu d'OpenStreetMap directement sur le téléphone. Mais oh que c'est chiant. Premièrement, par une belle journée ensoleillée, on ne voit strictement rien sur l'écran, donc on repassera pour l'édition sur place. Et lorsque que j'ai essayé en soirée, c'est tellement pas convivial que je n'ai même pas réussi à ajouter un arrêt d'autobus. J'avoue, je n'ai essayé que Vespucci mais ça semble être l'application la plus complète.
Tout ça pour dire que sans photo aérienne de disponible dans les layers offerte par OpenStreetMap et avec un téléphone GPS qui n'est pas trop coopératif, possible que les updates attende un peu que je me décide à faire quelque track GPS pour définir les piste cyclable et chemin piéton.
Oui, c'est assez courant chez moi, je fais de l'insomnie. Cette fois, j'ai juste assez le cerveau en état pour ajouter les easter eggs dans ma carte du monde. Alors je me suis défini un classeur sous Google Drive ayant les colonnes suivantes:
Ça me permet de mettre en coordonnées géographique des icône pris à la position offsetx et offsety et de taille width et height dans un fichier .png contenant les easter eggs. Et si texte contient quelque chose, c'est écrit sous l'image. Pour le moment, le fichier contient:
Il y a donc un petit Link qui se promène en Amérique latine, un petite mario au Groenland, un airship dans l'océan Atlantique et une tour blanche au nord du Nigéria. Ceci dit, je me demande toujours quel image icônique des jeux vidéo sur console 16 bits ajouter sur ma carte. N'hésitez-pas à me laisser vos idées en commentaire.
J'aime bien l'idée du e-government ( ou administration électronique en bon français ) et j'espère jeter un oeil sur Open311 bientôt, mais si on ne peut pas bien représenter certaine données géographiquement, certains service sont moins efficace, surtout pour un visuel comme moi. Alors que google map à un bon API pour afficher du contenu, il est assez difficile d'aller en retirer de l'information. Il y a cependant OpenStreetMap qui lui permet non seulement d'aller lire l'intégralité des données du serveur mais permet aussi aux usagers de mettre à jour l'information. Un wikipedia de la géomatique finalement. Malheureusement, l'information qu'on y trouve pour la région provient de datasets publiques assez générique et dont bien des informations sont manquantes.
Comme j'ai un projet en tête qui pourrait justement utiliser l'information vectoriel de la région, il serait préférable d'avoir le plus d'information possible et non seulement les rues et quelques "generic building" éparpillés sur le territoire. Alors ce sera ma bonne action de e-citoyen que de mettre à jour un petit quelque chose sur OSM à chaque jour.Pour le moment j'utilise l'outil directement lié par le site d'OSM, soit Potlatch 2, je pense essayer JOSM pour le long run. Je ne sais pas si je serai assez crinqué pour me taper tous les bancs de parc, poubelles et téléphones publiques, mais je dois au minimum ajouter les pistes cyclables et des petits immeubles manquants comme, bien, le CÉGEP !
J'ai pas travaillé beaucoup sur ma carte style RPG mais j'ai tout de même commencé à gérer les contours et les transitions. J'ai aussi implémenté un minimum pour conserver plus d'information sur la tuile courante que sur les tuiles adjacentes. C'est vraiment pas au point mais c'est un début.
Ça permet aussi de voir qu'il y a beaucoup trop de ville dans le nord de l'Europe. Je vais devoir en flusher quelques unes. J'ai commencer un petit quelque chose pour donner un ligne d'élévation au 1000 mètres mais je vais devoir travailler ça au niveau des sous-tuile pour arriver à un résultat potable.
Pour le moment aussi, il n'y pas de répétition de séquence de tuile, donc toujours le même sprite de forêt ou de montagne. Ceci dit, c'est pas facile de reconnaître l'Europe, le nord de l'Afrique ou encore l'Asie de l'est là-dessus. Mais ça avance, c'est ce qui compte.
Il y a un manque chronique de décoration dans mon salon. J'ai pensé faire de fausses fenêtres donnant sur l'extérieur recréer à l'aide de Minecraft mais j'ai démissionné en voyant la tâche de recréer la vue, même en mode créatif. Alors quoi faire?
J'ai un trip pixel art c'est temps-ci et j'aimerais bien avoir quelque chose de moindrement éducatif pour mes petits monstres. Out of nowhere, l'idée de faire une carte du monde dans un style RPG de console 16 bits ( à la SNES ) m'est apparue et elle m'a plu Comme il y bien de l'espace à couvrir, le but est d'imprimer le tout sur quelque chose d'environs 7 pieds de large. C'est en devenir mais ça avance bien. Je n'ai aucunement l'intention de faire cette carte à l'aide d'un logiciel de dessin mais d'écrire un un programme en C# qui utilise des datasets pour générer une carte du monde réaliste, bien que fortement stylisée.
C'est un projet qui va sûrement me prendre encore pas mal de temps mais c'est tout de même quelque chose qui avance rapidement et dont les petits changements sont tout de même visibles.
Oui, j'ai essayé de programmer un CRM, un engin de blog en PHP. Mais comme le nom de domaine de mon ancien site le disait si bien, notimetocode, j'ai effectivement pas le temps de coder ça. Alors j'ai décidé de prendre un engin existant et l'apprendre, le configurer, le mettre à ma main. Mais là aussi, pas le temps de me taper ça. Alors de retour sur le bon vieux blogger afin de mettre mes niaiseries sur le web et sauver quelque $ en ne payant plus de hosting pour rien.
C'est donc ici que je vais poster l'avancement de mes projets et autres pensés, analyses et bulles au cerveau que j'aurai.
