-
Salut,
j'ai une classe EntitéDessinable qui hérite de sf::Drawable et sf::Transformable.
De là en dérive une classe Tile qui contient et sprite et d'autres classes.
Je voudrai faire en sorte qu'on puisse modifier la géométrie à partir de cette classe EntitéDessinable et faire un draw directement sur un objet de type EntitéDessinable afin d'éviter de devoir à chaque fois vérifier le type d'entité et de faire un cast avant de dessiner.
Je voudrais aussi éviter de devoir modifier mon code, c'est à dire remplacer mon sf::Sprite par un sf::VertexArray.
Mais je n'ai trouvé aucune moyen de redéfinir la méthode draw en appliquant une transformation directement à un sprite, j'ai essayé ceci mais ça ne marche pas :
void Tile::draw (RenderTarget &target, RenderStates states) const {
states.transform = getTransform();
target.draw(sprite, states);
}
Même en appelant setPosition dans le constructeur de ma classe tile pour mettre à jour la position du sprite dans la classe sf::Transformable, le sprite ne s'afficher pas.
Que dois je faire ???
-
Bon c'est bizarre j'ai fais ça :
void Tile::draw (RenderTarget &target, RenderStates states) const {
states.transform = states.transform * getTransform();
target.draw(sprite, states);
}
Et les 4 première tiles que je veux ajouter sur la map ne s'ajoutent pas, mais à partir de la 5ème ça marche.
-
C'est en effet le bon code (pour ce genre de chose n'hésite pas à regarder les exemples dans les tutoriels, ou le code source de SFML directement).
Pour ce qui est des 4 premières tuiles, ça doit être un tout autre problème.
-
Oui, le problème vient d'ailleurs pour les 1ères tiles, bon bah voilà j'ai améliorer la classe ainsi, je peux définir la position de mes sprite à partir de leur origin mais aussi à partir de leur coin supérieur gauche maintenant.
J'ai juste du ré-écrire mes méthodes de la classe transformable par dessus les siennes.
-
Au sinon j'ai vu que la position était stockée dans la classe sf::Transformable et non dans la classe sf::Sprite comme je le pensais et ce qui me semblerait plus logique. (Du coup je me retrouve avec 2 positions (celle su sprite et celle du noeud (ma classe Tile).)
Je pense plus tard que je vais utiliser mes propres classes de transformation plutôt que la sfml et faire les transformation directement sur des vertexarray avant d'appeler draw. (Commele font la plupart des framework, je pense même que la plupart des framewors n'utilisent même plus le matrices d'opengl.)
Parce que là je dois réimplémenter toute les méthodes de la classe Transformable. (Je préfère ça que d'utiliser un sf::Transform et de devoir réimplémenter toutes les méthodes setRotation, setScale, etc... si ce n'est pas nécessaire.) de sorte à ce que Transformabe contienne juste les transformations et l'origine, combiner mes transformations avec celle du sprite qui ne contient que la position et l'origine finalement.
Avec l'origine je suis un peu perdu aussi car j'ai 2 origines, celles du sprite et celles de la classe transformable, bref, je mets les 2 mêmes origines pour les 2.
Bref en gros voilà ce que j'ai fais :
#ifndef TILE
#define TILE
#include <SFML/Graphics.hpp>
#include "../Math/vec4.h"
#include "../Math/maths.h"
#include "../Lighting/light.h"
#include "../Math/computer.h"
#include <vector>
class MyCanvas;
class GridMap;
class Shadow;
class Wall;
class Tile : public Entity, public sf::Drawable , public sf::Transformable {
public :
//Type principale de la couche.
Tile (sf::Texture &image, Vec2f position, Vec2f size, sf::IntRect subRect, bool bToAnim);
sf::Sprite& getSprite ();
const sf::Texture& getTexture ();
Vec2f getSize();
virtual Vec2f getPosition();
Vec2f getCenter();
void setZOrder(int zOrder);
virtual void setPosition (Vec2f pos);
void setCenter(Vec2f center);
void setSize(Vec2f size);
virtual void setOrigin(Vec2f origin);
sf::IntRect getTextRect();
void setAltitude (int altitude);
int getAltitude ();
bool operator== (Tile &tile);
bool operator!= (Tile &tile);
int getZOrder();
void setSelected(bool selected);
bool isSelected ();
void setShadowCenter(int cx, int cy);
Vec2f getShadowCenter ();
bool belongToAnim ();
void popup();
void popback ();
virtual ~Tile ();
private :
virtual void draw(sf::RenderTarget &target, sf::RenderStates states) const;
Tile (const Tile* tile);
int zOrder;
bool selected, bToAnim;
sf::Sprite sprite;
};
#endif
#include "tile.h"
#include "../world/gridMap.h"
#include "../Lighting/shadow.h"
#include "../Lighting/wall.h"
using namespace sf;
using namespace std;
/*Gère les différents tiles, cette classe hérite de Sprite.
*/
//Crée un tile, avec une image passée en paramètre.
Tile::Tile (sf::Texture &image, Vec2f position, Vec2f size, IntRect subRect, bool bToAnim) : Entity (E_TILE) {
sprite.setTexture(image);
sprite.setTextureRect(subRect);
float factorX = size.x / subRect.width;
float factorY = size.y / subRect.height;
sprite.setOrigin(subRect.width * 0.5f, subRect.height * 0.5f);
sprite.scale(factorX, factorY);
sprite.setPosition(position.x + size.x * 0.5f, position.y + size.y * 0.5f);
this->bToAnim = bToAnim;
zOrder = 0;
selected = false;
Transformable::setOrigin(subRect.width * 0.5f, subRect.height * 0.5f);
}
void Tile::setOrigin(Vec2f origin) {
Transformable::setOrigin(origin.x, origin.y);
sprite.setOrigin(origin.x, origin.y);
}
IntRect Tile::getTextRect () {
return sprite.getTextureRect();
}
Vec2f Tile::getSize() {
Vec2f size(sprite.getGlobalBounds().width, sprite.getGlobalBounds().height);
return size;
}
void Tile::setSize(Vec2f size) {
Vec2f actualSize = this->getSize();
Vec2f scale = size / actualSize;
this->size = size;
sprite.setScale(scale.x, scale.y);
}
const Texture& Tile::getTexture () {
return *sprite.getTexture();
}
Vec2f Tile::getCenter () {
return Vec2f(sprite.getPosition().x, sprite.getPosition().y);
}
Vec2f Tile::getPosition() {
return Vec2f(sprite.getGlobalBounds().left, sprite.getGlobalBounds().top);
}
bool Tile::belongToAnim () {
return bToAnim;
}
void Tile::popup () {
if (zOrder + 1 <= DEFAULT_SHADOW_Z_ORDER)
zOrder++;
}
void Tile::popback () {
if (zOrder - 1 >= 0)
zOrder--;
}
bool Tile::operator== (Tile &tile) {
return sprite.getTexture() == tile.sprite.getTexture() &&
sprite.getPosition().x == tile.sprite.getPosition().x &&
sprite.getPosition().y == tile.sprite.getPosition().y &&
getSize().x == tile.getSize().x &&
getSize().y == tile.getSize().y &&
getZOrder() == tile.getZOrder() &&
getType() == tile.getType () &&
sprite.getTextureRect().left == tile.sprite.getTextureRect().left &&
sprite.getTextureRect().top == tile.sprite.getTextureRect().top &&
sprite.getTextureRect().height == tile.sprite.getTextureRect().height &&
sprite.getTextureRect().width == tile.sprite.getTextureRect().width;
}
bool Tile::operator!= (Tile &tile) {
return !(*this == tile);
}
//Getter.
Sprite& Tile::getSprite () {
return sprite;
}
//Renvoie le numéro de la couche du sprite.
int Tile::getZOrder() {
return zOrder;
}
bool Tile::isSelected () {
return selected;
}
void Tile::setZOrder(int zOrder) {
this->zOrder = zOrder;
}
void Tile::setSelected (bool selected) {
this->selected = selected;
}
void Tile::setPosition(Vec2f pos) {
Vec2f origin (sprite.getOrigin().x, sprite.getOrigin().y);
Vec2f originalSize (sprite.getTextureRect().width, sprite.getTextureRect().height);
Vec2f size = getSize();
Vec2f scale (size.x / originalSize.x, size.y / originalSize.y);
Vec2f sub (origin.x * scale.x, origin.y * scale.y);
sprite.setPosition(Vec2f(sprite.getPosition().x - sub.x, sprite.getPosition().y - sub.y));
}
void Tile::setCenter(Vec2f center) {
sprite.setPosition(Vector2f(center.x, center.y));
}
void Tile::draw (RenderTarget &target, RenderStates states) const {
states.transform = states.transform * getTransform();
target.draw(sprite, states);
}
Tile::~Tile () {
}
Un peu compliqué je pense que y'a peut être moyen de faire plus simple. :/
Donc finalement qu'est ce qui est mieux, faire des transformations sur des vertex en utilisant ses propres matrices ou alors faire des transformation sur des vertex en utilisant les matrices d'opengl ?
Je pencherai plutôt pour la 1ère solution moi.
-
Il faut bien entendu faire les transformations via les matrices OpenGL. C'est fait pour ça (= c'est gratuit à l'exécution).
Ensuite j'ai pas vraiment regardé en détail ton code, mais pour faire simple, ignore les transformations du sprite, fais comme s'il n'en avait pas et gère tout avec ton sf::Transformable.
-
Ok mais quand je passerai en 3D et que je devrai faire des transformations autour d'un axe quelconque les matrices d'opengl ne me suffiront plus bref...
Ok je vais faire comme ça, comme si le sprite n'a aucune transformation.
Et je vais faire toutes mes transformations avec le sf::Transformable du noeud que je combine avec celle du sprite. (Seul le setPosition, le setSize et le setCenter pourront changer la transformation du sprite.)
Je dois juste faire attention à ce que le sprite et le noeud aie la même origine sinon je risque d'avoir des problèmes. :/
-
Ok mais quand je passerai en 3D et que je devrai faire des transformations autour d'un axe quelconque les matrices d'opengl ne me suffiront plus bref...
Tiens donc, j'aimerais bien savoir pourquoi :P
Je dois juste faire attention à ce que le sprite et le noeud aie la même origine sinon je risque d'avoir des problèmes. :/
Normalement non justement, pourquoi est-ce que tu aurais des problèmes ?
-
Bah en utilisant des quaternions par exemple. (On utilise plutôt ça à l'heure actuelle, mais surtout pour la 3D, pour de la 2D je ne pense pas que tu en ai besoin.)
Sinon ta matrice encapsulée dans sf::Transform tu la passe à opengl et c'est lui qui fait toutes les transformations à l'exécution ?
C'est plus rapide de faire comme ça ?
Maintenant il y a peut être moyen de transformer un quaternion en une matrice et la passer à opengl pour qu'il fasse une rotation autour d'un axe quelconque par exemple, mais ça m'étonnerais fort que ça soit possible les queternions et les matrices c'est complètement différent.
Bon finalement j'ai trouvé comment résoudre le problème avec la globalBox, j'ai regardé dans les sources de la sfml et il suffit d'appeler transformRect sur la localBox.
Je suppose que getLocalBounds ne fait rien d'autre que de renvoyer le textureRect.
-
Bah en utilisant des quaternions par exemple. (On utilise plutôt ça à l'heure actuelle, mais surtout pour la 3D, pour de la 2D je ne pense pas que tu en ai besoin.)
Les quaternions sont plus adaptés pour certaines manipulations, mais au final tu pourras toujours encoder ta transformation dans une matrice 4D et la passer à OpenGL.
Sinon ta matrice encapsulée dans sf::Transform tu la passe à opengl et c'est lui qui fait toutes les transformations à l'exécution ?
C'est plus rapide de faire comme ça ?
Oui. Ne pas laisser OpenGL gérer la transformation des vertexs, ce serait vraiment très contre-productif. C'est justement à ça que sert la carte graphique.
Maintenant il y a peut être moyen de transformer un quaternion en une matrice et la passer à opengl pour qu'il fasse une rotation autour d'un axe quelconque par exemple, mais ça m'étonnerais fort que ça soit possible les queternions et les matrices c'est complètement différent.
Toi tu as besoin de lire quelques articles sur les matrices et les transformations. Là tu pars sur des hypothèses complètement fausses, qui vont te faire concevoir et implémenter des choses inutiles dans ton application.
Avec une matrice 4D tu peux représenter n'importe quelle transformation 3D, linéaire ou non. Et donc bien entendu une rotation quelconque.
-
Ha lol, parce que j'ai vu le code source d'un moteur de jeux (JMonkeyEngine) qui utilise ses propres matrices et quaternions pour transformer les vertex.
C'est même sur le code de ce moteur là que je m'étais basé mais il me semblait bien que en lisant le code de ce moteur là ça ne me semblait pas très optimal.
Déjà faire un arbre binaire ou chaque feuille ne contient qu'un vertex n'est pas bon, car, il faut faire une entité par feuille, car, ce n'est pas parce que un vertex de la primitive est en dehors de la zone affichable à l'écran que les pixels qui relient ce vertex aux autes vertex ne sont pas affichable.
Et bon je suppose que c'est opengl qui se charge de savoir si un pixel est visible ou pas au niveau dela carte graphique.
Bref j'ai du m'inspirer d'un mauvais truc. :-\
-
Voici un lien avec les différentes matrices de transformation : http://www.siteduzero.com/informatique/tutoriels/developpez-vos-applications-3d-avec-opengl-3-3/transformations-au-niveau-matricielle
La matrice pour une rotation sur un axe arbitraire est compliquée car c'est en fait le résultat de RotationMatrixAxeX * RotationMatrixAxeY * RotationMatrixAxeZ
Si tu regarde dans le code source de sf::Transform, tu peux voir que les rotations sont faites seulement à partir de la RotationMatrixAxeZ car les rotations en 2D ne tourne qu'autour de l'axe Z ==> c'est donc suffisant.
Je suis également en train de coder ma classe Transform3D, donc si il y a moyen d'avoir une petite confirmation que mon explication soit bel est bien correcte ? :)
-
Je suis également en train de coder ma classe Transform3D, donc si il y a moyen d'avoir une petite confirmation que mon explication soit bel est bien correcte ?
Elle l'est quasiment ;)
Une rotation quelconque peut être exprimée de différentes manières ; la combinaison de rotations autour des 3 axes n'en est qu'une parmi d'autres. On pourrait aussi l'obtenir directement via un quaternion, via un axe + angle (ce qui est pratiquement le quaternion), etc. Il y a la formule qui va bien pour transformer chacune de ces choses en une matrice 4D.
-
Ok merci pour l'information je chercherai de ce côté là alors. :)
J'ai une dernière question est il possible que 2 tiles tournent autour d'un même point ?
Je voudrais que ma tile et son ombre tournent autour de l'origine de la tile en fait.
Sinon impéc j'ai pu combiner les transformations pour que mes segments pour les instersections murs lumière et mes points pour les projections des ombres de mes murs tournent en même temps que la tile qui affichent mes mur en utilisant ma propre classe transformMatrix dans la surcharge des méthodes setRotation, setScale et move.
Je peux donc combiner les transformations sur les entités de la SFML et les entités de mon propre framework ce qui est cool.
-
J'ai une dernière question est il possible que 2 tiles tournent autour d'un même point ?
Oui, il faut juste transformer ce point d'un repère local à l'autre (car l'origine est exprimée en coordonnées locales à l'entité).
-
Ok sinon je vois que tu fais toujours au moins une transformation pour les sprites car je n'ai pas vu de constructeur dans la classe sprite ou l'on peut passer la position du sprite.
Donc j'aurai du mal de faire un sprite sans transformation. :/
Je dois donc toujours faire au moins une transformation pour initialisé la position du sprite avec le constructeur de ma classe Tile. :/
Sinon pour les ConvesShape et VertexArray pas de soucis vu que la je peux passer directement la position des vertex grâce à la méthode addPoint ou append sans devoir faire de transformation.
PS : Et je ne peux pas modifier directement la position des Vertex des sprites car je n'y ai pas accès.
-
Ok sinon je vois que tu fais toujours au moins une transformation pour les sprites car je n'ai pas vu de constructeur dans la classe sprite ou l'on peut passer la position du sprite.
Donc j'aurai du mal de faire un sprite sans transformation. :/
Je dois donc toujours faire au moins une transformation pour initialisé la position du sprite avec le constructeur de ma classe Tile. :/
??
Je ne comprends pas ce que tu veux dire là.
Sinon pour les ConvesShape et VertexArray pas de soucis vu que la je peux passer directement la position des vertex grâce à la méthode addPoint ou append sans devoir faire de transformation.
PS : Et je ne peux pas modifier directement la position des Vertex des sprites car je n'y ai pas accès.
Là non plus je ne vois vraiment pas ce que tu veux faire :-\
-
Bon j'ai trouvé mieux en faisant carrément une classe dérivée de sf::Transformable (TransformableEntity) qui se charge de faire des tranformations sur des entités quelconques, les méthodes de cette classe dérivée qui appliquent les transformation peuvent être redéfinie si pas exemple je dois transformer aussi des entités enfants dans la classe qui hérite de TransformableEntity, remettre à jour la physique ou encore faire mon propre sf::Transform.
Voici cette classe :
#ifndef TRANSF_ENTITY
#define TRANSF_ENTITY
class TransformableEntity : public virtual sf::Transformable {
public :
void setLocalBounds (FloatRect localBounds) {
this->localBounds = localBounds;
}
FloatRect getLocalBounds() {
return localBounds;
}
virtual void setCenter(Vec2f center) {
Transformable::setPosition(Vector2f(center.x, center.y));
}
Vec2f getCenter() {
return Vec2f(Transformable::getPosition().x, Transformable::getPosition().y);
}
virtual void setPosition(Vec2f position) {
Vec2f origin (Transformable::getOrigin().x, Transformable::getOrigin().y);
Vec2f originalSize (getLocalBounds().width, getLocalBounds().height);
Vec2f size = getSize();
Vec2f scale (size.x / originalSize.x, size.y / originalSize.y);
Vec2f sub (origin.x * scale.x, origin.y * scale.y);
setCenter(position - sub);
}
Vec2f getPosition() {
FloatRect globalBounds = getGlobalBounds();
Vec2f position(globalBounds.left, globalBounds.top);
return position;
}
Vec2f getSize() {
FloatRect globalBounds = getGlobalBounds();
Vec2f size(globalBounds.width, globalBounds.height);
return size;
}
virtual void setRotation (float angle) {
Transformable::setRotation(angle);
}
virtual void setScale(Vec2f scale) {
Transformable::setScale(Vector2f(scale.x, scale.y));
}
virtual void move (Vec2f t) {
Transformable::move(Vector2f(t.x, t.y));
}
virtual void setOrigin(Vec2f origin) {
Transformable::setOrigin(Vector2f(origin.x, origin.y));
}
Vec2f getScale() {
return Vec2f(Transformable::getScale().x, Transformable::getScale().y);
}
float getRotation() {
return Transformable::getRotation();
}
Vec2f getOrigin() {
return Vec2f(Transformable::getOrigin().x, Transformable::getOrigin().y);
}
virtual void setSize (Vec2f size) {
Vec2f actualSize = this->getSize();
Vec2f scale = size / actualSize;
Transformable::setScale(scale.x, scale.y);
}
FloatRect getGlobalBounds() {
FloatRect globalBounds = getTransform().transformRect(localBounds);
}
private :
FloatRect localBounds;
};
#endif // TRANSF_ENTITY
Ca m'évite de devoir réecrire du code et de devoir à chaque fois redéfinir toutes les méthodes de transformation pour mes entités transformable et je peux aussi utiliser le polymorphisme si je veux appliquer des transfomations sur toutes les entités sélectionnée qui peuvent être de type différents.
Je crois que je vis lui mettre un constructeur à cette classe en envoyant la position et la taille du localBounds. (Je ne fais pas de transformation au sprite je ne fait que les transformations avec ma classe TransormableEntity.)
Ce qui donne :
#include "tile.h"
#include "../world/gridMap.h"
#include "../Lighting/shadow.h"
#include "../Lighting/wall.h"
using namespace sf;
using namespace std;
/*Gère les différents tiles, cette classe hérite de Sprite.
*/
//Crée un tile, avec une image passée en paramètre.
Tile::Tile (sf::Texture &image, Vec2f position, Vec2f size, IntRect subRect, bool bToAnim) : Entity (E_TILE) {
sprite.setTexture(image);
sprite.setTextureRect(subRect);
float factorX = size.x / subRect.width;
float factorY = size.y / subRect.height;
this->bToAnim = bToAnim;
zOrder = 0;
selected = false;
TransformableEntity::setOrigin(subRect.width * 0.5f, subRect.height * 0.5f);
TransformableEntity::setPosition(Vec2f(position.x + size.x * 0.5f, position.y + size.y * 0.5f));
TransformableEntity::setScale(Vec2f(factorX, factorY));
setLocalBounds(sprite.getLocalBounds());
}
IntRect Tile::getTextRect () {
return sprite.getTextureRect();
}
const Texture& Tile::getTexture () {
return *sprite.getTexture();
}
bool Tile::belongToAnim () {
return bToAnim;
}
void Tile::popup () {
if (zOrder + 1 <= DEFAULT_SHADOW_Z_ORDER)
zOrder++;
}
void Tile::popback () {
if (zOrder - 1 >= 0)
zOrder--;
}
bool Tile::operator== (Tile &tile) {
return sprite.getTexture() == tile.sprite.getTexture() &&
sprite.getPosition().x == tile.sprite.getPosition().x &&
sprite.getPosition().y == tile.sprite.getPosition().y &&
getSize().x == tile.getSize().x &&
getSize().y == tile.getSize().y &&
getZOrder() == tile.getZOrder() &&
getType() == tile.getType () &&
sprite.getTextureRect().left == tile.sprite.getTextureRect().left &&
sprite.getTextureRect().top == tile.sprite.getTextureRect().top &&
sprite.getTextureRect().height == tile.sprite.getTextureRect().height &&
sprite.getTextureRect().width == tile.sprite.getTextureRect().width;
}
bool Tile::operator!= (Tile &tile) {
return !(*this == tile);
}
//Getter.
Sprite& Tile::getSprite () {
return sprite;
}
//Renvoie le numéro de la couche du sprite.
int Tile::getZOrder() {
return zOrder;
}
bool Tile::isSelected () {
return selected;
}
void Tile::setZOrder(int zOrder) {
this->zOrder = zOrder;
}
void Tile::setSelected (bool selected) {
this->selected = selected;
}
void Tile::draw (RenderTarget &target, RenderStates states) const {
states.transform = states.transform * getTransform();
target.draw(sprite, states);
}
Tile::~Tile () {
}
J'avais pensé utiliser transfomable et faire hériter directement toutes les entités transformable de cette classe mais le problème c'est que les méthodes de la classe Transformable ne sont pas virtuelle donc je ne pourrai pas faire du polymorphisme. :/
-
C'est très bancal tout ça.
Déjà, pourquoi est-ce que toutes les fonctions de ta classe sont virtuelles ? Ensuite, puisque tu redéfinis tout ce que sf::Transformable propose, pourquoi en hériter publiquement ? Là dans ta classe tu va tout avoir en double : tes fonctions + celles de sf::Transformable. Si tu hérites de sf::Transformable juste pour implémenter ta classe, alors fais un héritage prové pour ne pas polluer l'interface publique de ta classe.
-
C'est très bancal tout ça.
Déjà, pourquoi est-ce que toutes les fonctions de ta classe sont virtuelles ?
Pour pouvoir utiliser le polymorphisme car ma grille contient des objets de type TransformableEntity et non pas de type Tile car je m'en fou de savoir si c'est une Tile ou bien un mur u ien n'importe quoi quand je veut redimentionner, faire tourner ou bien repositionner mes entités.
Et étant donné que les fonctions de Transformable ne sont pas virutelle comme la fonction draw de Drawable bah je peux pas utiliser des objets de type Transformable pour faire mes transformations car sinon, se seront les fonctions de Transformable qui seront appelée et pas les fonctions de ma classe qui hérite de Transformable, du coup certaines de mes entités de mon framework qui utilisent aussi de la physique et doivent redéfinir des méthodes de Transformable, et bah, ne remettront pas la physique à jour, comme par exemple, ma classe wall qui contient aussi les segments pour les intesections mur lumière ainsi que des points pour la projection des ombres en fonction des lumières :
#include "wall.h"
#include "lightManager.h"
Wall::Wall (Tile *t, int type) : Entity(Entity::E_WALL) , TransformableEntity(t->getPosition(), t->getSize(), t->getOrigin()) {
this->type = type;
this->t = t;
shadow = new ShadowWall(LightManager::getSun(), t, this);
}
void Wall::setSize(Vec2f size) {
TransformableEntity::setSize(size);
scale(s);
}
void Wall:setCenter(Vec2f center) {
Vec2f t = center - this->getCenter();
TransformableEntity::setCenter(center);
move(t);
}
void Wall::setPosition(Vec2f position) {
TransformableEntity::setPosition(Vec2f (position.x, position.y));
move(t);
}
void Wall::addSegment (Segment *seg) {
segments.push_back(seg);
}
void Wall::addBottomPoint (Vec2f *point) {
bottomPoints.push_back(point);
}
std::vector<Segment*> Wall::getSegment () {
return segments;
}
std::vector<Vec2f*> Wall::getBottomPoints () {
return bottomPoints;
}
void Wall::setType (int type) {
this->type = type;
}
int Wall::getType () {
return type;
}
void Wall::setRotation (float angle) {
shadow->setRotation(angle);
TransformMatrix tm;
tm.setRotation(angle);
for (int i = 0; i < segments.size(); i++) {
segments[i]->rotate(angle, Vec2f(t->getOrigin().x, t->getOrigin().y));
}
for (int i = 0; i < bottomPoints.size(); i++) {
*bottomPoints[i] = tm.transform(*bottomPoints[i]);
}
TransformableEntity::setRotation(angle);
}
void Wall::setScale (Vec2f s) {
shadow->setScale(s.x, s.y);
TransformMatrix tm;
tm.setScale(s.x, s.y);
for (int i = 0; i < segments.size(); i++) {
segments[i]->scale(s.x, s.y);
}
for (int i = 0; i < bottomPoints.size(); i++) {
*bottomPoints[i] = tm.transform(*bottomPoints[i]);
}
TransformableEntity::setScale(s.x, s.y);
}
void Wall::move (Vec2f t) {
shadow->move(t.x, t.y);
TransformMatrix tm;
tm.setTranslation(t.x, t.y);
for (int i = 0; i < segments.size(); i++) {
segments[i]->translate(t.x, t.y);
}
for (int i = 0; i < bottomPoints.size(); i++) {
*bottomPoints[i] = tm.transform(*bottomPoints[i]);
}
TransformableEntity::move(t.x, t.y);
}
void Wall::Draw (RenderTarget &target, RenderStates states) const {
states.transform = states.transform * getTransform();
target.draw(*t, states);
}
Shadow* Wall::getShadow() {
return shadow;
}
Wall::~Wall () {
for (unsigned int i = 0; i < segments.size(); i++)
delete segments[i];
segments.clear();
for (unsigned int i = 0; i < bottomPoints.size(); i++)
delete bottomPoints[i];
bottomPoints.clear();
delete shadow;
}
Donc voilà pourquoi j'ai déclarer mes méthodes virtuelles.
Ensuite, puisque tu redéfinis tout ce que sf::Transformable propose, pourquoi en hériter publiquement ?
Ha oui c'est vrai merci.
-
Bon j'ai fait un héritage privé, et j'ai fais mes propres interface qui sont implémentent les interfaces SFML mais avec des fonctions supplémentaires.
Et je peux aussi redéfinir ses fonctions si il y a lieux pour remettre à jour la physique du monde en cas de transformation sur mes entités.
Et enfin, j'en ai profité également pour faire une interface dont hériteront toutes les entités dynamique et statiques qui seront dessinable. ^^ (Les entités statique ayant aussi une position, un centre et une taille)
-
Sinon, une petite remarque, pour les entités statiques je préfère faire une seule transformation au chargement de la map puis afficher les entités plutôt que de faire la transformation à chaque rendu. :/ (Plus performant.)
Il n'y a que pour les entités dynamiques donc qu'il faut faire la transformation à chaque rendu.
Bref je vais réimplémenter tout ça.
-
Sinon une matrice 2*2 suffit amplement pour faire de la 2D si je ne me trompe pas :
x' = (x * cos(alpha) * sx + tx + ox) + (y * sin(alpha) * sy)
y' = (x * -sin(alpha) * sx) + (y * cos(alpha) * sy + ty + oy)
En espérant avoir bien recopier la formule que j'ai écrite sur papier ce matin.
tx et ty sont la translation de x et de y, sx et sy l'échelle, alpha l'angle de rotation, ox et oy les origines en x et y, x les coordonnées du point à transformer et ', y' les coordonnées du point transformé.
Hum..., j'ai du inverser les signes pour la matrice car l'axe y pointe vers le bas.
Ta matrice 4*4 ok elle marche mais je n'y comprend rien. :/
Bref moi je ne m'en sert que pour de la 3D. (Dans ma classe TransformMatrix j'ai 2 matrices, une 2*2 pour de la 2D et une 4*4 pour de la 3D.)
PS : de plus je combine les transformations dans ma classe TransformMatrix directement et si je veux pas combiner bah je fais loadIdentity avant chaque transformation je trouve ça plus pratique que de devoir réimplémenter une classe pour combiner les transformations.
Voici à quoi ressemble ma classe :
void TransformMatrix::setRotation (int angle) {
float cosAlpha = Math::cosinus(Math::toRadians(angle));
float sinAlpha = Math::sinus(Math::toRadians(angle));
matrix2f.m11 += cosAlpha;
matrix2f.m12 += sinAlpha;
matrix2f.m21 += -sinAlpha;
matrix2f.m22 += cosAlpha;
}
void TransformMatrix::setScale (float sx, float sy) {
matrix2f.m11 *= sx;
matrix2f.m12 *= sy;
matrix2f.m21 *= sx;
matrix2f.m22 *= sy;
}
void TransformMatrix::setTranslation (int dx, int dy) {
matrix2f.m21 += dx;
matrix2f.m22 += dy;
}
void TransformMatrix::reset () {
matrix2f.identity ();
}
Vec2f TransformMatrix::transform (const Vec2f &vec2) {
return matrix2f * vec2;
}
Vec3f TransformMatrix::inverseTransform (const Vec2f &vec2) {
Matrix2f inv;
inv = matrix2f.inverse();
return inv * vec2;
}
Bref ça m'ennuie beaucoup de devoir dériver de sf::Transformable ou bien de devoir réutiliser un sf::Transform en interne pour pouvoir faire ce genre de chose. :/
Je pense que je vais utiliser SFML que pour le fenêtrage finalement, les évènements, le son et le réseau.
Pour le reste j'ai besoin de code plus simple que de devoir dériver à chaque fois et utiliser mon propre sf::Transform pour gérer les transformations d'un parent et de ses noeuds. :/
Et ce qui m'énerve le plus c'est de devoir faire un setPosition pour un sprite si je veux lui mettre une position par défault hors que si mon sprite est statique et que je veux simplement lui donner 1 vertexarray avec 4 positions sans devoir passer par une transformation et devoir faire gaffe lorsque je combine cette transformation avec celle du noeud.
Je crois que je vais refaire une classe sprite ou je mets direct une position aux vertex pour les 4 coins et pas utiliser de tansformations si je n'en veut pas.
-
Et un autre truc qui me chiffone c'est de devoir déplacer la vue d'une RenderTexture comme si c'était une seconde vue hors que ce n'est qu'une texture, au lieu de pouvoir l'utiliser comme un sprite ou n'importe quel autre entité dessinable. (De plus pas moyen de modifier l'origine d'une vue, l'origine de la vue c'est toujours le centre.)
Bref je n'ai jamais compris l'intérêt de faire une vue pour une texture de rendu hors que une texture de rendu ce n'est pas une vue. (Enfin pour moi ça ne l'est pas.)
PS : bref je vais pas continuer à chouiner comme je comprends pas mal opengl et la SFML j'ai trouvé une solution pour faire ça plus simplement en utilisant mes propres matrices, sprites et textures de rendu sans devoir modifier trop mon code.
-
Sinon, une petite remarque, pour les entités statiques je préfère faire une seule transformation au chargement de la map puis afficher les entités plutôt que de faire la transformation à chaque rendu.
Dis toi bien que de toute façon OpenGL va appliquer une transformation à tous les points qu'il voit passer. Si tu ne transformes pas dynamiquement tes entités ce sera juste la matrice identité ; mais ça n'aura strictement aucun impact sur les performances.
Sinon une matrice 2*2 suffit amplement pour faire de la 2D si je ne me trompe pas
Pour les transformations linéaires oui. Mais la translation ne l'est pas, il faut donc une dimension supplémentaire pour la gérer.
Rappel : une transformation linéaire est du type y = a * x, or la translation est de type y = a + x.
Ta matrice 4*4 ok elle marche mais je n'y comprend rien.
SFML utilise une matrice 4x4 en interne de manière à pouvoir la refiler à OpenGL telle quelle, mais la 3ème dimension n'est pas utilisée.
de plus je combine les transformations dans ma classe TransformMatrix directement et si je veux pas combiner bah je fais loadIdentity avant chaque transformation je trouve ça plus pratique que de devoir réimplémenter une classe pour combiner les transformations.
Mais une fois que tu as combiné plusieurs composantes tu ne peux plus en changer une sans reconstruire toute la matrice. C'est ça que fait sf::Transformable : elle garde toutes ses composantes séparées, et les combine uniquement lorsqu'on a besoin d'avoir une représentation de la matrice.
Bref ça m'ennuie beaucoup de devoir dériver de sf::Transformable ou bien de devoir réutiliser un sf::Transform en interne pour pouvoir faire ce genre de chose. :/
Pourquoi utiliser un sf::Transform ne convient-il pas ?
Et ce qui m'énerve le plus c'est de devoir faire un setPosition pour un sprite si je veux lui mettre une position par défault hors que si mon sprite est statique et que je veux simplement lui donner 1 vertexarray avec 4 positions sans devoir passer par une transformation et devoir faire gaffe lorsque je combine cette transformation avec celle du noeud.
Je crois que je vais refaire une classe sprite ou je mets direct une position aux vertex pour les 4 coins et pas utiliser de tansformations si je n'en veut pas.
En effet tu peux faire ça ; sf::Sprite n'est qu'une couche très fine par dessus un sf::Vertex[4] + sf::Texture*. Mais je ne vois pas quel est l'inconvénient de faire un setPosition. Si tu penses aux performances, alors je vais te dire que ce n'est pas un argument tant que tu n'as pas prouvé que ça l'était. C'est assez minime comme impact.
Bref je n'ai jamais compris l'intérêt de faire une vue pour une texture de rendu hors que une texture de rendu ce n'est pas une vue. (Enfin pour moi ça ne l'est pas.)
Le fait que tu dessines sur une texture n'est pas pertinent ici. Que tu dessines sur une fenêtre, sur une texture, sur du papier ou n'importe quoi d'autre, c'est pareil : tu dessines. Et il faut bien définir quelle zone de la scène tu dessines.
-
A ok je comprends mieux là, ok si ça n'a pas d'impact sur les performances alors je vais laisser ça comme ça.
En effet dans le code que j'ai mis j'ai besoin de reconstruire la matrice à chaque transformation.
-
Ok sinon, je pense que je vais faire ma propre classe transformable contenant un sf::Transform finalement et un ma propre classe sprite pour m'entrainer.
Sinon j'ai une question, ça :
float tx = -m_origin.x * sxc - m_origin.y * sys + m_position.x;
float ty = m_origin.x * sxs - m_origin.y * syc + m_position.y;
Et ça :
float tx = m_origin.x + tx;
float ty = m_origin.y + ty;
Ce ne serait pas la même chose ???
Pour moi un changement d'origine n'a toujours été qu'une translation.
En tout cas sur papier ça me donne la même chose.
-
Non, l'origine n'est pas qu'une translation. C'est l'origine de toute les autres transformations. Ce n'est pas équivalent.
-
Ok.
-
Bon finalement j'ai fait ma propre interface Transformable à laquelle j'ai rajouté des fonctions, et j'ai fait des méthodes que je redéfini si j'ai besoin de mettre à jour mon moteur physique quand je fais une transformation et que j'appelle dans ma propre interface Transformable.
Plutôt que de devoir ré-écrire tout le code dans toutes mes entités SFML-LIKE avec un sf::Transform pour chaque entité SFML-LIKE.
De plus j'ai besoin de connaitre la géométrie de mes entités avant de les dessiner afin de les mettre dans une grille, un quadtree ou bien un arbre binaire pour faire le furstrum culling. (Je n'utilise pas de graphe de scene.)
Je ne fais plus d'héritage à la place j'utilise une variable membre sf::Transform.
Et je fais hériter cette interface de toute les classes qui ont besoin de faire des transformations, je redéfini onRotation si par exemple j'ai besoin de mettre à jour la physique ou bien de faire une rotation sur des entités enfants d'un noeud.
Je trouve ça plus pratique.
PS : je posterai un exemple de code source plus loin.
-
Bon voici le code de ma propre interface transformable :
#ifndef TRANSF_ENTITY
#define TRANSF_ENTITY
class TransformableEntity {
public :
TransformableEntity(Vec2f position, Vec2f size, Vec2f origin) {
localBounds = FloatRect(position.x, position.y, size.x, size.y);
m_position = position;
m_size = size;
m_center = Vec2f (position.x + size.x * 0.5f, position.y + size.y * 0.5f);
m_origin = origin;
m_scale = Vec2f(1.f, 1.f);
needToUpdate = true;
inverseNeedToUpdate = true;
}
FloatRect getLocalBounds() {
return localBounds;
}
void setCenter(Vec2f center) {
Vec2f position = Vec2f (center.x - m_scale.x * m_origin.x, center.y - m_scale.y * m_origin.y);
Vec2f t = position - m_position;
move(t);
needToUpdate = true;
inverseNeedToUpdate = true;
}
Vec2f getCenter() {
return m_center;
}
void setPosition(Vec2f position) {
Vec2f t = position - m_position;
move(t);
needToUpdate = true;
inverseNeedToUpdate = true;
}
Vec2f getSize() {
return m_size;
}
Vec2f getPosition() {
return m_position;
}
void setRotation (float angle) {
m_rotation = static_cast<float>(fmod(angle, 360));
if (m_rotation < 0)
m_rotation += 360.f;
angle = -m_rotation * 3.141592654f / 180.f;
float cosinus = Math::cosinus(angle);
float sinus = Math::sinus(angle);
float sxc = cosinus * m_scale.x;
float sxs = sinus * m_scale.y;
float syc = cosinus * m_scale.x;
float sys = sinus * m_scale.y;
m_size.x = (sxc + sys) * localBounds.width;
m_size.y = (-sxs + syc) * localBounds.height;
needToUpdate = true;
inverseNeedToUpdate = true;
onRotate(angle);
}
void setScale(Vec2f scale) {
m_scale = scale;
float angle = -m_rotation * 3.141592654f / 180.f;
float cosinus = Math::cosinus(angle);
float sinus = Math::sinus(angle);
float sxc = cosinus * m_scale.x;
float sxs = sinus * m_scale.y;
float syc = cosinus * m_scale.x;
float sys = sinus * m_scale.y;
m_size.x = (sxc + sys) * localBounds.width;
m_size.y = (-sxs + syc) * localBounds.height;
needToUpdate = true;
inverseNeedToUpdate = true;
onScale(scale);
}
void scale(Vec2f s) {
setScale(m_scale * s);
}
void rotate (float angle) {
setRotation(m_rotation + angle);
}
void move (Vec2f t) {
m_position += t;
m_center += t;
needToUpdate = true;
inverseNeedToUpdate = true;
onMove(t);
}
void setOrigin(Vec2f origin) {
m_origin = origin;
needToUpdate = true;
inverseNeedToUpdate = true;
}
Vec2f getScale() {
return m_scale;
}
float getRotation() {
return m_rotation;
}
Vec2f getOrigin() {
return m_origin;
}
void setSize (Vec2f size) {
setScale(size / m_size);
needToUpdate = true;
inverseNeedToUpdate = true;
}
FloatRect getGlobalBounds() {
FloatRect globalBounds = getTransform().transformRect(localBounds);
}
const sf::Transform getTransform() const {
// Recompute the combined transform if needed
if (needToUpdate) {
float angle = -m_rotation * 3.141592654f / 180.f;
float cosine = static_cast<float>(std::cos(angle));
float sine = static_cast<float>(std::sin(angle));
float sxc = m_scale.x * cosine;
float syc = m_scale.y * cosine;
float sxs = m_scale.x * sine;
float sys = m_scale.y * sine;
float tx = -m_origin.x * sxc - m_origin.y * sys + m_position.x;
float ty = m_origin.x * sxs - m_origin.y * syc + m_position.y;
const_cast<TransformableEntity*>(this)->m_transform = sf::Transform( sxc, sys, tx,
-sxs, syc, ty,
0.f, 0.f, 1.f);
const_cast<TransformableEntity*>(this)->needToUpdate = false;
}
return m_transform;
}
const sf::Transform& getInverseTransform()
{
// Recompute the inverse transform if needed
if (inverseNeedToUpdate)
{
const_cast<TransformableEntity*>(this)->m_inverseTransform = getTransform().getInverse();
const_cast<TransformableEntity*>(this)->inverseNeedToUpdate = false;
}
return m_inverseTransform;
}
protected :
virtual void onRotate(float angle) {}
virtual void onScale(Vec2f s) {}
virtual void onMove(Vec2f t) {}
private :
FloatRect localBounds;
Vec2f m_position, m_size, m_center,m_scale,m_origin;
float m_rotation;
sf::Transform m_transform;
sf::Transform m_inverseTransform;
bool needToUpdate, inverseNeedToUpdate;
};
#endif // TRANSF_ENTITY
Mais il reste un soucis, avec ce code, je ne peux pas par exemple, pour un sprite, mettre sa position en fonction du coin supérieur gauche c'est à dire quand l'origine est le coin supérieur gauche de la tile, puis changer l'origine et faire les transformations autour du centre de la tile.
Je pense que je vais ré-écrire une classe Sprite se sera plus simple que de devoir faire un calcul en retirant la moitié de la taille de ma tile si je veux la positionner en foncton du coin supérieur gauche puis faire des transformations autour de son centre.
Sinon de temps en temps je me retrouve avec une tile inclinée à 45° ce qui est bizarre.
J'ai rien dit j'avais oublié d'initialiser m_rotation a 0.
Sinon quelque questions :
-Y a t'il moyen de rendre une classe abstraite même si elle n'a pas de méthode virtuelle pure ? (Comme en java.)
-Et si je veux pouvoir redéfinir les méthodes onRotate, on Scale et onMove mais je veux que seul mon interface puisse appelé ses méthodes, que dois je faire, déclarer ses méthode en privé ?
-
Bon finalement j'ai trouvé il suffisait de déclarer les méthodes virtuelles en privé et le constructeur en protected de ma classe transformable.
Bon bah il ne me reste plus qu'à changer ma classe Tile en utilisant un vertexarray plutôt que un sprite et se sera parfait. :)
Je me demande si je ne vais pas aussi remettre à jour la matrice à chaque transformation plutôt que à chaque getTransform histoire de pouvoir faire des transformations en changeant l'origine.