Migration du blog et XNA : Frogger - Sources et ressources

Bien, après plusieurs mois d’utilisation de ma propre plateforme de blog hébergée sur mon serveur perso, j’ai décidé de changer de plateforme pour me diriger vers la communauté de blog Codes-Sources.

Codes-Sources nouveau blog de Nicolas Boonaert aperçu

Le nouveau blog est disponible à travers ce lien.
Mettez donc à jour vos flux RSS et vos bookmarks !

Cependant, ce blog restera en ligne encore pendant un bon moment.

 

XNA Header Frogger

Pour terminer la série de posts concernant XNA autour du jeu Frogger, je mets à disposition comme convenu mes sources ainsi que les ressources qui m’ont permis de mettre en oeuvre ce jeu que vous pouvez essayer dès à présent.

Quelques indications pour vous aider :

  • Les touches : Joueur 1 : touches directionnelles; Joueur 2 : QSDZ
  • En cas de mort : Lorsque dans le jeu, votre grenouille se fait tuer, elle se positionne au point de départ et le jeu attend que vous appuyez sur la touche Entrée.
  • Pour quitter le jeu : Appuyer sur la touche Echap. et sélectionner l’option Quit du menu.

Quelles sont les prérequis pour lancer ce jeu :

  • Système : Windows XP SP2 ou Vista
  • Framework XNA 2.0 installé et les prérequis de XNA

Cette version est développée à l’aide de Visual Studio C# Express 2005, qui est requis pour ouvrir la solution. Elle ne propose pas d’animation avancée ni de gestion sonore et réseau, elle peut cependant les accueillir sans souci. N’hésitez pas à me faire un retour sur le jeu dans son état ou si vous le continuez !

Retrouvez une analyse plus complète de ce travail, réalisée à travers ce document.

Sur ce… A bientôt sur le nouveau blog ! Et bon dev’ !

 

UPDATE :
J’ai pu recevoir d’autres versions du projet réalisées par d’autres étudiants, voici une liste de ceux que j’ai trouvé sympa :

Virtual Earth : la version 6.1 est live !

La nouvelle version 6.1 de Virtual Earth vient d’être lancée, on est encore loin des nouveautés présentés lors du Mix08 par Chris Pendleton ou celles dont je rêve un peu (mais pas si "rêve" que ça, hein :)), mais on retrouve de nombreuses nouveautés qui seront très utiles et apporteront vraiment une plus value à vos sites et applications web.

Virtual Earth v6.1 Header

Les nouveautés de la version 6.1 en résumé :
La mise à jour de Virtual Earth se traduit à travers plusieurs nouveautés, Microsoft a même mis à jour le site officiel de Virtual Earth, le rendant un peu plus animé et sympa.

Je reviendrai sur ces nouveautés plus en détails et à travers des exemples de mise en oeuvre, ici je vais simplement les énumérer :

  • Un mode 3d plus réaliste :
    Les modèles sont plus précis, les textures également, et on retrouve maintenant la végétation au sein de ce mode.
  • Un nouveau style de carte :
    Le style de vue oblique (Bird’s eye view) présente la possibilité d’être affiché en style Hybride afin de voir les noms et tracés des rues en superposition des photographies.
  • Les calculs d’itinéraires améliorés :
    Il est maintenant possible de calculer des itinéraires piétons ainsi que des itinéraires qui prennent en compte le trafic routier
  • Une internationalisation améliorée :
    Le dashboard par défaut est maintenant déclinable en différentes langues. Il en va de même pour le calcul d’itinéraire simple de Virtual Earth (différent du MapPoint WS).
  • Une plateforme améliorée :
    Un support officiel et amélioré de Safari 2.0 mais également de la version 3.0, une amélioration pour l’impression des cartes.

Une mise à jour mineure qui apporte tout de même son lot de nouveautés réellement utiles, surtout pour nous qui ne sommes pas anglophones. Vous pouvez retrouver ces nouveautés résumées et en images via le blog de Steve Lombardi, celui de Chris Pendleton ou de Johannes Kebeck.

En attendant la version 7, on a à nouveau de quoi améliorer et consolider des existants tout en fournissant davantage de services aux utilisateurs finaux.

Une couverture améliorée en France :
D’autant plus qu’en termes de contenu, Arnaud qui nous avait promis quelque chose de "gros" ne nous avait pas menti : les Français seront gâtés dans les mois à venir grâce à un partenariat exceptionnel avec l’IGN (Institut Géographique National) afin d’obtenir une résolution correcte sur l’ensemble du territoire et plus importante suivant les zones, retrouvez le communiqué officiel par ici.

Tout cela s’ajoutant bien entendu aux nombreuses villes déjà disponibles en vue oblique ou en vue haute résolution (ortho view), cela comble ainsi une demande importante des utilisateurs français qui étaient souvent déçus par la couverture sur notre territoire.

En bref, et pour ne pas jouer l’originalité mais quand même :p, ‘Well done Arnaud!’ pour ce nouveau partenariat mais aussi pour ceux à venir :) !

A venir :
Bien entendu je ne manquerai pas de présenter plus en détails toutes ces nouveautés et bien d’autres en abordant toutes les modifications que cela apporte et des exemples d’application.

D’ici peu nous allons également mettre à jour l’IntelliSense Helper pour VS2008 afin de la faire coller à cette dernière version 6.1 de l’API Virtual Earth, je communiquerai bientôt plein d’infos et exemples.

Virtual Earth : Quelques nouveautés expliquées [partie 5] - Géométrie et niveau de zoom

A travers ce court billet, nous allons voir comment éviter un phénomène dérangeant lorsqu’on ajoute des géométries au MapControl.

Virtual Earth Header

Que se passe-t-il ?
Lorsque l’on établir une géométrie (VEPolyline ou VEPolygon) avec des points relativement proches, et lorsqu’on zoom en arrière (”dezoom” si on veut :)), on peut observer un comportement gênant visuellement qui vient du fait que le MapControl tente de simplifier la forme en fusionnant les points géométriques les plus proches.

Comment l’éviter ?
Pour ne plus observer ce souci, il suffit d’utiliser la ligne suivante, dans votre code d’initialisation par exemple :

map.EnableShapeDisplayThreshold(false);

Voilà le résultat avec et sans l’option :
Virtual Earth Geometry vemap.EnableShapeDisplayThreshold(false) avec simplification (cercle transformé en carré) et non

Virtual Earth : Quelques nouveautés expliquées [partie 4] - Itinéraires et feuille de route

Depuis la mise à jour mineure de la version 6 de l’API Virtual Earth, on peut utiliser le web service MapPoint (MWS) ce qui nous permet d’avoir des itinéraires avec des indications dans différentes langues.

Virtual Earth Header

Ainsi à travers cet article nous allons simplement voir comment interroger le web service MapPoint à travers Virtual Earth ainsi que comment obtenir et exploiter les itinéraires et indications routières internationalisées.

Comment ça fonctionne ?
Voici un petit schéma qui reprend le principe de fonctionnement :
Virtual Earth MapPoint Web Service

Ainsi, on observe plusieurs étapes :

  • Etape 1 : Le client (via son navigateur web) exécute une requête vers notre serveur web afin de récupérer la page HTML et les fichiers de ressources (JavaScript et/ou CSS).
  • Etape 2 : La page HTML est rendu au sein du navigateur, les événements JavaScript de chargement sont déclenchés, c’est dans un de ceux là que l’on instancie le MapControl, on interroge alors en AJAX les serveurs de Virtual Earth afin d’obtenir les fichiers de ressources ainsi que les données (tiles). Enfin le MapControl est initialisé et l’événement correspondant est déclenché.
  • Etape 3 : L’événement d’initialisation du MapControl est déclenché, on y fait appel à la méthode GetDirections() de la classe VEMap en y passant plusieurs points de passage en paramètre, ainsi que des options que nous étudierons par la suite. Le web service MapPoint est appelé puisqu’on l’indique explicitement dans les options d’appel à la méthode. Au retour de ces informations, la méthode de callback est déclenchée ce qui nous permet d’initialiser la feuille de route.

Et en détails ?
Afin de gérer plus simplement l’appel au calcul d’itinéraire, je créé une méthode drawRoute() qui sera appelée dans n’importe quel événement à partir du moment que certaines variables définissant les points de passage soient initialisées.

Voici le code de cette méthode drawRoute() :

118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
function drawRoute() 
{	
  map.Clear();
  var locations = new Array();
  locations.push(latLongPointStart);	
  for(var i in checkPoints)
  {
    locations.push(checkPoints[i]);
  }
  locations.push(latLongPointStop);
 
  latLongPointStart = null;
  checkPoints = new Array();
  latLongPointStop = null;
 
  var options = new VERouteOptions;	
  options.DrawRoute = true; // The route is drawn on the map
  options.ShowDisambiguation = true; // Show the disambiguation dialog
  options.SetBestMapView = true; // The map change to the show the route	
  options.RouteCallback = onGetRoute;  // Call this function when map route is determined:	
  options.DistanceUnit = VERouteDistanceUnit.Kilometer; // Show as kilometers
  options.UseMWS = true; // The MapPoint Web Service is used to find 
                                   //the route (must be true if we want localization)	
 
  map.GetDirections(locations, options);
}

Mais que fais au juste cette méthode.

La première partie concerne le traitement de mes variables contenant les coordonnées, celles-ci peuvent être initialisées dans la méthode GetMap() d’initialisation comme elles peuvent l’être dans tous types d’événements.
Dans ce mini-projet d’exemple, en l’occurrence elles sont utilisées au sein d’événements liés à la souris.

La seconde partie bien plus intéressante pour nous concerne l’appel à la méthode GetDirections() de la classe VEMap de l’API Virtual Earth v6.
On peut voir tout d’abord que je choisis d’initialiser un objet de type VERouteOptions.
Cet objet comporte plusieurs propriétés :

  • DrawRoute : indique si l’on souhaite tracer la route automatiquement lorsqu’elle est renvoyée par le serveur de calcul d’itinéraire
  • ShowDisambiguation : en cas d’ambigüité sur un nom ou sur un itinéraire à suivre, nous renvoie une fenêtre d’aide nous indiquant les différents choix
  • SetBestMapView : indique si l’on souhaite positionner la carte de manière à couvrir l’itinéraire complet une fois celui-ci renvoyé
  • RouteCallback : indique la méthode qui sera déclenché une fois l’itinéraire renvoyé par leur serveur, dans notre cas il s’agit d’une méthode que nous verrons par la suite
  • DistanceUnit : spécifie l’unité de distance pour l’itinéraire. Il s’agit d’une valeur de l’énumération VERouteDistanceUnit. Attention à ne pas se tromper sur cette valeur !
  • UseMWS : indique explicitement que l’on souhaite utiliser le web service MapPoint. Ce paramètre doit être à vrai pour obtenir l’internationalisation. Celle-ci sera spécifiée dans un paramètre d’url à la référence vers le script VE

Les différentes options paramétrées, on remarque l’association de l’événement de callback à une méthode qui sera déclenchée une fois l’itinéraire renvoyé.

Voici le code de cette méthode onGetRoute() :

145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
function onGetRoute(route) 
{
  document.getElementById("myVE_Information").innerHTML = "<b>Distance totale : " + route.Distance.toString().substring(0,6) + " km";
  document.getElementById("myVE_Information").innerHTML += "</b><br />";
 
  for(var indexRoute in route.RouteLegs)
  {
    for(var index in route.RouteLegs[indexRoute].Itinerary.Items)
    {
      var sInfoTemp;
      sInfoTemp = ">> " + route.RouteLegs[indexRoute].Itinerary.Items[index].Text;
      sInfoTemp += " - Dist : " + route.RouteLegs[indexRoute].Itinerary.Items[index].Distance.toString().substring(0,6) + " km";
 
      document.getElementById("myVE_Information").innerHTML += sInfoTemp + "<br />";
    }	
    document.getElementById("myVE_Information").innerHTML += "================ Point intermediaire " + indexRoute + " ================<br />";
  }
}

On remarque dès lors que cette méthode récupère un paramètre route (parmi d’autres disponibles) qui nous permet d’accéder à des informations sur l’itinéraire fraichement calculé et renvoyé.

On itère sur l’ensemble des RouteLegs renvoyés (tableau de VERouteLeg), pour simplifier la chose, chaque segment de route entre deux points indiqués par l’utilisateur est un objet RouteLegs de la route. On peut donc véritablement qualifier ça de segment de route.

On itère ensuite sur les éléments d’informations de l’itinéraire associé à chaque segment en parcourant les éléments Itinerary.Items des segments de cet itinéraire (tableau de VERouteItineraryItem contenu dans un élément de type VERouteItineraryItem).
Cela permet ainsi d’obtenir les indications telles celles d’un GPS : “TOURNER à GAUCHE sur telle rue”.
Il est également possible de récupérer d’autres informations sur chacun de ces éléments d’informations de l’itinéraire, comme par exemple la distance à parcourir jusqu’à la prochaine indication à suivre.

On peut récupérer différentes informations depuis ces VERouteItineraryItem à travers les différentes propriétés :

  • Distance : la distance associée
  • LatLong : la position de la punaise où se trouve l’indication
  • Shape : la punaise associée à l’indication
  • Text : la description textuelle de l’étape
  • Time : le temps estimé de parcours

Voici le résultat observé :
MapPoint Virtual Earth Feuille de route

Ici ces informations sont renvoyées dans une simple cellule DIV mais on pourrait très bien, sans gros efforts, obtenir une information comme sur Mappy ou bien d’autres services de calcul d’itinéraire dédiés avec des images sympathiques, une mise en forme moins brute et surtout une information plus complète (Distance intermédiaire et durée estimé…).

Et à propos de l’internationalisation ?
Au moment de la référence vers le script VE, il suffit d’ajouter le paramètre mkt comme suit :

  http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6&mkt=fr-fr

Les langues et cultures supportées sont les suivantes :
en-ca, en-gb, en-us, cs-cz, da-dk, nl-nl, fi-fi, fr-fr, de-de, it-it, nb-no, pt-pt, es-es, et sv-se.
Bien sûr comme indiqué dans le code, l’option UseMWS lors de l’appel à la méthode GetDirections() est également indispensable pour avoir l’information internationalisée.

Avantages et inconvénients :
Grâce à cette solution, il est possible de fournir un service supplémentaire à vos clients sans pour autant avoir à modifier ou complexifier votre partie serveur. Comme on peut le voir, ce traitement est purement navigateur, la page présente sur le serveur web est une page statique. Les appels AJAX au web service MapPoint sont gérés à travers l’appel à la méthode GetDirections() de la classe VEMap.

Attention toutefois, vous êtes limités à un certains nombre de requêtes par jour au service Virtual Earth (50 000 transactions en 24h maxi), et cette limite peut très rapidement être atteinte, mais dans tous les cas, Virtual Earth propose des licences d’utilisation qui peuvent être étudiées plus en détail à travers la présentation de Arnaud Gstach qu’il faut contacter pour ce genre d’information.
Ici 1 appel à la méthode GetDirections() = 1 transaction.

Je vous laisse imaginer toutes les applications que l’on peut trouver à cette fonctionnalité de calcul d’itinéraire et surtout quel gain pour l’utilisateur final de votre site.

En attendant et comme à chaque fois, le code source complet de cet exemple est téléchargeable via ce lien ainsi que la version de test ici.

La prochain billet de la série sur Virtual Earth concernera une nouveauté très peu connue qui pourra résoudre quelques soucis visuels…


Valid XHTML 1.0 Transitional Valid CSS!