Discussion :

[Franck.H]

Voici le premier tutoriel d'une série qui va vous permettre de démarrer le développement de jeux avec MonoGame.

http://franckh.developpez.com/tutori...nogame/part-I/

Vous pouvez laisser vos remarques et autres messages à la suite !

[CHbox]

Je n'ai pas lu en détail mais ce premier tuto a déjà l'air conséquent et donne les premiers pas de la 2D, très bonne initiative je suis impatient de voir jusqu'où il ira J'espère que quelques tutos 3D seront présentées.

Petite question justement, perso j'ai commencé à faire du XNA 4 depuis quelques semaines, j'ai quelques projets tutos et tests, la migration vers Monogame est-elle immédiate ou bien y'a-t-il tout de même quelques adaptations à apporter au projet? A priori puisque Monogame embarque carrément le framework XNA 4.0 le code en lui-même ne devrait pas changer mais la structure du projet nécessite peut-être des modifications? Je constate par exemple qu'au lieu d'avoir un projet spécifique Content, Monogame semble se contenter d'un dossier dans le projet.

[LittleWhite]

La migration est décrite ici : http://jeux.developpez.com/tutoriels...ransition-XNA/

Généralement, elle est immédiate.

[CHbox]

La migration est décrite ici : http://jeux.developpez.com/tutoriels...ransition-XNA/

Généralement, elle est immédiate.

de ta réponse, ce tuto m'avait échappé

[I_Pnose]

Bonne initiative ^^

Par contre je ne saisis pas l'utilité de réaffecter la taille de la fenêtre à chaque tour de boucle.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
graphics.PreferredBackBufferWidth = WINDOW_WIDTH;
graphics.PreferredBackBufferHeight = WINDOW_HEIGHT;

Si les lignes ci-dessus sont dans le constructeur, il n'y a aucun intérêt à les réaffecter (sinon pour modifier la taille de l'écran ponctuellement -dans un hypothétique menu d'option par exemple).

Après, en dehors des méthodes et événements, j'ai un peu de mal avec les membres publics ; afin de respecter l'encapsulation, et donc avoir une certaine cohérence dans le code, il est recommandé d'opter pour les propriétés (avec une visibilité adaptée sur le set et le get) en lieu et place d'un simple champ public.

Sur ce, bonne continuation.

[Franck.H]

Par contre je ne saisis pas l'utilité de réaffecter la taille de la fenêtre à chaque tour de boucle.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
graphics.PreferredBackBufferWidth = WINDOW_WIDTH;
graphics.PreferredBackBufferHeight = WINDOW_HEIGHT;

Si les lignes ci-dessus sont dans le constructeur, il n'y a aucun intérêt à les réaffecter (sinon pour modifier la taille de l'écran ponctuellement -dans un hypothétique menu d'option par exemple).

Oui effectivement, ce n'est pas totalement nécessaire, uniquement comme tu le dis, dans le cas d'un redimensionnement de la surface ce qui en effet rarement le cas. J'ai appris comme cela j'ai donc fait comme ça

Après, en dehors des méthodes et événements, j'ai un peu de mal avec les membres publics ; afin de respecter l'encapsulation, et donc avoir une certaine cohérence dans le code, il est recommandé d'opter pour les propriétés (avec une visibilité adaptée sur le set et le get) en lieu et place d'un simple champ public.

Je ne suis pas totalement à l'aise avec les langages modernes, objets et de haut niveau d'abstraction comme C# ou autres. Ma préférence restant le C (j'utilise souvent quelques concepts objets tout de même avec ce langage), j'ai un esprit plus procédural qu'objet


pour les commentaires, j'adapterais plus tard lorsque j'aurais fini les autres tutoriels de prévu. Merci également à CHbox