Ca dépend de la lib.

Que je sache t'as jamais utilisé Pygame ?

Donc walla j'ai envie de dire. (j'hésite à sortir un truc, mais c'est trop violent)

Bah oui Pygame est super pour faire des jeux. Bah oui Pygame franchement ça roxe du poney. Mais pour ce qui est des jeux de scrolling verticaux-horizontaux comme celui-ci, non il gère plus du tout. Et c'est bien connu. En me lançant là dedans je le savais.

Mais ce que peu de personnes savent, c'est que cette version d'Unamed, c'était un "prototype" dans le sens j'y met tout ce que je veux voir dans la finale. Et j'ai utilisé Pygame car je connais bien et que je savais que je pouvais pondre ce proto rapidement. Maintenant j'écris le truc sous PySFML.

Je m'exuse d'avance si ça passe pour un coup de gueule C'est juste que j'ai été "un poquito" irrité (c'est de ma faute aussi, c'est écrit nul part que je prévoyais cette "réécriture")

-
Edité par Anonyme 24 mars 2016 à 19:07:19

C'est aussi pour ça qu'il y a Unity.

C'est pas un peu casse-gueule de faire un "prototype" de jeu sur une lib que tu sais inadaptée? Surtout que ta seule motivation pour choisir cette lib plutôt qu'une autre apparemment était que tu la connaissais déjà. Mais pour le temps que ça t'a pris pour faire un prototype, combien ça t'aurais pris en apprenant directement une lib adaptée et de commencer le jeu directement dessus? (J'ose supposer que ça aurait été plus facile, avec un outil adapté).

Après moi je suis pas grandement calé en python, je fais surtout du C et un peu de C++... Donc je ne suis pas une référence en programmation python (sans déc)... Mais je trouve ça quand-même saugrenu comme démarche.

Bwef.

Peut-être que ce qui l'intéresse dans ce projet, c'est de développer les différents aspects du jeu de toute pièce, non ?

entwanne a écrit:

Peut-être que ce qui l'intéresse dans ce projet, c'est de développer les différents aspects du jeu de toute pièce, non ?

Et oh !

Je suis en pleine réécriture, les perfs sont à 0 là ! Y a rien qui tourne xD

Et oui j'avais envie de me focaliser sur le moteur "pokémon" du jeu

Je savais que ça tiendrait pas la route, certes, mais ça m'a quand même permis de mettre en place quoi, les 4/5 du jeu ? Donc je pense que c'est vraiment pas mal perso !

Commencer direct dessus ? Bof bof. Ca aurait pris plus de temps car faut apprendre à se servir de la lib (chose que je fais depuis un petit moment maintenant), et j'aurais sûrement mal codé le truc car ça aurait été la première fois que je me serais servi de PySFML

Et pis la force de Python c'est l'oo. Donc la modularité. Donc oui je suis aussi modulaire dans mes choix (ma pensée est tordue oui)

Ca peut paraitre bizarre oui, grand smurf. Mais c'est mon choix Je trouve que je contrôle tout, et que là au moins je peux faire ce que je veux (et facilement) (ok Unity est super génial, et quand on connais bien, on peut faire mieux que ce que je fais là)

Si tu as besoin de technique d'opti n'hésite pas à me demander ! Par exemple, moi j'ai gagné 200 fps sur mon jeu avec quelques trucs tout simple

T'inquiète pas, j'ai quelques 20000 lignes de log grâce à CProfile

Maintenant, faut que je bosse ma migration, et ensuite on en reparlera

-

Edit : migration du main.py et de quelques fichiers ... terminée ! Et ça marche du tonnerre. Et grâce à tout ce que j'ai découvert (encore) cet aprem (j'ai téléchargé la doc ^^), je pense que ce portage pour être complet (même si plus long que prévu :/ ) ! En effet j'ai trouvé tous les "alias" de fonctions que j'utilisais avec Pygame dans PySFML (bon, faut chercher un peu par contre, et c'est assez tordu pour avoir la taille d'un texte xD faut faire un text.local_bounds.width)

-
Edité par Anonyme 25 mars 2016 à 19:27:08

Tu n'as pas parlé de tes 20 000 FPS ?

(Perso, je soupçonne un mauvais calcul )

Moi je soupçonne une valeur donnée en "fps", une unité qui n'a pas le moindre soupçon de sens en benchmark. La valeur pertinente est en millisecondes.

Ah non, j'ai pas parlé des 20'000 FPS que donne PySFML (l'ayant fait sur le blog, j'ai zappé de le dire ici et sur ZDS (sur csp aussi je crois xD))

Gwënn : si je te donne le dt ça t'ira ? J'peux aller chercher ça

Edit : test fait (PySFML). self.clock.restart().milliseconds me donne bien un dt compris entre 48 et 66 millisecondes. Si on fait le calcul ensemble, on a ça : ~0.048 | ~0.066 sec.

Donc 1000 / 0.066 (j'prends la plus grosse valeur) donne ~15000 FPS.

Et j'ai aussi fait un petit script totalement con dont voici la source :

import sfml as sf

fen = sf.RenderWindow(sf.VideoMode(200, 200), "test SFML")
clock = sf.Clock()
fps = 0

while True:
    fps += 1
    if clock.elapsed_time.milliseconds >= 1000:
        clock.restart()
        print(fps)
        fps = 0

L'output indique (en moyenne) 48'000 FPS (donc un dt en ms inférieur à 0.1)

Merci pour vos encouragements

-
Edité par Anonyme 29 mars 2016 à 17:23:13

Et si je vous disais qu'une version jouable est disponible ?

Souhaiteriez vous la tester ?

Oui ?

Alors c'est par ici que ça se passe : releases !

Arrête moi si je me trompe mais tes calculs sont légèrement  (complètement ) erronés

1000 ms = 1 s ok

Donc 1000 ms ÷ 66 ms (et non pas 0,066 qui exprime une valeur en secondes ) = 15 frames .

15000 fps ça voudrait dire 15 frames par millisecondes. Si je me trompe alors il faut absolument que tu m'apprennes à coder 

Yaalval a écrit:

import sfml as sf

fen = sf.RenderWindow(sf.VideoMode(200, 200), "test SFML")
clock = sf.Clock()
fps = 0

while True:
    fps += 1
    if clock.elapsed_time.milliseconds >= 1000:
        clock.restart()
        print(fps)
        fps = 0

Ah oui. Mea culpa

Mais d'où vient ce résultat de 48000 FPS que donne ce code alors ? Car même pygamene peut pas atteindre ça !

Arrête de mesurer des fps - cette valeur ne sert à rien - et mesure le temps, en millisecondes, passé dans chaque frame. Eventuellement avec une moyenne, mais même mesurer le temps maximum est très bien.

Le temps de rendu est un budget. Tu as un budget de 16,7ms, tu ne dois pas le dépasser, et partant de là, tu peux prendre des décisions comme un budget financier : allouer 5ms au rendu, 3ms à la logique du jeu, 2ms au réseau, 1ms au son et attendre les quelques ms qui restent.

Le framerate est une mauvaise mesure de performances parce qu'elle ne permet pas de découper le temps de calcul suivant un budget, et parce que c'est très facile d'en tirer de fausses conclusions :

• la technologie A donne 240 fps avec 10 objects, et 24 fps avec 100 objets;
• la technologie B donne 120 fps avec 10 objects, et 110 fps avec 10 000 objets.

Dans cet exemple, en mesurant en temps, tu verrais que la technologie A coûte 0,4ms par objet, et la technologie B coûte 8ms systématiquement même à vide, mais 0,00...ms par objet. Tu n'as pas terminé ton jeu, tu es dans le cas "10 objets", tu ne peux pas juger sur la base du framerate parce que ça te mènerait à une mauvaise conclusion - ce que tu dois faire c'est mesurer le temps, et profiler qu'est-ce qui consomme ton budget.

-
Edité par Anonyme 30 mars 2016 à 18:13:07

-
Edité par Lauloque 30 mars 2016 à 19:11:17

Ya un soucis Watson ...

Pygame :

29688    0.230    0.000   26.925    0.001 rendering_engine.py:132(flip)

652    0.049    0.000    3.751    0.006 rendering_engine.py:90(load_image)

PySFML :

793   10.994    0.014   10.994    0.014 {method 'display' of 'sfml.window.Window' objects} (équivalent de flip)

75    3.234    0.043    3.234    0.043 {method 'to_image' of 'sfml.graphics.Texture' objects} (équivalent d'un pygame.image.load().convert_alpha() ; grossièrement (si on compte pas le temps pour appliquer la texture à un sprite, chose super rapide))

Rendering engine est un wrapper que j'ai fait à Pygame

Donc rendering_engine.flip() appelle pygame.display.flip() et rendering_engine.load_image(path) appelle pygame.image.load(path).convert_alpha()

Comment dire ... (et ce ne sont que 2 échantillons) Soit je code mal avec la SFML, soit mon PC l'aime pas, soit Pygame est plus rapide ...

J'hésite. (je garde le portage dans un coin de ma tête mais l'enlève de mes priorités)

Chouette explication en effet

Mais le 48000 FPS parrait un peu étonnant sachant qu'avec C++ et SFML je tapais dans les 12000 avec un code simplissime.

Test à blanc Donc 48000 = 1000 / x donc x (le dt) = en moyenne 1000 / 48000 (car 1000 / (1000 / 48000) = 48000 ; là je me suis pas planté xD) Donc un dt d'environ 0.02083 ms (si je me plante pas encore une fois d'unité )

Mais un test plus "conséquent" avec gestion des event (draw différents en fonction d'event) par poll() (donc stress du CPU car ca consomme bien plus que get ou wait), clear total (.clear() chez sfml et .fill() chez pygame) puis draw call et enfin actualisation (display pour sfml et flip pour pygame), donne des dt très beaux

0.23 ms de dt pour Pygame (en moyenne)

0.46 ms de dt pour SFML (en moyenne)

Pygame est toujours 2* meilleur j'm'tâte, surtout que la sfml gère mal les accents dans les Text() apparement

A chaque fois que je vois une mesure de framerate supérieure à 60fps (donc dénuée de sens), je tue un chaton, alors arrêtez.

Yaalval a écrit:

Pygame est toujours 2* meilleur j'm'tâte, surtout que la sfml gère mal les accents dans les Text() apparement

0.46ms, c'est 3% de ton budget de performances. C'est purement et simplement négligeable. Tu es en train de mesurer la charge a à vide - le cas à 10 objets dans mon exemple, et tu es en train de déduire que A est la meilleure solution parce qu'à vide, A est plus rapide (et je t'ai prévenu du danger de ce raisonnement). Quelles sont les performances de pygame sur un jeu complet ? Pourquoi voulais-tu passer à sfml ?

A vide, pygame est plus rapide, avec le premier objet, un pysfml bien géré vaut 100 pygame, j'étais a 10ms sur Endless caves avec pygame, je suis à 3ms avec pysfml sur Endless Rooms.

De plus, Endless Rooms est un jeu qui doit rafraîchir tout l’écran à chaque frame alors que Endless-caves n'avait que quelques sprites à effacer puis réafficher.

Donc "Pygame est toujours 2* meilleur" c'est un mensonge !

Str4nger a écrit:

A chaque fois que je vois une mesure de framerate supérieure à 60fps (donc dénuée de sens), je tue un chaton, alors arrêtez.

Surtout pas! CONTINUEZ!!!!

Pardon, je flood un peu...

-
Edité par Lauloque 30 mars 2016 à 23:03:20

Quelques minutes de fun

C'est cool d'avoir mis plusieurs zones ça permet de se balader un peu pendant le test . Le truc qui me déconcerte c'est l'utilisation de la souris ainsi que le placement des maps qui n'est jamais le même, décentrant au passage le héros ... mais à part ça c'est pas mal ^^