SpriteBuffer

[marchred]

Idee que certain on du avoir, le but est de fusionner le Sprite et les VertexArray...
...pour en faire un espece de SpriteBuffer.

Je m'explique :

• Prendre la cappacite SetTexture() du Sprite
• Lui coller une pool de quatuor de vertices (coord2D + TexCoord)
• La taille de la pool est parametrable selon les besoin
• Un compteur indique le nombre de case de la pool a afficher
• Il est possible de reset a 0 ce compteur entre chaque frame
• Suite a quoi il est possible de push des donnees de Sprite dans la pool
  
  • on ne realloc pas la pool, on ecrase les data depuis le compteur
  • on incremente le compteur pour savoir combien afficher et d'ou ecraser dans le futur
• Enfin, on affiche, et la les avantages sont multiple :
• Un seul Appel a Bind de texture2D pour plusieurs Sprite
• Plusieur Sprite rendu en une seule fois
• Le system de Reset/Push permet de gerer des scenes 2D static et dynamic

PS : dsl pour mon francais probablement mauvais.
PS : clavier QWERTY, pas d'accent pour moi.

[Laurent]

Ce genre de classe me pose plusieurs problèmes :

- on ne pourra pas mettre dans un même buffer des sprites utilisant différentes textures, mais on ne peut pas l'interdire proprement au niveau de l'API (du coup je vois déjà les milliers de posts sur le forum "ça marche pô !")

- si on utilise un sf::Sprite il faut gérer tous ses attributs, donc notamment sa transformation courante (c'est pas la mort mais ça peut devenir assez vite inefficace pour des sprites qui ne bougent jamais).

- si on met des sf::Sprite dans le buffer, ce n'est à mon avis pas assez clair que ceux-ci sont copiés dans le vertex array ; je m'attend en outre à voir des gens changer leur sprite après ajout dans le buffer, et penser que le buffer va automatiquement prendre en compte ces changements

Du coup je préfère laisser chacun concevoir sa propre encapsulation de vertex array. Et puis, ce n'est pas comme s'il était difficile de créer les quatre sf::Vertex correspondant à un sprite

[marchred]

Hello !

Je crois comprendre ton raisonnement, ce serai un outil potentiellement difficile a comprendre.
Juste qu'apres lecture des source de la SFML, je pense que dans certain cas, ya moyen de faire tres rapide.

L'exemple le plus parlant sera surement une TileMap.
Mais cela peut s'etendre a tout objet de scene partageant la meme texture, projectile des bot/player.
Vu la taille/resolution de certaine texture, regroupper plusieurs image en une seule image est logique.

J'ai bien 20 projets utilisant un grand nombre de sprite qui se retrouve dans ce cas.


Apres je te l'ai dis, je comprend ton desir de faire une lib facile d'utilisation.
Mais certains sacrifice sont-ils vraiment necessaire ?

Tu mentionne plusieurs obstacle :

- on ne pourra pas mettre dans un même buffer des sprites utilisant différentes textures, mais on ne peut pas l'interdire proprement au niveau de l'API (du coup je vois déjà les milliers de posts sur le forum "ça marche pô !")

Exemple parfait, a ce stade la seule alternative que j'ai est d'indiquer le probleme avec un std::cerr.
Assert le programme si on push un Sprite avec une texture differente par exemple.
Box2D semble fan de cette technique, et je ne l'ai pas trouve si inabordable que cela.

- si on utilise un sf::Sprite il faut gérer tous ses attributs, donc notamment sa transformation courante (c'est pas la mort mais ça peut devenir assez vite inefficace pour des sprites qui ne bougent jamais).

Oui, c'est vrai que gerer le cas de maniere optimise/propre va complexifier le fonctionnement interne de la lib.
Probablement des modifications du Sprite (attribut bool) confirmant qu'il a subit une transformation.
Cela me fait penser qu'un ColorBuffer ne serait pas inutile dans une classe comme le SpriteBuffer.

- si on met des sf::Sprite dans le buffer, ce n'est à mon avis pas assez clair que ceux-ci sont copiés dans le vertex array ; je m'attend en outre à voir des gens changer leur sprite après ajout dans le buffer, et penser que le buffer va automatiquement prendre en compte ces changements

Vrai, mais a ce stade pourquoi ne pas rendre la chose possible ?
Au lieu de reset puis push des Sprites dans un SpriteBuffer, pourquoi ne pas les lier ?
Le SpriteBuffer attach/detach des Sprites qui sont update dans leur coin.
SpriteBuffer.Render() s'occuperai d'update la pool, qui a ce stade "pourrait" augmenter sa taille si besoin.

PS : dsl pour mon francais probablement mauvais.
PS : clavier QWERTY, pas d'accent pour moi.
PS : quelque soit ta decision, ce topic m'aura permit d'avoir une idee plus complete de ma "mySFML"

[Laurent]

Exemple parfait, a ce stade la seule alternative que j'ai est d'indiquer le probleme avec un std::cerr.
Assert le programme si on push un Sprite avec une texture differente par exemple.
Box2D semble fan de cette technique, et je ne l'ai pas trouve si inabordable que cela.

En effet on peut faire ça, c'est pour ça que j'ai parlé de l'impossibilité de le faire au niveau de l'API. J'ai tendance à éviter les cas d'erreur qui sont connus d'avance, mais qui ne peuvent être détectés qu'en runtime. Ca signifie "tu ne peux pas faire ça, mais je te laisse le faire et t'auras une belle surprise quand tu lanceras ton programme". Pour moi c'est un point négatif dans l'API, même si c'est loin d'être crade.

Probablement des modifications du Sprite (attribut bool) confirmant qu'il a subit une transformation.

Là on optimise un nouveau cas, mais on rend plus "complexe" l'utilisation de base (le sprite tout seul sans buffer). Et puis idéalement sf::Sprite ne devrait pas comporter de détail d'implémentation relatif à un éventuel sf::SpriteBuffer. La dépendance devrait être uniquement dans l'autre sens.

Vrai, mais a ce stade pourquoi ne pas rendre la chose possible ?
Au lieu de reset puis push des Sprites dans un SpriteBuffer, pourquoi ne pas les lier ?

Alors se pose le problème de responsabilité : qui gère la durée de vie du sprite ? Certainement l'utilisateur de la classe, mais dans ce cas on va retomber dans les mêmes problèmes qu'avec sf::Sprite/sf::Texture (bon, tu me diras, le problème est déjà là de toute façon). Et puis du coup, quid du mec qui veut construire son sprite buffer avec des sprites temporaires ? Et à force de détruire et recréer des sprites dans le buffer, on risque d'avoir des trous. Bien sûr tout ceci est gérable, mais la classe part déjà avec beaucoup de handicaps techniques et conceptuels.