Bienvenue, Invité. Merci de vous connecter ou de vous inscrire. Avez-vous oublié d'activer ?

Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - Hypnéos

Pages: « Précédente 1 [2]
16
Graphique / Re : 2D isométrique, VertexArray
« le: Août 24, 2013, 02:57:27 pm »
J'ai fait quelques test avec openGL; à moins que la carte ne soit très ( trèèèèèès ) complexe, SFML est une meilleure solution.

Pourrais-tu nous donner une approximation de ce qu'il y aura à l'écran dans le jeu final ?

17
Graphique / Re : 2D isométrique, VertexArray
« le: Août 24, 2013, 01:47:15 am »
C'est ce que je voulais dire; mais tu as l'air d'avoir mieux compris que moi  ;D

Ce qui me soucie, c'est que si tu veut faire la moindre animation, il faudra soit reconstruire le chunk, soit en faire une copie par frame d'animation.

C'est un prix cher pour avoir de l'eau animée.  :-\


Je vais voir si je peux faire quelque chose avec openGL...

18
Graphique / Re : 2D isométrique, VertexArray
« le: Août 23, 2013, 11:56:49 pm »
Tu veux parler d'un système de "chunks", c'est-à-dire découper la map en zones de X blocks * X blocks ? :)
[...]
Actualiser les chunks visibles dans l'écran ? :) Mais en utilisant des VertexArrays ou une RenderTexture ?

Je pensait à quelque chose comme : VertexArray -> RenderTexture -> RenderWindow.
Pas la meilleure solution pour atteindre 60 FPS si on doit le répéter à chaque frame...

Je n'y connais absolument rien en shader, je préfère éviter :D

Sage décision, c'est une force puissante, mais difficile à maîtriser.
<insert Star-War quote>



Merci Laurent, j'avais oublié la doc  :-[.
Au fait, je n'ai pas vu de shaders dans les source; est-ce que je suis passé au-dessus, ou SFML n'en utilise pas ?

19
Projets SFML / Re : Émulation de CLI rétro. (basique)
« le: Août 23, 2013, 08:27:16 pm »

SFML 2.0 et C++11

Tu as plus d'informations sur l'erreur ?
Peut-tu m'envoyer le message d'erreur complet ?

20
Graphique / Re : 2D isométrique, VertexArray
« le: Août 23, 2013, 07:13:26 pm »

Le nombre de textures est en effet un problème.
Est-ce que tu as déjà une idée du nombre de textures qu'il y aura à l'écran?

Tu pourrais rendre ton terrain par "bloc" de (par exemple) 8 cases de coté?
Et actualiser seulement les blocs qui ont changés (personnages qui se déplacent, etc)

Une solution plus ... complexe ... pourrait être d'utiliser un shader... avec un paramètre "distance depuis la 'camera' "
Malheureusement (*) sf::Vertex ne permet pas d'ajouter des paramètres supplémentaires, donc il faudrait en venir à des "hacks" tels que :
  • utiliser une des valeurs non-utilisées ( canal alpha de la couleur ? ) pour paramètre.
    Problème : tu as peut-être envie de rendre invisible les objets qui bloquent la vue ?
  • Dériver une classe de sf::VertexArray et modifier la fonction draw()
    Problème : tu devras réécrire tout le stockage de la classe pour prendre en compte la nouvelle valeur plus(+) utiliser openGL directement dans la nouvelle méthode draw()  ( plus écrire un shader :'( )


<note d'après relecture :>

Les points que j'ai abordés sont très vagues et très risqués.
Je tiens aussi à dire que je n'ai quasiment aucune expérience dans ces domaines.

@Laurent :  Est-ce que les renderTextures peuvent être modifiés pour avoir un composant GL_DEPTH ?
( J'ai essayé de rechercher sur le forum, mais j'ai reçu une 'Database error'  >_< )

21
Graphique / Re : 2D isométrique, VertexArray
« le: Août 23, 2013, 01:06:26 pm »
Je ne sais pas si cela peut aider, mais les primitives d'un VertexArray sont rendues dans l'ordre dans lequel elles sont entrées.

donc, si tu enregistre les tuiles les plus éloignées de la caméra en premier, et les plus proches en dernier; elles devraient se superposer correctement.

Je ne suis pas sur à 100% du comportement d'openGL, mais je pense que ça devrait marcher...

22
Projets SFML / Émulation de CLI rétro. (basique)
« le: Août 21, 2013, 10:46:32 pm »
Je suis en train de développer une CLI rétro.

J'ai fait ce topic pour deux raisons:
  • D'abord, vérifier si le projet n'a pas de problèmes majeurs.
    Je vous invite à le tester sur votre ordinateur ( linux seulement, malheureusement ).
  • Ensuite, pour discuter de point de design qui m'ont l'air important:

Note : Le but de ce prototype est de reproduire une console, si possible en lui donnant l'air "rétro" ( env. 1980 ).

En codant ce projet, je me suis heurté à un problème, l'alignement.
Les ordinateur de l'époque n'utilisaient pas de polices à proprement parler; mais des bitmaps codant l'apparence graphique de chaque caractère, qui étaient copiées sur la sortie pixel-par-pixel, similaire à un tileset.
Le prototype ci-joint utilise des sf::Text, dont le comportement est dicté par la police, ce qui offre l'avantage de ne pas avoir  à ce soucier de l'alignement, ainsi que de gérer l'Utf automatiquement.
Par contre, cette solution requiert une police monospace ce qui assez difficile à trouver si on veut l'apparence correcte.La coloration du texte est aussi un possible problème.
L'utilisation d'un "tileset" permet un plus grand contrôle sur l'apparence du texte, mais a un fonctionnement plus complexe, demande une conversion entre les entrées (Utf-32) et la sortie (index de texture) et une moins grande flexibilité.

J'aimerai avoir vos avis sur cette question, vos expériences, ou des corrections si je me suis trompé.
Merci d'avoir lu jusqu'ici.  :)


EDIT : devrais-je poster ceci sur le forum anglophone aussi ?

Police : "F25 Bank Printer" par Volker Busse - F25 Digital Typeface Design sur Dafont

23
Projets SFML / Re : [C++] Strategic Wars
« le: Août 21, 2013, 03:44:23 pm »
Je viens de tester le jeu sous Linux avec Wine : Ça marche !   ;D

Très bon concept, je me suis bien amusé; même en jouant contre moi-même !

Quelques problèmes néanmoins; rien qui n'empêche de jouer par contre, bravo.
Certains sont peut-être dus à des problème venants de wine.

La génération du terrain est lente (quelques secondes) et la sortie d'erreurs est remplie de messages tels que :
Cannot set pixel (6001,2561201718) for image (width = 6400, height = 600)

J'ai été déçu par le fait que les bâtiments possèdent une barre de vie, mais ne prennent pas de dégâts. (pas encore implémenté ?)

Enfin, un tour se termine lors qu'une unité à tiré:
ce qui veut dire qu'il n'y a pas de limite de déplacement sur toutes les unités...
Je ne sais pas si c'est voulu, mais je suis déconcerté.  :-\


J'ai hâte de voir ce que ce projet va devenir  8)
Et encore une fois, bravo Malfrax!

24
Général / Re : Avis sur un Snake
« le: Juillet 14, 2013, 08:30:34 pm »
En effet,
j'ai limité l'accès à un mois pour ne pas encombrer les serveurs, je le ré-upload actuellement.

[EDIT]
 voilà le lien http://pastebin.com/e0WHx4fV
Dis moi ce que tu en pense.

25
Général / Avis sur un Snake
« le: Juin 07, 2013, 04:11:08 pm »
Bonjour tout le monde.

J'ai récemment codé un snake et, après l'avoir raffiné,
je m'en suis senti suffisamment fier pour l'exposer à l'opinion publique.

Je fournis le code source qui devrait fonctionner sur toutes les plateformes.
ici


rond rouge : nouriture
  • augmente la longueur de 1
  • ajoute 10 points au score
machin jaune : spécial
  • augmente le score d'un dixième de sa valeur
  • Par trois fois, au hasard
    • augmente la taille de 1
    • fait apparaître un obstacle et augmente le score de 1
    • augmente la taille de 2 et réduit le score de 1

losange blanc : !! OBSTACLE !!


Le score est affiché en haut à droite et clignote durant quelques secondes à la fin de la partie.
La difficulté n'est pas très élevée.
Bon jeu ^^

26
Ta méthode Moteur::boucleJeu() ne gère pas le temps dans le while.

rajouter un sf::sleep devrait régler le problème.
(et soulager ton processeur  :) )

Voici un lien vers le tutoriel correspondant : Tutoriel - Système - Gérer le temps.
Jette aussi un coup d'œil à sf::Clock.


EDIT :

Pour être plus précis :

while(m_fenetre->isOpen()){

//stuff

}

s’exécutera le plus vite possible.

sf::sleep() fait une pause dans l'exécution du programme :
/!\ Attention/!\
sf::sleep() prends un sf::Time en argument avec la SFML2.

while(m_fenetre->isOpen()){

//stuff

sf::sleep(sf::seconds(1.f/60.f))

}

Avec le code ci-dessus tes FPS seront légèrement inférieures à 60 du à la durée d’exécution de //stuff
pour corriger ça je te propose de chronométrer la durée de ta boucle et de l'ôter à sf::sleep() :

sf::Clock chrono;

while(m_fenetre->isOpen()){

//stuff

sf::sleep(sf::seconds(1.f/60.f - chrono.getElapsedTime().asSeconds()));
chrono.restart();

}

Tu peux désormais considérer qu'il se passe toujours la même durée entre deux frames;

/!\ Attention /!\
Si ton code met plus de 1/60ème de seconde à s’exécuter sf::sleep() ne servira à rien;
tu devras considérer un FPS plus bas. (1/20ème est encore correct pour un jeu ;) )

Protip  8)

const sf::Time FRAME__TIME = sf::seconds(1.f/60.f);

float time_delta; //temps écoulé durant la dernière frame (en secondes)

while(m_fenetre->isOpen()){

//stuff

time_delta = chrono.getElapsedTime().asSeconds();
sf::sleep(FRAME_TIME - chrono.restart());

}

sf::Time possède un opérateur - ;
sf::Clock::restart() retourne un sf::Time ;
utilise les pour simplifier ton code;

Et time_delta permet d'obtenir des mouvements "parfaitement" chronométrés quelque-soit les FPS :

déplacement en 1 seconde * fraction de seconde = déplacement durant une fraction de seconde


PS : J'en ai peut-être fait un peu trop.
J’espère avoir été utile.
et bonne journée. :)

Pages: « Précédente 1 [2]