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

[moldavi]

Bonjour.

Juste pour dire que je trouve ce tutorial très sympa.

J'ai hâte de voir la gestion des collisions dans le tutorial 2.

Pour faire mon relou, le seul truc qui m'a frappé :

Code :

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

1
2
3
 
public const int WINDOW_WIDTH = 224;
public const int WINDOW_HEIGHT = 248;

Je suis de la vieille école. Les textures, c'est 16/32/64/128/256/512/1024/etc...

Les cartes graphiques, elles adorent, et sont optimisées pour ces valeurs. Il y a quelques articles sur internet qui expliquent la chose (l'alignement de données et les optimisations pour des tailles puissance de 2 dans le GPU).

Les infographistes qui travaillent avec moi me haïssent pour ça... Bon ok j'exagère un peu...

PS: tu as le droit de me dire que pour une taille aussi de faible de texture on s'en fout. Je te répondrai, fait du 4k et on en reparle.

PS2: pour les puissances de 2 je parle du BackBuffer...

[I_Pnose]

Bonjour.
Pour faire mon relou, le seul truc qui m'a frappé :

Code :

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

1
2
3
 
public const int WINDOW_WIDTH = 224;
public const int WINDOW_HEIGHT = 248;

Je suis de la vieille école. Les textures, c'est 16/32/64/128/256/512/1024/etc...
[...]
PS2: pour les puissances de 2 je parle du BackBuffer...

Là en l’occurrence, j’ai la vague impression qu’on nous abstraie l’initialisation du BackBuffer car, d’une part, lorsqu’on affecte des valeurs aux propriétés PreferredBackBufferWidth et PreferredBackBufferHeight, c’est la taille de la fenêtre qu’on affecte (et du Viewport associé), et d’autre part, si on ne touche pas à ces propriétés, les valeurs par défauts sont 800x480 (on est loin des puissances de deux ^^ ). Je pense que le système choisis un BackBuffer qui colle au mieux à la taille du Viewport lié à la fenêtre.

Dans le même ordre d’idée, le ContentProcessor lié au chargement des textures sous XNA converti automatiquement les textures en puissance de deux (un mécanisme qu’on peut désactiver uniquement si on cible des cartes compatibles DirectX10 et supérieur, via un profil spécifique).

[moldavi]

Bonjour.

Là en l’occurrence, j’ai la vague impression qu’on nous abstraie l’initialisation du BackBuffer car, d’une part, lorsqu’on affecte des valeurs aux propriétés PreferredBackBufferWidth et PreferredBackBufferHeight, c’est la taille de la fenêtre qu’on affecte

Effectivement, j'avais oublié qu'il y a un Framework derrière qui gère la chose.

Et en effet, PreferredBackBufferWidth, cela sous entends certainement que le Framework adpate le buffer d'une manière optimale.

[Mic512]

Bonjour,

Merci pour cet ensemble de tutoriels ! Bien que je n'ai encore que survoler ces derniers afin de voir ce qu'il était possible de faire, une question me vient tout de suite à l'esprit :
Vous commencez par créer un "Windows Project", cela signifie que le jeu en question ne fonctionnera que sous Windows, ou bien il sera portable sur iOS, Android, Linux, etc... également ?
J'espère que ce n'est pas une question redondante !
Auquel cas, comment est géré le "transfert" vers une autre plateforme ? Si par exemple je veux compiler et exécuter mon application sur un smartphone Android, comment dois-je m'y prendre ?

[Vetea]

Bonjour Frank,

Excellent petit tuto que j'ai parcouru avec attention.
J'ai presque tout compris pour dire !
Ce qui me gêne c'est cette synthaxe à la C, mais cela n'engage que moi et je ne suis guère un modèle dans ce deomaine là !
J'ai beaucoup entendu parler du C# et de son emploi étendu dans le domaine du jeu et j'avoue y avoir touché un peu quand j'ai voulu découvrir Unity mais cette synthaxe ... Arg, je peux pas !
Malgré tout un tuto réussi donne envie de se lancer dans une techno complétement étrangère à ce que l'on a l'habitude d'utiliser, et c'est le cas du tien.
J'ai une question sur la portabilité, la diffusion d'un projet sur ce support : Quels sont les OS et plateformes supportées ? Pour diffuser un jeu, faut il passer par un setup à configurer, ou bien tout est inclu avec les .DLL ainsi que l'exe ?
Merci et meilleurs voeux !

[Franck.H]

et merci

Les supports principaux sont: iOS, Android, Mac OS X, Linux, Windows, Windows 8 Store, Windows Phone 8 et xBox. Sûrement d'autres ou à venir. Sinon pour ce qui est du portage d'une plateforme à une autre, il y a des chances que dans certains cas, la compilation sur la cible soit nécessaire mais c'est une chose que je n'ai pas testé.

C'est vrai que la syntaxe C/C++ n'enchante pas tout le monde et il y a autant de façon de coder que de codeurs, si comme moi, tu met un point d'honneur sur la propreté du code... Moi ça fait 6 ou 7 ans que je programme en C donc aucun problème. Après je suis moins à l'aise avec l'objet

[I_Pnose]

J'ai presque tout compris pour dire !
Ce qui me gêne c'est cette synthaxe à la C, mais cela n'engage que moi et je ne suis guère un modèle dans ce deomaine là !

C’est vrai que par défaut, lorsque tu installes le package Monogame, seuls les templates C# sont disponibles dans l’assistant de création de projet. Mais absolument rien ne t’empêche d’utiliser Vb.net (je pense qu’en zieutant sur le forum officiel de Monogame tu devrais trouver des gens qui ont traduit les différents templates en Vb.net).

Après, de Vb6 à Vb.Net il n’y a qu’une toute petite marche à gravir, et cette dernière se situe surtout au niveau de l’IDE (car il est tout à fait possible de coder à la manière de Vb6 en Vb.net... si on n’a vraiment pas envie de sortir des sentiers battus du procédural).

Reste à voir s’il est possible de trouver des tutos Mnogame écrits en Vb.net, qui sait (dans tous les cas tu trouveras des tutos XNA écrits en Vb.Net, or la syntaxe Monogame et identique à celle d'XNA).

[Vetea]

Bonsoir à vous et merci pour vos informations claires et concises.
Depuis ce week end, j'ai entrepris une formation sérieuse au C++, rien à voir avec le sujet si ce n'est le 1er mot !
A bientôt !

[I_Pnose]

Depuis ce week end, j'ai entrepris une formation sérieuse au C++, rien à voir avec le sujet si ce n'est le 1er mot !

Ah oui, carrément. J’espère que ça ne va pas t’écœurer définitivement ; en terme d’abstraction, il y a une marche entre le Basic et le C#, mais il y en a une autre entre le C# et le C++ selon moi (qui se situe davantage au niveau de la verbosité et du trop grand nombre d'approches possibles).

Bref, bon courage.