Messages

1

Système / Re : [Clock/Time] Quelle précision quand on ne restart pas ?

« le: Mars 18, 2014, 10:28:42 am »

Comment peux-tu compter jusqu'à six sur tes doigts alors que tu n'as que cinq doigts à ta main ? En utilisant deux mains

De la même façon, un processeur 32 bits utilisera deux registres 32 bits pour représenter et calculer un nombre 64 bits.

2

Système / Re : comment fonctionne les evenements?

« le: Décembre 07, 2013, 01:21:57 pm »

Alors il y a deux choses que tu dois savoir, la première c'est que ton ordinateur est extrêmement rapide comparé à la vitesse prise pour une condition, il fait des dizaines de millions de conditions à la seconde, ce n'est pas en en enlevant cinq que tu vas changer quoi que ce soit.

La seconde, c'est que les switch sont généralement implémentés sous la forme de jump table, autrement dit plutôt que de mettre une condition par cas, le compilateur va générer une table contenant les adresses d'exécution pour chaque cas, et sauter directement au bon endroit.
Autrement dit, un switch avec dix cas et un avec un millier de cas vont s'exécuter à la même vitesse.

Honnêtement, ne t'embête pas avec les performances de ton programme, il faudra que tu fasses bien des choses avant de devoir t'en soucier, et d'ailleurs il faut toujours faire un programme qui fonctionne avant de chercher à l'optimiser (Uniquement dans le cas où c'est nécessaire !).

3

Suggestions de nouvelles fonctionnalités / Re : Simplification de Window::isOpen()

« le: Août 15, 2013, 12:44:17 pm »

J'ai eu l'occasion de faire un benchmark fait par une dizaine de personnes récemment : http://www.siteduzero.com/forum/sujet/moteur-de-jeu-nazara-engine-69732?page=20#message-84597382

On retrouve souvent ceci, lorsque l'instancing est activé, et que le CPU doit faire moins de choses que le GPU, window.Display (SwapBuffers) prend alors bien plus de temps (25ms par exemple, si ça ce n'est pas du bloquant ^^), alors que si l'instancing est désactivé, le Swap est presque immédiat (200us).

J'en ai déduit que le GPU n'attend pas, et se lance immédiatement dans l'exécution des commandes, avec l'instancing, le CPU a terminé avant le GPU et se met donc à l'attendre. Sans instancing, le CPU passe plus de temps sur les commandes, suffisamment pour que le GPU ait le temps de les terminer avant que le CPU ne passe à SwapBuffers, qui n'effectue dès lors qu'un swap, sans devoir attendre la carte graphique.

De plus, si je ne dis pas de bêtises, les moteurs 3D sont basés sur cette exécution simultanée (Rien que les query sont basées sur ce principe).

4

Suggestions de nouvelles fonctionnalités / Re : Re : Simplification de Window::isOpen()

« le: Août 15, 2013, 02:39:09 am »

Juste pour la petite histoire, l'ordre optimal serait même celui-ci :

display()
...
update()
...
clear()
draw()

Ce qui revient au bon vieux

update()
...
clear()
draw()
display()

... car lors de l'appel à display(), le GPU se "met en route" et exécute tout le boulot qui a potentiellement été mis en attente par les appels précédents à draw(). Donc après display(), si le CPU attaque directement par une instruction graphique, il va devoir attendre que le GPU ait terminé et donc bloquer à ne rien faire. Alors que si le CPU s'occupe de choses qui n'impliquent pas le GPU pendant ce temps, les deux peuvent  tourner en parallèle, d'où un gain de temps.

Sauf que l'appel à "display" entraîne un glFinish implicite, bloquant par nature.
Et de toute façon, c'est déjà parallélisé, le GPU tourne en même temps que le CPU lui donne des instructions, l'idéal serait alors de faire les gros calculs CPU après le draw()

Bon en revanche ça introduit une frame de latence pour le joueur, ce qui peut avoir son importance selon le type de jeu.

5

Projets SFML / Re : [jeu 3d] Pigami

« le: Juillet 12, 2013, 12:53:10 am »

Est-ce que tu utilises la SFML 1.x ?

Parce que je n'arrive pas à lancer le jeu, la fenêtre n'apparaît tout simplement pas.

Et j'ai une carte AMD

6

Projets SFML / Re : Un Miniminijeu à 0€! ;)

« le: Mai 16, 2013, 01:22:04 am »

Salut,

C'est pas pour critiquer, mais pourquoi changer le titre du topic comme ça et mettre "un minijeu à 0€" ?
L'argument monétaire on s'en tape, d'autant plus que tu critiques ton jeu avant même qu'on le teste.
Si tu veux de l'aide de la part de la communauté afin d'améliorer ta façon de coder tu t'es trompé de rubrique. Si par contre tu veux des testeurs, donne nous envie un minimum de le tester...
Là pour le coup, le style, l'écriture du post, et le .exe directement en téléchargement ça fait pas mal penser à une tentative de piratage.

Bref, si je me trompe je m'excuse, mais faut avouer que c'est louche.

EDIT : à priori le fichier est clean http://vscan.novirusthanks.org/analysis/ea9f884f79831743f563703f1f0faec8/Z2FtZTEtZXhl/.

Pas la peine de répondre comme ça, il débute et veut présenter son premier programme, ne sommes-nous pas tous passés par là ?

7

Graphique / Re : Taille d'un sf::Vertex

« le: Mai 11, 2013, 12:40:33 pm »

Mon premier post contenait "par exemple", mon second "sensibilisation".

Faut arrêter de déconner, j'ai pas dis qu'on ne pouvait en faire qu'un nombre X par seconde, j'ai dis que c'était lourd et j'ai présenté un exemple qui, en comptant 50us par allocation, montrait que tu te retrouvais rapidement limité.

Au passage, j'ai aussi dit dans mon premier post que ça variait beaucoup, et ça varie tellement que j'ai préféré enlever mes chiffres du dernier post.

Edit: Gros objets ? Mes tests se sont basé sur du 64 octets, je doute même que tu puisses en obtenir moins de la part de l'OS.

8

Graphique / Re : Re : Taille d'un sf::Vertex

« le: Mai 11, 2013, 11:44:48 am »

J'avoue, 320 c'est rien du tout. Mon PC en supporte bien 15000 - 30000 par seconde en dépassant les 250FPS...

Bon déjà, 320 c'était par frame et pas par seconde...

Dans mon scénario, 60 frames et 320 allocations par frame ça fait 19200 allocations par seconde.

Ce qui entre dans tes nombres (Quant aux 250 FPS, je rappelle qu'il s'agit d'une échelle logarithmique)

Pour reprendre ceci:

Tu sauvegardes ton taff sur disquette ? (ouais ok je troll x) mais faut reconnaître que tes chiffres sont quand même vachement marseillais).

Troller c'est bien mais réfléchir c'est encore mieux.

Surtout que, pour me citer moi-même:

Bon après, le temps d'allocation varie de beaucoup, mais ça fait vraiment partie des opérations lourdes.

9

Graphique / Re : Re : Taille d'un sf::Vertex

« le: Mai 10, 2013, 10:08:12 pm »

en règle générale, on alloue toute la mémoire nécessaire au fonctionnement lors de l'initialisation du jeu

Tu travail avec du matos d'il y a 20 ans ? 

C'est facile de dire ça quand ton ordinateur n'a aucun problème à gérer ce que tu lui donnes, cependant lorsque tu entres vraiment dans le temps réel, tu te retrouves très vite limité.

Pour un jeu à 60 FPS, tu n'as que 16ms pour générer une image, faire les calculs CPU et laisser la carte graphique faire ses propres calculs.

Une allocation dynamique est lourde, facilement plusieurs dizaines de microsecondes, tu te dis que ça n'est rien, mais même si ça ne prenait que 50us, ça signifie un vingtième de milliseconde, ça signifie qu'en enlevant tous les autres calculs et le rendu, tu ne pourrais faire que 320 allocations par frame pour tenir 60 FPS...

Bon après, le temps d'allocation varie de beaucoup, mais ça fait vraiment partie des opérations lourdes.

10

Discussions générales / Re : SFML 2 est là avec son nouveau site web

« le: Mai 08, 2013, 09:42:01 pm »

Personnellement j'utilise Premake, ça fait les choses vraiment bien je trouve

11

Suggestions de nouvelles fonctionnalités / Re : Re : Implémentation du C++11 ?

« le: Avril 29, 2013, 09:51:52 pm »

Lynix, ton problème était un bug de quel ordre: Corruption de la mémoire ou tout simplement les appels de mauvaises fonctions ? ça mérite des tests tout ça
Mais il n'y a pas une compatibilité ascendante garantie par la norme entre les différentes versions du C++ ?

J'avais droit aux deux, la mémoire était corrompue et je me retrouvais dans une méthode que je n'avais jamais appelée, je n'avais pas fait le lien immédiatement donc j'ai passé des heures à m'arracher les cheveux pour comprendre ce qu'il se passait.

Pour la compatibilité ascendante, Laurent y a déjà répondu, c'est uniquement syntaxique, le grand reproche que je fais au C++ est de ne pas avoir d'ABI standardisée

12

Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?

« le: Avril 29, 2013, 03:48:24 am »

Mon message était écrit avec les binaires incompatibles en tête.

Alors oui, il est possible de compiler en C++11 et d'utiliser en C++03, en restreignant de beaucoup.
Comme Laurent l'a indiqué, la taille de la classe ne doit pas changer, mais il n'y a pas que ça.

Un jour j'ai compilé une classe avec une méthode que j'enlevais du header lors de l'utilisation, j'ai eu les pires bugs de ma vie et n'ait plus jamais recommencé.

Bon après, comme je n'ai tenté le coup qu'une fois, je ne peux pas trop l'affirmer, c'était sans doute lié aux vtable (la méthode en question était virtuelle).

Mais bon, une telle compatibilité binaire ne fait pas partie du standard à ma connaissance, autrement dit c'est jouer avec le feu pour pas grand chose.

D'ailleurs aucune compatibilité binaire ne fait partie du standard

13

Suggestions de nouvelles fonctionnalités / Re : Implémentation du C++11 ?

« le: Avril 28, 2013, 01:48:44 pm »

Je trouverais assez superflu de recompiler la SFML pour ça, ce qui au contraire empêcherait une compatibilité des binaires de la lib

Ce que tu demandes à Laurent c'est de distribuer des binaires C++03 et des binaires C++11 ? Je doute qu'il accepte

14

Système / Re : [SFML2.0] Les thread et mutex sont il plus rapide ?

« le: Janvier 28, 2013, 10:57:17 pm »

Surtout que les mutex SFML sont des mutex légères, inter-processus, qui peuvent être utilisées sans vraiment ralentir l'application (S'il n'y a pas d'abus).

15

Suggestions de nouvelles fonctionnalités / Re : Amélioration des paquets

« le: Décembre 04, 2012, 09:00:33 am »

Moi je trouverais ça bien plus naturel de surcharger l'opérateur &= pour l'écriture et & pour la lecture.