Messages

1

Graphique / Re : Re : Problème de positionnement avec sf::VertexArray

« le: Avril 24, 2013, 12:01:43 pm »

Hum... C'est à dire ?
Un vertexArray avec plein de Vectex à chaque intersection ?
Je trouvais plus économique de tracer des droites (2*43*2 points) plutôt que de spécifier toutes les intersections (43^2 points)

Non, tu gardes exactement la même définition avec les mêmes lignes, mais au lieu de les regrouper 1 par 1 tu les mets toutes dans le même vertex array et tu les dessines d'un coup. C'est un peu ça le but du vertex array à la base

Ahhh, oki, je comprend mieux.
En effet, ça marche très bien

void MapView::draw(sf::RenderTarget& target, sf::RenderStates states) const {
    for(auto tileIt = this->mapLvl0.begin(); tileIt != this->mapLvl0.end(); ++tileIt) {
        target.draw(**tileIt, states);
    }
   
    for(auto tileIt = this->mapLvl1.begin(); tileIt != this->mapLvl1.end(); ++tileIt) {
        target.draw(**tileIt, states);
    }
   
    sf::VertexArray vArray(sf::Lines, (target.getSize().x / 16 + 1)*4);
    for(unsigned int i = 0; i <= target.getSize().x / 16; i++) {
        vArray[2*i].position = sf::Vector2f(i*16+0.5f,0);
        vArray[2*i+1].position = sf::Vector2f(i*16+0.5f,target.getSize().y);
        vArray[2*i].color = sf::Color::White;
        vArray[2*i+1].color = sf::Color::White;  
        //Debug::info << NEW_ENTRY << 2*i << ":" << 2*i+1 << std::endl;
    }
    unsigned int offset = 2 * (target.getSize().x / 16 + 1);
    for(unsigned int i = 0; i <= target.getSize().y / 16; i++) {
        vArray[offset+2*i].position = sf::Vector2f(0,i*16+0.5f);
        vArray[offset+2*i+1].position = sf::Vector2f(target.getSize().x,i*16+0.5f);
        vArray[offset+2*i].color = sf::Color::White;
        vArray[offset+2*i+1].color = sf::Color::White;
        //Debug::info << NEW_ENTRY << offset+2*i << ":" << offset+2*i+1 << std::endl;
    }
    target.draw(vArray, states);
}

Merci Laurent !
Tout marche nickel

2

Graphique / Re : Re : Problème de positionnement avec sf::VertexArray

« le: Avril 24, 2013, 11:36:14 am »

En fait, comme les lignes font un pixel d'épaisseur et que leurs coordonnées représentent la ligne médiane (i.e. quand tu dessines il y a 0.5 pixels d'un côté de ta coordonnée, et 0.5 de l'autre), tu peux en déduire que pour remplir une ligne/colonne de pixels, il faut placer la ligne au centre des pixels, donc utiliser des demi-coordonnées.

Ahhh merci
ça explique donc le pourquoi du comment XD

sf::VertexArray vArray(sf::Lines, 2);

Arg! sf::VertexArray est un std::vector<sf::Vertex>. Ca ne te viendrait pas à l'idée de faire plein de new/delete juste pour allouer 2 sf::Vertex, n'est-ce pas ?

Remplace par ça, ce sera beaucoup plus léger :

sf::Vertex vArray[2];
...
mapWindow.draw(vArray, 2, sf::Lines);

oops :p
En effet, c'est pas top.
Pour le moment, j'essaye juste de comprendre comment marche les Vertex. (jamais fais d'opengl moi)

Et sinon, pourquoi plein de petits vertex arrays plutôt qu'un gros avec tout dedans ?

Hum... C'est à dire ?
Un vertexArray avec plein de Vectex à chaque intersection ?
Je trouvais plus économique de tracer des droites (2*43*2 points) plutôt que de spécifier toutes les intersections (43^2 points)

3

Graphique / [Résolu]Problème de positionnement avec sf::VertexArray

« le: Avril 24, 2013, 11:09:31 am »

Bonjour,

Je viens vous soumettre un problème (ou bug potentiel ?) avec sf::VertexArray
J'essaye de quadriller ma fenêtre avec des carrés blancs de 16pixels par 16.
Pour ça, j'utilise un sf::VertexArray(sf::Lines,2) pour dessiner des lignes horizontales et verticales.

Ma fenêtre fais 673 pixels (=16px*42+1)
Je devrais donc réussir à caser 43 lignes horizontales et 43 verticales.

Pas de problème pour les lignes horizontales. Par contre, pour les lignes verticales, tout est décalé de 1 pixel : la ligne verticale à x=0 ne s'affiche pas et la dernière ligne à s'afficher à pour coordonnée x = 671 au lieu de 672.

Voir le problème sur cet image (j'ai mis un fond rouge uniforme pour bien voir) :


J'ai refait un code minimal pour illustrer le problème.
Le style de la fenêtre est sf::Style::None pour qu'on puisse bien voir le problème.
La touche Echap quitte l'appli.

J'utilise SFML2 (RC) compilé avec MinGW 7.4
J'utilise la norme C++11

#include <iostream>
#include <SFML/Graphics.hpp>

int main(int argc, char** argv) {
    //673 = 16*42+1
    sf::RenderWindow mapWindow(sf::VideoMode(673, 673, 32), "Map", sf::Style::None);
    mapWindow.setFramerateLimit(10);

    while (mapWindow.isOpen())
    {
        sf::Event event;
        while(mapWindow.pollEvent(event))
        {
            // Close Window (press escape)
            if (event.type == sf::Event::Closed || ((event.type == sf::Event::KeyPressed) && (event.key.code == sf::Keyboard::Escape)))
                mapWindow.close();

            // Mouse Debug
            // Coin haut gauche : (0,0)
            // Coin bas droite  : (672,672)
            if(event.type == sf::Event::MouseMoved)
                std::cout << "x=" << sf::Mouse::getPosition(mapWindow).x << " ; y=" << sf::Mouse::getPosition(mapWindow).y << std::endl;
        }
       
        // Draw vertical lines
        for(unsigned int i = 0; i <= mapWindow.getSize().x / 16; i++) {
            sf::VertexArray vArray(sf::Lines, 2);
            vArray[0].position = sf::Vector2f(i*16,0);
            vArray[1].position = sf::Vector2f(i*16,mapWindow.getSize().y);
            vArray[0].color = sf::Color::White;
            vArray[1].color = sf::Color::White;  
            mapWindow.draw(vArray);
        }

        // Draw horizontal lines
        for(unsigned int i = 0; i <= mapWindow.getSize().y / 16; i++) {
            sf::VertexArray vArray(sf::Lines, 2);
            vArray[0].position = sf::Vector2f(0,i*16);
            vArray[1].position = sf::Vector2f(mapWindow.getSize().x,i*16);
            vArray[0].color = sf::Color::White;
            vArray[1].color = sf::Color::White;  
            mapWindow.draw(vArray);
        }
       
        // Display Window
        mapWindow.display();
        mapWindow.clear();
    }
   
    return 0;
}
 

C'est peut-être moi qui utilise mal le sf::vertexArray, il suffit que je rajoute un +1 lorsque je dessine mes lignes verticales, mais je ne trouve pas ça très logique.

++
Black Templar

4

Général / Re : Problème affichage sprites

« le: Avril 24, 2013, 12:35:11 am »

Salut,

En effet, c'est assez crade.
Tu as plein d'attribut qui n'ont pas lieu d'être (par exemple : y, x, yScreen, finX, ind, indR, indDX, etc.)
Vire les. Tu peux très bien les créer uniquement dans les fonctions qui en ont besoin. Rien ne sert de les garder en mémoire.

Ton problème vient surement de la méthode Screen::chargementLvl.
A la fin de la méthode, tu as un bout de code qui ne sert à rien, vire le !

for (int j(0); j<fichierLvl[0].size(); j++)
{
        screen[j][0].SetPosition(x,y);
        xScreen[j][0]=x;
        x+=38;
}

Ton soucis viens de là !
Ta variable "y" n'est pas réinitialisé ! Donc tu va positionner tes tiles [j][0] (donc la première ligne de tiles) hors de l'écran.


++
Black Templar

5

Général / Re : Re : Tile Mapping et structure de donnée

« le: Avril 23, 2013, 07:46:03 pm »

Perso j'utiliserai un vector de zone. Chaque zone connaitrait la(les) zone(s) qui lui sont accolé et les chargerait.
un petit schémas vite fait pour expliquer.

0   Z1 Z2
Z3 Z4  0
Z5  0   0

les Zx correspondent aux zone pleines et les 0 des zones vident.
Si mon perso se trouvent dans la zone Z1 je charge Z2 et Z4 mais ne dessine que Z1.
Si mon perso est en Z2 je ne charge que Z1 et dessine Z2.
Et ainsi de suite. Chaque zone connait sa ou ses voisines.

Oui, j'avais bien compris ça.
ça serait assez efficace sur une map comme celle de mon poste précédent.
Par contre, pour une map plus complexe, ça risque d'être moins trivial.
La question : est-ce que j'ai besoin d'avoir une map complexe ou non.
En tout cas je vais implémenter ton idée pour voir !

Ou alors j'utiliserais un tableau 2D de pointeurs vers des Zones et les zones vident je les mettrai à NULL.

Hum. Aussi. On perdrait juste 4 octets par case non utilisé (pour le pointeur), ce qui est quedale

6

Général / Re : Re : Tile Mapping et structure de donnée

« le: Avril 23, 2013, 03:14:54 pm »

Pour mieux comprendre ce que je souhaite faire :
J'ai une map "à ciel ouvert" comme celle-ci : http://www.vgmaps.com/Atlas/GB-GBC/Pokemon-GSC-Kanto.png
Avec un tableau2D (ou vector), je prend trop de place en mémoire (les zones blanches sont inutiles, mais bel et bien stocké)

Pourquoi ne pas utiliser un tableau 2D de Zones ( ou un std::vector avec certains calculs cela revient au même) et définir une zone comme étant une tilemap.

Intéressant.
ça permet de ne pas consommer trop de mémoire inutilement (si les tileMap sont bien découpés).
Par contre, lorsque le perso arrive au bord d'une tilemap, il faut charger la seconde en mémoire et gérer les deux tilemap en même temps... ça complique tout de même un peu les choses.

Pour résumer ce prendre la tête maintenant est une bonne chose mais pas forcément utile au vue de nos machines actuelles. Code comme tu le sens et si y a besoin d'optimiser regarde ce que tu peux faire à ce moment là.

Je suis d'accord, si une implémentation ne me convient pas, je pourrais toujours recoder le modèle.
Mais bon, autant implémenter directement ce qui me semble le mieux.


Merci pour ta réponse.
Je vais déjà commencer à coder l'éditeur en stockant les tiles dans une liste chainée. Je pourrais ainsi me rendre compte des perfs.

7

Général / Tile Mapping et structure de donnée

« le: Avril 23, 2013, 10:03:36 am »

Bonjour à tous,

Je souhaite me mettre au "Game Programming" et j'ai envie de commencer par étudier la technique de TileMapping pour un RPG style Pokémon ou Zelda.

Il y a quelques temps, j'ai déjà fait un Mario et un Packman avec cette technique. Rien de très compliqué : je stockais la map dans un tableau 2D.

Mon soucis, c'est qu'avec un jeu style Zelda, c'est que la map peut vite devenir très grande et elle n'est pas rectangulaire, mais de forme indéterminée.
C'est pourquoi je recherche une structure de donnée adaptée à ce type de map.

* Avec un tableau 2D, je gâche beaucoup de mémoire.

* J'ai donc pensé à une structure d'arbre quadratique (ou quadrilatère, je ne sais pas comment ça s'appelle) : chaque noeud (tile) possède un pointeur vers ses 4 voisins connexes. Ainsi, on peut dessiner à l'écran le rendu en utilisant un algo de diffusion.
Avantage, on ne gâche pas de mémoire, l'affichage est super efficace.
Le soucis, c'est que la création de la map avec un éditeur de map n'est pas trivial... (l'utilisateur peut ajouter les tiles comme bon lui semble). La génération de la map demande donc beaucoup de calcul.

* J'ai pensé à une autre solution qui serait de stocker chaque tile dans une liste (chainée).
On ne consomme pas de mémoire inutilement, mais pour l'affichage, on est obligé de parcourir l'intégralité de la liste pour savoir quelle tile afficher... donc perte de temps...
Pour le générateur de map par contre, c'est super simple à concevoir ainsi

J'ai donc 3 méthodes :

• Tableau 2D : Gâche de la mémoire, très rapide à afficher
• Arbre quad : Pas de gâchis de mémoire, très rapide à afficher, mais conception de la map ardu
• Liste chainée : Pas de gâchis de mémoire, plus long à l'affichage

Je les implémenterais bien toutes les trois pour comparer les perfs en espace et en temps, mais je voulais d'avoir l'avis d'experts
Car comme le tileMapping est un sujet largement rependu, je suis sûr qu'il existe des structures de données plus utilisés que d'autres


Une astuce pourrait être d'utiliser une autre structure de donnée (liste chainée) pour l'éditeur de map, puis compilé la map pour qu'elle soit facilement lue par le jeu qui lui utilisera une structure d'arbre quad.

Qu'en pensez-vous ?
Black Templar

8

Général / Re : SFML et gestion des évènements

« le: Novembre 12, 2012, 11:37:30 am »

Ok, ça marche.

Je continue à faire mes recherche, mais de mon côté non plus, je n'ai rien trouvé.
Du coup, je pense que je vais me faire plaisir à coder tout ça

EDIT : par contre, aucune discussion sur le forum ne remonte avant 2012 Oo
Pourtant j'étais sur que le forum était déjà bien actif en 2007 

9

Général / SFML et gestion des évènements

« le: Novembre 12, 2012, 11:25:21 am »

Bonjour à tous,

Je souhaiterai refaire un gestionnaire d’événements pour SFML, un peu à la javascript.
C'est à dire que j'aimerais organiser tout ce qui est affiché à l'écran sous la forme d'un arbre de parenté. Les enfants étant affichés par dessus les parents. Chacun de ces éléments seraient à l'écoute d’événements (mouse up/down, focus/blur, mouse enter/leave, etc.)

Lorsqu'un événement se déclenche pour l'un de ces objets, il exécute les fonctions callbacks que l'utilisateur aura associés à celui-ci (listeners).

J'aimerai faire une propagation d’événement à la javascript, c'est à dire, avoir une phase de capture que déclenchera certains listeners de la racine (écran global) aux feuilles (enfants) ainsi qu'une phase de bubbling qui fera remonter l’événement d'une feuille vers la racine.


Ce gestionnaire d'événement à plusieurs avantages par rapport à la gestion classique des événements via SFML :

• Avoir un code plus lisible : fini l'énorme switch pour interpréter l'événement reçu ! Le gestionnaire d'événement s'occupera de déclencher automatiquement les bons callback
• Simplifier les événements plus complexes : l'événement focus sera automatiquement géré, etc.
• Cela permettra simplifier le développement de bibliothèques graphiques GUI (avec la gestion des callback, du focus, etc., il sera très simple de gérer des boutons, des textbox, de coder une console, etc.)[\li]
  

Le but ici, n'est pas de refaire une bibliothèque GUI, mais de simplifier la gestion des événements sous SFML.
C'est tout de même plus simple à mon sens, dans un jeu, d'avoir un coffre au trésor sur lequel on écoute l'événement 'onClick' et qui déclenche automatiquement la bonne fonction lorsque l'on clique sur cet objet


Ma question, c'est est-ce que ça a déjà été codé pour SFML ?
Parce que si ça a déjà été fait, ça ne sert à rien que je réinvente la roue ^^

Sinon, je pourrais alors commencer à penser comment je vais faire ça (est-ce que le gestionnaire d'événement doit gérer tous les sprites ou alors juste les objets héritant de clickable ? etc.)