Bonjour,

Je développe un jeu sous XNA, et au fur et à mesure que je rajoute des ressources au projet, le lancement du jeu est de plus en plus long à cause de la méthode LoadContent qui charge tout ce qui est nécessaire.

Y a-t-il un moyen d'optimiser ce temps de chargement ?

Je connais pas XNA, mais généralement si le temps de chargement est long c'est souvent à cause des musiques.
Pour résoudre ce problème, il faut les streamer à leur lancement
Certains gros jeux streament les textures aussi

Ouais le stream aurait pu être une possibilité, mais XNA fourni déjà une méthode qui Load direct les ressources, donc je vois pas comment faire pour streamer ...

Il y a un pattern très simple à mettre en oeuvre d'un point de vue conception : le lazy load : le but est de plutôt que de charger une ressource au démarrage, de ne la charger qu'au moment où tu en a vraiment besoin. En gros, tes méthodes utilisant tes ressources vont taper un pool de ressources qui ne seront chargées que lorsqu'elles seront réclamées. Alors, oui, ça demande un peu plus de travail que "Vas-y, charge tout, y'a de la RAM coco !". Mais ça sera rapidement la seule solution viable si tu veux faire un jeu non découpé en niveaux/zones.

Raspberry-Pi Et charger le strict minimum au lancement, puis tout charger quand on quitte le menu principal, c'est viable ?

Tout dépend de la quantité d'infos. Si tu veux faire un RPG où tu explores un monde entier, clairement, non. Si tu réalises un shoot où tu n'as qu'une dizaine de vaisseaux et de textures, oui.
Après, tu peux imaginer charger des éléments en basse définition puis de streamer au fil de la proximité du joueur des modèles/textures de meilleure qualité. Voir de faire du LOD : c'est fait pour ça.
L'autre question à te poser est : est-ce que tous mes éléments peuvent être affichés en même temps, sur un même écran dès le démarrage ?

raspberry a deja un peu dit ca, mais une solution completement lazy, c'est a dire qui ne charge l'information qu'a la frame ou elle devient necesasire va introduire des ralentissements horrible. Je suis entrain d'ecrire un shoot them up decoupe en niveau et je ne charge que les donnee qui sont utile pour le niveau qui est lance. Ca fait un petit chargement au debut, mais rien de ridiculement long. Et il n'y a pas de ralentissement pendant le jeu (puisque tous, ou quasiment tout est deja en memoire)

godrik Le découpage par niveaux, c'est en grande partie à cause de ça (RAM, CPU limités) que ça existe :D
Je suis d'accord pour le lazy, pas pour chaque élément à moins de pouvoir le mettre dans un thread (Mais un thread qui charge ce qu'il peut au fil de l'eau, c'est du streaming . Un truc typique en lazy, ça va être le contenu d'un inventaire de coffre ou autre. Un niveau, c'est justement un exemple de lazy load. Le niveau 2 n'est chargé que lorsqu'il est atteint

C'est vrai que quand on y pense, c'est un peu con de tout charger d'un coup quand y a la possibilité de charger par petit morceau à différent moments ...

J'avais écrit ça pour un petit shoot-em-up en C# XNA:
http://pastebin.com/7pjiS1SF

Et je l'instanciais comme ça dans Initialize pour Texture2D par exemple:
new Misc.Unique<string, Texture2D>(s => Content.Load<Texture2D>(s));

Ca rejoint le lazy load de Rasperry-Pi. Mais ça dispose pas les ressources non utilisés donc si ton jeu utilise beaucoup de ressources c'est pas le top.

hyrulink2 Tu peux assez facilement mettre en place de l'aging si tu veux décharger des resources sans savoir si tu t'en sers encore vu que tu as déjà du lazy load : si la ressource dégagée revient, elle sera rechargée. Mais oui, l'idéal est quand même de savoir quelles sont les ressources que tu utilises aux alentours de t.

Raspberry-Pi, dans la premiere version de monshmup, je chargait les sprite quand ils etait affiche la premiere fois. donc a chaque fois qu'un nouvel enemi entrait en scene, je perdais des frames... En effet, je devrais streamer avec un thread a part, mais pour l'instant ca se passe bien, donc je fais avec

Raspberry-Pi En fait j'avais envisagé de maintenir en parallèle une file de priorité avec vieillissement des éléments non utilisés et retrait des trop vieux si besoin mais pour le peu de ressources ça en valait pas la peine.