1
Projets SFML / Re : Iluzioj Chess
« le: Août 21, 2013, 03:23:32 pm »
Voilà, j’ai modifié en y ajoutant un petit screenshot de l’application 
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.
Pages: [1]
2
Projets SFML / Iluzioj Chess
« le: Août 21, 2013, 09:45:55 am »
Hey!
J’ai programmé il y a quelques temps un jeu d’échecs avec SFML 2 (RC à l’époque, mais ça reste compatible avec la 2.1).
J’ai créé un topic sur le SdZ :
http://www.siteduzero.com/forum/sujet/jeu-d-echecs-iluzioj-chess
Reprenons la même description :
Un petit screenshot :
Le projet est accessible sur github :
https://github.com/Niolak/IluziojChess
Voilà, n’hésitez pas à me donner votre avis sur le jeu, sur le code. Et comme je le dis sur le SdZ, l’IA me semble bien mauvaise par rapport à ce que j’attendais de cet algorithme, donc j’ai sans doute fait une erreur stupide. Si l’envie vous prend d’analyser le code et de chercher cette erreur (ou en tout cas la raison pour laquelle l’IA est si mauvaise), et que vous arrivez à améliorer notablement l’IA sans grands changements, n’hésitez pas à me faire part de modifications à apporter !
À bientôt !
J’ai programmé il y a quelques temps un jeu d’échecs avec SFML 2 (RC à l’époque, mais ça reste compatible avec la 2.1).
J’ai créé un topic sur le SdZ :
http://www.siteduzero.com/forum/sujet/jeu-d-echecs-iluzioj-chess
Reprenons la même description :
Citer
Le programme fait jouer l’utilisateur contre une IA, implémentant l’algorithme negamax avec élagage alpha-beta. Pour représenter le plateau et les différents coups, j’ai utilisé les bitboards (Partant du principe qu’un échiquier est composé de 64 cases, on représente le plateau avec différents bitboards, un bitboard n’étant rien d’autre qu’un entier de 64 bits où chaque bit correspond à une case de l’échiquier).
Bien que l’option n’est pas encore accessible pour l’utilisateur, le code source est suffisamment modulable pour définir la nature de chaque joueur : humain ou intelligence artificielle (Deux "intelligences" possibles : aléatoire ou intelligence un peu plus perfectionnée). Pour tester, il suffit de changer dans le fichier main.cpp les deux lignes correspondant à la déclaration des joueurs.
Un petit screenshot :
Le projet est accessible sur github :
https://github.com/Niolak/IluziojChess
Voilà, n’hésitez pas à me donner votre avis sur le jeu, sur le code. Et comme je le dis sur le SdZ, l’IA me semble bien mauvaise par rapport à ce que j’attendais de cet algorithme, donc j’ai sans doute fait une erreur stupide. Si l’envie vous prend d’analyser le code et de chercher cette erreur (ou en tout cas la raison pour laquelle l’IA est si mauvaise), et que vous arrivez à améliorer notablement l’IA sans grands changements, n’hésitez pas à me faire part de modifications à apporter !
À bientôt !
3
Graphique / Re : Plantage lors de créations et destructions successives de fenêtre
« le: Août 23, 2012, 07:58:02 am »
Exact, je n’avais pas fait attention pour l’anglais, désolé.
(Et de rien, c’est normal de faire remonter les bugs ^^)
(Et de rien, c’est normal de faire remonter les bugs ^^)
4
Graphique / Re : Plantage lors de créations et destructions successives de fenêtre
« le: Août 22, 2012, 09:04:48 am »
Ok, voilà qui est fait :
https://github.com/SFML/SFML/issues/275
(J’ai d'ailleurs encore réduit le code minimal reproduisant l'erreur)
https://github.com/SFML/SFML/issues/275
(J’ai d'ailleurs encore réduit le code minimal reproduisant l'erreur)
5
Graphique / Plantage lors de créations et destructions successives de fenêtre
« le: Août 21, 2012, 03:03:35 pm »
Bonjour,
Je viens de découvrir un bug (enfin je crois) lorsqu’on détruit puis recrée des fenêtres (sous Linux).
J’obtiens l’erreur suivante, de manière un peu aléatoire :
Un code minimal reproduisant le problème :
PS : j’utilise la version GIT de la SFML, que j’ai mise à jour tout à l’heure.
Je viens de découvrir un bug (enfin je crois) lorsqu’on détruit puis recrée des fenêtres (sous Linux).
J’obtiens l’erreur suivante, de manière un peu aléatoire :
Citer
X Error of failed request: GLXBadContext
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Serial number of failed request: 25
Current serial number in output stream: 30
Un code minimal reproduisant le problème :
#include <SFML/Graphics.hpp>
int main(int argc, char** argv)
{
while(true)
{
sf::RenderWindow test(sf::VideoMode(800,600), "Test");
test.clear();
test.display();
}
}
int main(int argc, char** argv)
{
while(true)
{
sf::RenderWindow test(sf::VideoMode(800,600), "Test");
test.clear();
test.display();
}
}
PS : j’utilise la version GIT de la SFML, que j’ai mise à jour tout à l’heure.
6
Graphique / Re : [Aide pour un shader] Associer une profondeur à une couleur
« le: Juin 30, 2012, 07:25:54 pm »
Personne pour m’aider ? 
7
Graphique / [Aide pour un shader] Associer une profondeur à une couleur
« le: Juin 24, 2012, 10:30:49 am »
Salut !
Je suis en train de me pencher sur les shaders pour une future application, et je n’arrive pas à faire ce que je veux…
Mon objectif : faire en sorte que quel que soit l’ordre d’affichage, les pixels dont la composante verte est la plus élevée soit au dessus de tout.
J’ai donc créé ces shaders :
vertexShader
fragmentShader
Un code minimal de SFML pour tester les shaders :
Avec ce shader, je pensais que le triangle vert serait au dessus du bleu, ce qui n’est pas le cas…
Du coup, je veux bien un petit coup de main s’il vous plaît :p
Remarque : en ajoutant le depthBuffer au sf::ContextSettings, je pensais que ça résoudrait le problème, mais apparemment non.
Autre remarque : le code SFML que je donne est un code minimal, il va de soi que dans cet exemple, il suffit de dessiner les objets dans l’autre ordre. Toutefois, dans mon vrai programme, chaque vertexArray comporte des pixels plus ou moins verts.
Merci d’avance
Je suis en train de me pencher sur les shaders pour une future application, et je n’arrive pas à faire ce que je veux…
Mon objectif : faire en sorte que quel que soit l’ordre d’affichage, les pixels dont la composante verte est la plus élevée soit au dessus de tout.
J’ai donc créé ces shaders :
vertexShader
void main(void)
{
vec4 position = gl_ModelViewMatrix * gl_Vertex;
position.z = gl_Color.g;
gl_Position = gl_ProjectionMatrix * position;
gl_FrontColor = gl_Color;
}
{
vec4 position = gl_ModelViewMatrix * gl_Vertex;
position.z = gl_Color.g;
gl_Position = gl_ProjectionMatrix * position;
gl_FrontColor = gl_Color;
}
fragmentShader
void main(void)
{
gl_FragDepth = gl_Color.g;
gl_FragColor = gl_Color;
}
{
gl_FragDepth = gl_Color.g;
gl_FragColor = gl_Color;
}
Un code minimal de SFML pour tester les shaders :
#include <SFML/Graphics.hpp>
void processEvent(sf::RenderWindow& p_window);
int main()
{
sf::ContextSettings contextSettings(0xFF, 0, 0xFF);
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window", sf::Style::Default, contextSettings);
sf::VertexArray array1(sf::Triangles, 3);
array1[0].position.x = 0;
array1[0].position.y = 0;
array1[0].color = sf::Color::Green;
array1[1].position.x = 30;
array1[1].position.y = 0;
array1[1].color = sf::Color::Green;
array1[2].position.x = 0;
array1[2].position.y = 100;
array1[2].color = sf::Color::Green;
sf::VertexArray array2(sf::Triangles, 3);
array2[0].position.x = 10;
array2[0].position.y = 20;
array2[0].color = sf::Color::Blue;
array2[1].position.x = 50;
array2[1].position.y = 20;
array2[1].color = sf::Color::Blue;
array2[2].position.x = 20;
array2[2].position.y = 120;
array2[2].color = sf::Color::Blue;
sf::Shader shader;
shader.loadFromFile("vertexShader", "fragmentShader");
while (window.isOpen())
{
processEvent(window);
window.clear();
window.draw(array1, sf::RenderStates(&shader));
window.draw(array2, sf::RenderStates(&shader));
window.display();
}
return EXIT_SUCCESS;
}
void processEvent(sf::RenderWindow& p_window)
{
sf::Event event;
while (p_window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
p_window.close();
}
}
void processEvent(sf::RenderWindow& p_window);
int main()
{
sf::ContextSettings contextSettings(0xFF, 0, 0xFF);
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window", sf::Style::Default, contextSettings);
sf::VertexArray array1(sf::Triangles, 3);
array1[0].position.x = 0;
array1[0].position.y = 0;
array1[0].color = sf::Color::Green;
array1[1].position.x = 30;
array1[1].position.y = 0;
array1[1].color = sf::Color::Green;
array1[2].position.x = 0;
array1[2].position.y = 100;
array1[2].color = sf::Color::Green;
sf::VertexArray array2(sf::Triangles, 3);
array2[0].position.x = 10;
array2[0].position.y = 20;
array2[0].color = sf::Color::Blue;
array2[1].position.x = 50;
array2[1].position.y = 20;
array2[1].color = sf::Color::Blue;
array2[2].position.x = 20;
array2[2].position.y = 120;
array2[2].color = sf::Color::Blue;
sf::Shader shader;
shader.loadFromFile("vertexShader", "fragmentShader");
while (window.isOpen())
{
processEvent(window);
window.clear();
window.draw(array1, sf::RenderStates(&shader));
window.draw(array2, sf::RenderStates(&shader));
window.display();
}
return EXIT_SUCCESS;
}
void processEvent(sf::RenderWindow& p_window)
{
sf::Event event;
while (p_window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
p_window.close();
}
}
Avec ce shader, je pensais que le triangle vert serait au dessus du bleu, ce qui n’est pas le cas…
Du coup, je veux bien un petit coup de main s’il vous plaît :p
Remarque : en ajoutant le depthBuffer au sf::ContextSettings, je pensais que ça résoudrait le problème, mais apparemment non.
Autre remarque : le code SFML que je donne est un code minimal, il va de soi que dans cet exemple, il suffit de dessiner les objets dans l’autre ordre. Toutefois, dans mon vrai programme, chaque vertexArray comporte des pixels plus ou moins verts.
Merci d’avance
8
Discussions générales / SFML2 RC - Frametime ?
« le: Juin 10, 2012, 12:52:47 pm »
Salut !
Jusqu’à maintenant, il était conseillé d’utiliser GetFrameTime() pour avoir un résultat précis. Apparemment, cette méthode n’existe plus. Peut-on la retrouver ailleurs sous un autre nom, dans une autre classe ? Est-ce un oubli ou un choix ?
Jusqu’à maintenant, il était conseillé d’utiliser GetFrameTime() pour avoir un résultat précis. Apparemment, cette méthode n’existe plus. Peut-on la retrouver ailleurs sous un autre nom, dans une autre classe ? Est-ce un oubli ou un choix ?
Pages: [1]