je suis en train d'optimiser là

moi aussi ca métonnait x)

à vide de chez vide, j'ai 500 FPS (donc je n'affiche AUCUNS blocs, mais je fais tous les calculs à coté (x et y pour chaque tile, je fais mes get sur les listes de blocs à afficher ...

et bien tu veux savoir où était le point qui péchait ?

dans un test unitaire, je faisais un get list pour savoir quels sont les blocs solides. sauf que cette methode créait à chaque fois une liste de 0 ! du coup, vu que cette liste ne change au cours du jeu, j'ai fait une constante, et on repasse 15 FPS à 55-70 FPS (en affichant tout, donc bloc du 1er layer et ceux de fond )

edit : regardez cette screenschot : grâce à l'optimisation faite, je peux afficher 213 blocs de fond (avec une mise en alpha, qui est censer bouffer pas mal quand meme ) sans baisse de FPS (je suis resté constant sur les FPS tout au long des déplacements et de l'augmentation des blocs de fond à afficher )

edit 2: oups, je viens de spoiler l'interface de debug

edit 3 : mise à jour du post principal

-
Edité par Anonyme 30 août 2015 à 14:17:20

Ha ça m'étonnait aussi ! En restant sur de la 2D "simpliste" 15 FPS était vraiment peu... Mais je pense que tu peux encore gagner quelque part

Si je peux faire tourner Crysis 3 à 60 FPS, tu peux ajouter tous les effets que tu veux à Urworld, il devrait tourner à plus de 15 FPS.

C'est l'affichage pygame qui bouffe beaucoup de temps, j'ai le même problème avec Endless caves, enfin il est moindre parce que je dois pas afficher tout l’écran a chaque image, vu que j'ai pas de scrolling, mais des qu'il faut rafraîchir ça bouffe très vite si on fait pas attention...

-
Edité par Reiex 31 août 2015 à 1:31:03

Concernant l'optimisation, simule-tu les blocs qui ne sont pas visible par le joueur ? Si oui tu pourrais améliorer ce système et gagner quelques petits FPS.

et non justement, j'y ai déjà pensé

si il y a un bloc devant mon bloc d'arrière plan, je n'affiche pas ce dernier

<hs>

sinon, je suis en train de rédiger un tutoriel sur pygame sur zds, pour les interressés

</hs>

edit : je vais tenter un hwsurface en flg sur ma fenetre, ca se pourrait que ca optimise le jeu (d'un chouilla hein, pas de 1500000 FPS )

-
Edité par Anonyme 31 août 2015 à 12:11:39

Oh oui ! Très intéressé même !

J'ai déjà pensé a plusieurs reprises faire un tutoriel sur pygame, car l'actuel est vraiment très incomplet, mais comme je suis débutant en python je preferais attendre d'etre expert pour tenter ça, mais si t'as une beta, un besoin d'aide, ou n'importe quoi, je suis dispo =D

-
Edité par Reiex 31 août 2015 à 12:12:51

<hs>

le lien est dans ma signature, je viens de commencer (ce matin meme), et y a une beta

besoin d'aide, j'en aurais surement (mon deuxieme prenom est yoda :lol :), comme je rentre en premiere S (arrete de raconter ta vie idiot ! ) je vais avoir bcp moins de temps pour coder et rediger mon tuto (que je veux plus consequent que celui d'oc qui est n'est qu'une intro à pygame je trouve )

</hs>

Lubzorg a écrit:

<hs>

comme je rentre en premiere S (arrete de raconter ta vie idiot ! ) je vais avoir bcp moins de temps pour coder et rediger mon tuto

</hs>

<hs>

Qui a dit qu'on avait plus de vie en 1ère S ?

Tu auras largement le temps de continuer ce que tu fais

</hs>

bah je sais pas, mais pas mal de gens dans mon entourage me disent que cette année j'ai pas bossé (vrai, mais 15 de moyenne quand meme x) ), et qu'en première faudra cartonner avec le bac et tout et tout, surtout que si j'ai pas 16 de moyenne en 1S et TS, et ben ... je devrais passer un concours pour aller à polytech

j'espere, meme si c'est au ralenti, il me reste plein de trucs à coder ! et a rediger

C'est marrant ça, t'as 16 ans, tu entre en première S et tu pense ne plus avoir de temps libre, j'en ai 15 j'entre en terminale S spé ISN et je sens que je vais passer une année tranquilou (mis a part le bac d'histoire-géo)

Je pars voir la beta de ce pas !

EDIT: Je vise pas l’école d'ingé aussi x)

-
Edité par Reiex 31 août 2015 à 12:30:37

je pense qu'on continuer en mp bientot xD

15 ans et deja en TS ?! bah dis donc, chapeau !

d'ailleurs, l'ISN, c'est facile ? car tout ce que j'ai trouvé sur le net c'est : on apprend python de 0, y a pas de POO

bref c'est la mort là (j'adore la POO) x)

J'entre en terminale, je n'y suis pas encore... mais vu le niveau de ma classe en programmation... on aura de la chance si on atteint la fonction print() ...

En fait si j'ai pris ISN c'est juste pour impressionner le jury sans trop forcer, bah oui, envoyer en projet d'ISN Endless caves (qui est toujours en dev, je fais... une surprise), quand le reste de la classe envoie un programme année bissextile, ou doodle jump avec tkinter x)

EDIT: La POO, va falloir attendre la deuxième année de licence, enfin je pars en licence après en école d'ingé je suppose qu'on aborde ça en premier année x)

PS: J'ai essayé blablublo blablublo mais ça a planté, je fais comment ? x)

-
Edité par Reiex 31 août 2015 à 12:43:08

@progy : effectivement, le flag HWSURFACE me permet de gagner quelques petits FPS, sans shader je tourne à maxi 70 PFS, avec un shader standart, je suis à 55, avec un shader raycasté, c'est du 40-49, et avec un shader progressif (le pire de tous, mais de loin le plus beau je trouve), on est à maxi 36 FPS

je vais profiler uw pour voir où je peux encore gagner, et je vous tiens au courant

edit : je vous présente le cprofile d'urworld : http://pastebin.com/GcpcG34t

j'en suis pas fier xD

-
Edité par Anonyme 31 août 2015 à 14:03:04

Mais de manière général, pygame est affreusement lent pour le rendu, j'avais fait un test à vide avec une config musclée en C++ / SFML et Python / pygame.
Les deux programmes devaient afficher une couleur unie qui change graduellement et de façon plutôt lisse.
En C++ / SFML j'obtenais 13000 FPS

En Python / pygame j'obtenais 600 FPS

Soit 21x moins puissant !

Et avec Pysfml ? x)

Mizugola a écrit:

En C++ / SFML j'obtenais 13000 FPS

En Python / pygame j'obtenais 600 FPS

Soit 21x moins puissant !

C'est absolument n'importe quoi, comme test. Déjà on fait ce genre de mesures en millisecondes par frame - ce qui permet de comparer par rapport à 16ms, le but à atteindre.Si tu as (comme ici) un moteur qui prend 0.1ms, eh bah on s'en fout... puisque c'est 0.1ms sur 16ms.

Ensuite, et surtout, un test à vide, ça ne veut vraiment rien dire.

Lubzorg a écrit:

je suis en train d'optimiser là

moi aussi ca métonnait x)

à vide de chez vide, j'ai 500 FPS (donc je n'affiche AUCUNS blocs, mais je fais tous les calculs à coté (x et y pour chaque tile, je fais mes get sur les listes de blocs à afficher ...

c'est juste l'affichage que j'ai pas fait dans mon test meme si il est vrai qu'avec les blocs, je chute de 300-400 FPS :/ donc ca sert bien a rien

Mizugola a écrit:

Mais de manière général, pygame est affreusement lent pour le rendu, j'avais fait un test à vide avec une config musclée en C++ / SFML et Python / pygame.
Les deux programmes devaient afficher une couleur unie qui change graduellement et de façon plutôt lisse.
En C++ / SFML j'obtenais 13000 FPS

En Python / pygame j'obtenais 600 FPS

Soit 21x moins puissant !

ca dépend aussi de comment tu as optimisé ton code !

un code python peut etre aussi rapide qu'un code C++ avec de petites ficelles

Reiex a écrit:

Et avec Pysfml ? x)

j'ai prévu une réécriture avec ce dernier, dans sa version 2, mais là j'ai pas le temps :

un possible TPE sur les fractales, donc je ne code QUE ca (mot de fibo, fractale maison ...)

un tuto en cours de redac sur zds

et pis les cours quoi

Str4nger a écrit:

Mizugola a écrit:

En C++ / SFML j'obtenais 13000 FPS

En Python / pygame j'obtenais 600 FPS

Soit 21x moins puissant !

C'est absolument n'importe quoi, comme test. Déjà on fait ce genre de mesures en millisecondes par frame - ce qui permet de comparer par rapport à 16ms, le but à atteindre.Si tu as (comme ici) un moteur qui prend 0.1ms, eh bah on s'en fout... puisque c'est 0.1ms sur 16ms.

Ensuite, et surtout, un test à vide, ça ne veut vraiment rien dire.

ms par frame, le deltatime donc ?

si oui, bah le rendu est bon pour un jeu qui bouffe autant qu'urworld (un dt de 0.015 sec approximativement)

edit : mauvaises unités

-
Edité par Anonyme 9 septembre 2015 à 12:26:19

Ce serait quoi la deuxième matière pour le TPE ? Maths et ?

les matieres on a pas encore choisis (mais c'est sur, y aura maths)

et pis le sujet peut encore changer un peu, en tout cas on semble partir sur matieres et formes

Fais attention a bien traiter les deux matières, je me suis fais détruire l'année dernière parce que j'avais pas assez parlé de la deuxième matière...

Certes le test à vide ne prouve pas grand chose en soi, mais ça permet d'avoir une petite idée toutefois. SFML était capable de fill l'écran 13000 fois par seconde contre 600 fois par seconde pour SFML

Mizugola a écrit:

Certes le test à vide ne prouve pas grand chose en soi, mais ça permet d'avoir une petite idée toutefois. 

Non, ça ne donne même pas de petite idée. Je vais t'expliquer pourquoi. Imagine un moteur A qui se contente de coller des appels OpenGL sur tes fonctions, et un moteur B qui enregistre tous tes sprites, toutes tes demandes de mouvement, et qui une fois par frame, affiche tout à l'écran. 

Sur de très petits jeux, le moteur A sera forcément plus efficace. Le moteur B a un coût statique à chaque frame quel que soit le jeu, gros ou petit. Mais sur de très gros jeux, les performances du moteur A vont exploser en vol, tu vas te traîner à 1fps - alors que le moteur B, lui, a un peu plus de charge en statique mais supporte beaucoup mieux le passage à l'échelle au-dessus. 

c'est très imagé mais un exemple réel de "moteur A", c'est Source de Valve, dans sa version Half-Life². Une lumière dynamique ? OK. Cinq lumières dynamiques ? Cool. Vingt lumières dynamiques ? Au revoir, merci d'avoir joué... Alors que des moteurs plus modernes, avec un coût "à vide" très largement supérieur, s'en sortiront bien mieux sur un gros projet. 

Je résume donc ; 

• on ne compare jamais des performances à vide ;
• on ne compare jamais des FPS (surtout au dessus de 60) mais des millisecondes ;
• ton test ne veut strictement rien dire et dans un cas réel, SFML ne sera jamais vingt fois plus rapide.

Bon sinon pour avoir un meilleur comparatif, le même jeu fait avec SFML et pygame :

SFML : 0,833 millisecondes pour rendre une frame

pygame : 22,2 millisecondes pour rendre une frame

Sachant que le jeu implique de la parallax.

En situation "réelle", SFML/C++ apparait 26x plus rapide que pygame/python.

On attend impatiemment les sources des deux versions et le détail des benchmarks.

mizu: connaissant le-dit jeu, je trouve ça parfaitement normal

pour plusieurs raisons : tu fais du pixel perfect, ca bouffe (apres ca dépend si ton benchmark se passait sans mouvement du joueur ou non, et si ta gestion des collisions / sauts est appelée uniquement lors d'un event ou non)

et pour info, urworld a quand meme pas mal de fonctionnalités qui sont appelées à *chaque tour* de boucle (des routines obligatoires), et j'ai des frames de 0.014 sec = 14 ms

bonjour,

bon, je ne te cache pas que le graphisme sont moche (mais se n'est qu'un détaille, tu trouvera surement un graphisme que t'on jeux sera bien plus avencé)

j'ai un peut survolé t'on poste et j'ai quelque question :

- tu parlé au début des voyage dans le temps, comment fait tu ? plusieur map pour apssé/présent/futur ? a tu re travailer dessu ?

- utilise tu un moteur 2D, si tu n'en utilise pas , ou sont stoqué les image (ram ou carte graphique), si elle sont stoké dans la ram, sa peut espliqué les 15 FPS. (prent c'est remarque de quelqu'un qui n'y connais pas grand chose, qui fait juste des forum)

- a tu mis (vas tu mettre) de la vie (pasifique / ostile) ? car la redstone, c'est marent, mais dans un monde vide sens vie

bonne chance a toi pour la suite de t'on dévelopement

gourmand87 a écrit:

bonjour,

bon, je ne te cache pas que le graphisme sont moche (mais se n'est qu'un détaille, tu trouvera surement un graphisme que t'on jeux sera bien plus avencé)

j'ai un peut survolé t'on poste et j'ai quelque question :

- tu parlé au début des voyage dans le temps, comment fait tu ? plusieur map pour apssé/présent/futur ? a tu re travailer dessu ?

- utilise tu un moteur 2D, si tu n'en utilise pas , ou sont stoqué les image (ram ou carte graphique), si elle sont stoké dans la ram, sa peut espliqué les 15 FPS. (prent c'est remarque de quelqu'un qui n'y connais pas grand chose, qui fait juste des forum)

- a tu mis (vas tu mettre) de la vie (pasifique / ostile) ? car la redstone, c'est marent, mais dans un monde vide sens vie

bonne chance a toi pour la suite de t'on dévelopement

À moins que je me trompe, de ce que a dit Lubzorg, le projet serait fini...

charlesfire a écrit:

À moins que je me trompe, de ce que a dit Lubzorg, le projet serait fini...

Effectivement, le jeu est en Alpha 3.0 d'après Github, mais il est fini x)

Plusieurs maps

Ram je pense car c est la sdl 1.2

Il devait en avoir, mais le projet etait mal codé du coup ca aurait ete plus dur que de faire rentrer une patate dans un MMS

Oui il est "fini"