Loading thread et SpriteBatch.Draw

Bonjour, j'utilise un thread pour charger le content de la scene.

Le soucis c'est que une fois sur 50 SpriteBatch.End() plante avec une invalid operation exception.
Mais ce qui m'enerve le plus c'est que le thread qui load le content est dans un etat de sleep a ce moment (car il y a un content manager locked)

En gros j'ai le main thread qui draw et qui plante sur le sb.end() et le loading thread qui est dans un etat de sleep...

Avez vous deja eu a faire a ce genre de probleme.
Quelle est la bonne maniere pour debugger cela.

Merci.

Cette technique a toujours fonctionné pour moi :
http://blogs.msdn.com/b/shawnhar/arc...nimations.aspx

Salut, en faite tu draw l'animation de loading dans le thread de loading ensuite tu appelles Present pour display?

Car moi je draw le loading depuis le main thread.

Merci

Disons qu'en fait le loading se passe dans le thread principale et l'affichage dans un autre thread.

merci je vais tester cela meme si je crois que ca ne va pas changer grand chose...
j'essaie de vous tenir au courant lorsque je patche.

effectivement passer le chargement sur le thread principal c'est bien plus rapide.

Sur pc je passe de 4 secondes a environ 0.75 seconde.
(Bon sur pc, la xbox ca reste long...)

Sinon question perf:
- pour le draw call, on a un systeme de layer avec chaque layer un scroll speed different. Mais pour chaque layer on a un Sb.begin()/End() different.
Du coup avec 9 layer je suppose qu'on perd beaucoup en perf?(si vous avez des retours d'experiences sur ce point.)

Merci.

Citation:

---

Envoyé par saturn1

effectivement passer le chargement sur le thread principal c'est bien plus rapide.

Sur pc je passe de 4 secondes a environ 0.75 seconde.
(Bon sur pc, la xbox ca reste long...)

Sinon question perf:
- pour le draw call, on a un systeme de layer avec chaque layer un scroll speed different. Mais pour chaque layer on a un Sb.begin()/End() different.
Du coup avec 9 layer je suppose qu'on perd beaucoup en perf?(si vous avez des retours d'experiences sur ce point.)

Merci.

---

Oui tu as une perte de perf mais je ne pense pas que celle ci soit significative : si ton jeu tourne à 60 FPS pas de soucis.
Si par contre tu recherches des performances maximales la première chose à faire est malheureusement de recoder son propre spritebach

Erf...
Cette bobox commence vraiment a m'enerver.
Par exemple je thread l'ia j'ai exactement les meme perf que sans thread.
Pourtant je fais bien

Code:

---

1 2 3 4

#if XBOX Thread.CurrentThread.SetProcessorAffinity( new int[ ] { 3 } ); #endif

---

et j'update le thread de l'ia sur deux fois moins que le thread principale.

De plus j'ai deux methodes de chargement, une avec des fichiers binaires serializer et une autre avec des fichiers xml mais je met sensiblement le meme temps. Ce qui m'etonne fortement car

Code:

---

1 2 3

br.ReadString(); //devrait etre plus rapide que this.ShaderTechnique = node.FindAttributeValue("ShaderTechnique") != null ? node.FindAttributeValue("ShaderTechnique") : "TexturedNoShading";

---

Quand je vois des gros jeux qui tourne sur la xbox en 3d+particules + lights il tourne a 60 ou 30 fps?
Meme si je pense qu'ils ne sont pas code en c#...

EDIT: quelle est la methode de profiling la plus indicative, CPU ou temps?

La vraie question c'est pourquoi travailles tu avec des threads ?
Mis à part si tu refais le Cry Engine c'est très rare d'en avoir réellement besoin et le temps gagné à ne pas les utiliser permet de passer du temps sur des vrais optimisations souvent plus utiles.

Concernant ton chargement il faut profiler plus en détails.

Citation:

---

Quand je vois des gros jeux qui tourne sur la xbox en 3d+particules + lights il tourne a 60 ou 30 fps?
Meme si je pense qu'ils ne sont pas code en c#...

---

Souvent 30 et des fois 60.
Le problème ne vient pas du C# car sur PC les performances sont bonnes mais surtout du micro framework .net absolument pas adapté à la xbox.

Citation:

---

EDIT: quelle est la methode de profiling la plus indicative, CPU ou temps?

---

Personnellement j'affiche le temps, j'ai quasiment un facteur 10 sur le calcul pur entre le temps sur PC et le temps sur Xbox.

Pour les optis la j'ai fait une passe pour supprimer toutes les string en dur.
Surtout sur les shader, les Effect.Technique et Effect.Parameters j'ai repasse tout ca en int. ca gagne quelques fps (cool :))

Pour le loading je n'ai quasiment aucune spritesheet que des sprite unique du coup si je passe tout ca en spritesheet je pense pouvoir gagner du temps de chargement...:P

Citation:

---

Envoyé par saturn1

Pour le loading je n'ai quasiment aucune spritesheet que des sprite unique du coup si je passe tout ca en spritesheet je pense pouvoir gagner du temps de chargement...:P

---

Moi c'est ça qui m'a sauvé la vie pour les temps de chargement :
http://easypak.codeplex.com/

Oai, j'ai pris le packer de xna creator club.

Merci :)

EDIT: on est limite a une taille de 4096 .. dommage, j'aurais foutu tout le content dans une spritesheet :aie:

Pour recoder le spritebatch.Draw tu fais ca avec Graphics.DrawUserIndexedPrimitive?

Pour la rotation l'origin et l'orgin tu fais ca direct dans le pixelshader avec un peu de math?

Pour le rectangle source et le scale il faut faire ca au niveau du binding de la texture je suppose.

Si tu sais dire a la louche cb de % c'est plus performant, meme si je sais que c'est dur d'estimer.

Merci.

Citation:

---

Pour recoder le spritebatch.Draw tu fais ca avec Graphics.DrawUserIndexedPrimitive?

---

Oui et une caméra ortho

Citation:

---

Pour la rotation l'origin et l'orgin tu fais ca direct dans le pixelshader avec un peu de math?

---

Il est possible d'envoyer la matrice World avec toutes les informations nécessaires.

Citation:

---

Pour le rectangle source et le scale il faut faire ca au niveau du binding de la texture je suppose.

---

Une des possibilités est d'envoyer les uv au vertexshader

Citation:

---

Si tu sais dire a la louche cb de % c'est plus performant, meme si je sais que c'est dur d'estimer.

---

Peut être 10-15%, certainement moins ; ça dépends de beaucoup de chose et ça n'a d'intérêt que si tu dessines un nombre extrêmement important d'éléments tout en étant spécifique à tes besoins ( afficher tous les éléments avec la même texture à la suite par exemple si tu te fiches de l'ordre d'affichage sur un même layer )
Ca permet aussi et surtout une plus grande flexibilité sur des besoins spécifiques.

Ok merci,
moi je n'ai q'environ 40 SpriteBatch.draw par frame, l'espace est partitionne. Donc ce n'est pas enorme.

Mais bon il faut que je vois si j'ai le temps de recoder, mais bon c'est sur qu'avec un sort.textured on doit gagner encore en perf.