Discussion :

[jean_kevin_musclor]

Si le programme n'est pas multi-thread c'est tout à fait normal il n'utilise qu'un seul des deux coeurs.

[Vetea]

Si le programme n'est pas multi-thread c'est tout à fait normal il n'utilise qu'un seul des deux coeurs.

Et bien, que ce soit avec mon Q9550 ( 4 coeurs ) ou E6600 ( 2 coeurs ), j'ai tous les coeurs qui sont utilisés et non un seul.

EDIT :

Voici la preuve en image :

[jean_kevin_musclor]

Tu as donc programmé quatre threads.
Ou alors c'est qb64 qui le fait tout seul ?

[Vetea]

Je pense que c'est QB64 qui gère avec la SDL 1.2.
Après, j'en sais fichtre rien ! ^^

[jean_kevin_musclor]

Okay l'enquête progresse.

Sdl 1.2 ne gère pas la vsync tout seul, il faut passer par une texture dynamique opengl et reprogrammer intégralement le moteur graphique, et je doute qu'ils aient fait ça pour qb64, ça expliquerait pourquoi y'a pas de vsync.

Sinon je vois que chez moi aussi ça prend les deux coeurs, et ça dépasse un peu 50%, et donc tu n'as pas fait une routine de bourrin qui surchauffe, y'a bien une pause pour que ça tourne aux alentours de 60 fps. (perso je conseille plutôt 50 fps pour les jeux sans vsync, ça fait un tearing mieux réparti et ça donne un effet vieille télé au lieu des vilaines saccades)

Bon mais donc en effet il y'a un problème de consommation processeur, pour un jeu aussi simple ça devrait pas pomper autant.

Soit qb64 est d'une lenteur extrême, soit il manque des optimisations, soit les deux...

Là ça va pas être évident il faudrait que je passe deux semaines à étudier tout ton code source pour savoir où ça rame...

Pourrais-tu décrire un ordre de grandeur du nombre de routines d'objet et de tests de collision en force brute qui tournent en temps réel ?

[Vetea]

Merci pour l'info de la SDL 1.2, cela sort de mes compétences très médiocres en terme de développement.
Ceci expliquant peut être cela en ce qui concerne les optimisations ( que j'effectue à chaque mise à jour. )
Pour ce qui est des routines qui tournent, il y en a beaucoup :

1/ Routine de Z Ordering pour le traitement de la profondeur des objets de la scène ( avec gestion de ce qui est uniquement visible à l'écran )
2/ Gestion de l'IA ( Pathfinding, aggro, etc ... )
3/ Gestion de l'affichage de tous les éléments ( avec gestion de ce qui est uniquement visible à l'écran )
4/ Routine de la police graphique.

Si tu veux t'amuser à reprendre les 22 000 lignes de code, je te souhaite bien du courage et je ne t'en demande pas tant !
Pour moi, le code manque encore d'optimisation ET QB64 a des problèmes de vélocité avec des résolutions supérieures ou égales à 800x600 ( en 320 x 200, le jeu est 2 3 fois plus véloce, mais nécessite une mise à l'échelle de toutes les coordonnées ... )
Donc, ne te prends pas la tête, je vais continuer mes travaux d'optimisations.

Bonne soirée.

[jean_kevin_musclor]

22 000 lignes ??? omg hé bé y'a du boulot là dessous
( super mario ne faisait que 10 000 lignes )

Je peux quand même faire un bref résumé des optimisations basiques de jeux oldschool en 2d, je suppose qu'elles sont déjà faites mais on sait jamais:

- les objets statiques n'ont pas de routines, ils sont rangés dans la grille et on les consulte en collision

- les objets dynamiques en dehors de l'écran n'ont pas de routine, ils sont activés au fur et à mesure que l'on scrolle en consultant la rangée de cases qui se trouve au dessus de l'ecran

- quand il y'a beaucoup d'objets en collision on optimise les collisions avec une broad phase dans une grille d'objets dynamiques, qui les stock au choix avec des bitmask ou des tableaux dynamiques (je ne sais pas laquelle des deux approches est la plus rapide en qb64). Mais dans les vieux jeux on n'e sembêtait pas à aller jusque là et on limitait les tests de collision comme cela: le perso tire maximum 8 balles, et si les ennemis sont nombreux ils ne se collisionnent pas entre eux.

- le pathfind ne se fait pas bêtement à chaque frame (sinon tu es sûr que ça va ramer) mais il est étalé sur une pile d'itérations de façon à faire juste quelques tests par frame. ceci dit dans les vieux jeux on s'embêtait pas avec du pathfind on faisait des trucs beaucoup plus simples (voir par exemple les fantômes de pacman)


voilà... je sais pas si ça va t'aider ou si tout cela est déjà programmé.. toi qui est un roots normalement tu devrais connaitre tous ces trucs

[Vetea]

22 000 lignes ??? omg hé bé y'a du boulot là dessous
( super mario ne faisait que 10 000 lignes )

Je peux quand même faire un bref résumé des optimisations basiques de jeux oldschool en 2d, je suppose qu'elles sont déjà faites mais on sait jamais:

- les objets statiques n'ont pas de routines, ils sont rangés dans la grille et on les consulte en collision

- les objets dynamiques en dehors de l'écran n'ont pas de routine, ils sont activés au fur et à mesure que l'on scrolle en consultant la rangée de cases qui se trouve au dessus de l'ecran

- quand il y'a beaucoup d'objets en collision on optimise les collisions avec une broad phase dans une grille d'objets dynamiques, qui les stock au choix avec des bitmask ou des tableaux dynamiques (je ne sais pas laquelle des deux approches est la plus rapide en qb64). Mais dans les vieux jeux on n'e sembêtait pas à aller jusque là et on limitait les tests de collision comme cela: le perso tire maximum 8 balles, et si les ennemis sont nombreux ils ne se collisionnent pas entre eux.

- le pathfinding ne se fait pas bêtement à chaque frame (sinon tu es sûr que ça va ramer) mais il est étalé sur une pile d'itérations de façon à faire juste quelques tests par frame. ceci dit dans les vieux jeux on s'embêtait pas avec du pathfind on faisait des trucs beaucoup plus simples (voir par exemple les fantômes de pacman)


voilà... je sais pas si ça va t'aider ou si tout cela est déjà programmé

Héhé, et oui depuis le mois d'Aout 2013, il y a eu près de 500 heures de boulot cumulées ( Code, Graphisme, FX, Sons & Musiques )
Pour ce qui est de tes conseils, je crois avoir compris une bonne moitié de ce qui tu m'a énuméré.

Les objets statiques sont en effets gérés dans un tableau en 2D ( ObjetObstacle ( X, Y ) = type d'objet qui amènera une collision, une vitesse diminuée, etc ... ), donc aucune ressource processeur, juste de la place en mémoire.
Mémoire qui, à chaque stage, est réinitialisée.
Il n'y a aucune fuite de mémoire.

Tout ce qui est en dehors de l'écran n'est pas géré en effet.

Le Pathfinding est très simple. Ce n'est pas un A*, juste un Pathfinding de mon cru ou chaque unité utilise un vecteur de direction jusqu'à ce qu'il effectue la distance qui lui était affecté ( ou jusqu'à ce qu'il rencontre un obstacle ), auquel cas, il choisi à nouveau un nouveau vecteur et une distance à parcourir ( distance qui est différente pour chaque classe d'unité ).
Ils prennent en compte la position de Papi que quand leur tempo d'aggro est activé, dès lors il tir en direction de Papi. Par contre, il y a quelques restrictions :
- Si les unités se trouvent dans un vecteur contraire à celui de Papi, ils ne tireront pas pour éviter des réactions illogiques et irréalisables et leur tempo d'aggro sera réinitialisée.
- Si les unités se trouvent face à papi ( sur 180 ° ), alors ils effectueront leur tir dans le vecteur adéquat.

Tout ceci ne consomme pratiquement aucune ressource ! J'ai fait des tests avec plus de 200 unités ...

La gestion des hitbox des objets dynamiques est on ne peut plus simple :
Valeur Absolue ( X Cible - X Source ) = Intervalle X ET Valeur Absolue ( Y Cible - Y Source ) = Intervalle Y
Intervalle X & Intervalle Y sont les dimensions de la hitbox ( un carré, ou un rectangle selon leur taille. )

Ce qui prend pas mal de ressource, c'est la routine de Z-Ordering.
Routine que j'appelle au travers d'une tempo pour alléger la charge CPU.

Voilà en gros.

[jean_kevin_musclor]

Ok je me disais bien qu'un dev oldschool connaissait toutes ces techniques...

Effectivement j'avais pas pensé que c'est d'abord le z-ordering qui pompe un max.
La technique la plus simple reste le z buffer mais ça doit pas être prévu par le moteur graphique de qb64.

Tu as utilisé quel algo pour ça ? Le bubble sort est facile à coder mais c'est un très mauvais algo très mal optimisé qui fout le cpu à genoux à coup sûr.

J'avais codé le mien à une époque avec un système con qui consommait pas trop. Y'a deux tableaux, d'abord je parcourt le premier pour trouver le plus petit, et puis je le copie dans le 2eme tableau, et ainsi de suite, avec un bitmask pour ne pas re-tester inutilement les cases déjà testées sur le premier tableau, mais je sais pas trop si qb64 sait faire des calculs binaires qui vont vite

J'en ai fait pas mal du basic dans le temps mais depuis que j'ai gouté au c++ je ne peux plus faire autre chose, fini les arrachages de cheveux pour optimiser les langages lents, ça aère

[Vetea]

Pour l'algo de Z-Ordering, c'est très similaire à ce que tu as décrit :

1/ Je copie les coordonnées Z de la scène ( et d'autres objets en fonction de leur hauteur .. Il s'agit d'un jeu en 3D isométrique ) dans un tableau ainsi que leur ID.
2/ J'effectue dans ce tableau un tri des coordonnées Z uniquement pour les objets visibles de la scène ainsi que d'autres conditions comme les objets à plusieurs étages.
3/ Une fois le tri effectué, je copie l'ID des objets traités dans mon tableau d'origine.

Basique, en effet ! ^^

Je rappelle que QB64 est développé en C++, l'exe compilé est en C++.
QB64 est un interprétateur "Basic" pour utiliser un langage plus évolué comme le C++ avec des instructions toutes faites héritées à la SDL.
QB64 GL, est une nouvelle version "Beta" qui utilise des routines hardware OpenGL mais est beaucoup moins finie que la version SDL.

Voilà, je pense que tu sais presque tout ! ^^

[jean_kevin_musclor]

Pour etre exact ton jeu est de l'iso2d (ça veut dire que les personnages ne grimpent pas sur les obstacles), donc normalement il n'y a pas à tenir compte des étages pendant le z order, un objet à étages se traite comme un objet normal en tenant juste compte du y du pixel le plus bas. (le z order se fait sur les objets et non pas sur les sprites qui composent l'objet)

Le z order je le ferais fonctionner comme ça avec 3 tableaux ( je laisse tomber l'optimisation bitmask en partant du principe que qbasic ne sait pas le faire correctement ) :

phase 1:

- le tableau 1 est rempli avec tous les id d'objets visibles
- le tableau 2 est rempli avec le y du pixel le plus bas

phase 2:

- on cherche le plus petit y dans le tableau 2
- on copie l'index correspondant dans le tableau 3 (en incrémentant l'index d'insertion dans tableau 3 évidemment)
- on fout la valeur integer maximale dans la case du tableau 2 afin de l'éliminer (en supposant que qbasic se débrouille plus vite comme ça qu'avec les bitmask)
- et puis on recommence

phase 3:

- on parcourt le tableau 3 pour tracer chaque objet dans le bon ordre. chaque objet a autant de sprites que tu veux (c'est comme ça qu'on fait les étages).


voilà je sais pas si tu as fait comme ça mais ça me semble pas insurmontable pour le processeur, à moins que le langage qb64 soit un véritable escargot

[Cirrus Minor]

Alors moi je suis pas là pour parler technique ;-)

J'ai joué à la nouvelle version ce weekend, et j'aime bien la nouvelle interface. On voit bien les informations importantes, et ça ne pose pas de problème à l'expérience de jeu.

Par contre, je suis toujours aussi nul
Faut dire que le challenge est élevé, on n'est plus habitué (quoi qu'il y a un "hype" du jeu indépendant avec des titres extrêmement exigeants depuis quelque temps ! J'avais joué un peu à Dustforce, La-Mulana...).

Vraiment encore pour ce jeu !

[Vetea]

La technique, c'est pas mon fort a vrai dire !!
Sinon, merci Cirrus !!!
C'est un jeu difficile a l'ancienne ... Peut être encore mal équilibre ! Il faut que j'ameliore ça
Ravi que ce nouveau Hud te convienne. Moi je ne peux plus m'en passer !
Par contre, j'ai reçu de nouvelles musiques de Michael , compositeur de talent qui a rejoint le projet. Du tour bon !!!!!
Quand j'aurai plus de sample, je diffuserai une nouvelle version avec ces nouveaux contenus qui vous plairons si vous aimez les titres "chiptunes" !
A bientôt et bon jeu a tous.

[illight]

Ah au fait :

Joyeux anniversaire

[Vetea]

Arg ... Merci !
Me rajeunit pas cette nouvelle ... Premier programme Basic en 1979 ... Pfiouuuuu ... Ça passe trop vite

[Vetea]

Bonjour à tous,

Avec l'arrivée de Michael Ghelfi ( Sa chaine YouTube : https://www.youtube.com/user/MichaelGhelfi ), compositeur de talent, le projet va prendre une autre ampleur au niveau de son atmosphère musicale.

Vous aimez les musiques rétros ? Les bon vieux thèmes "Chip tunes" ? Ces sons et ces musiques qui ont égayées vos après midi pluvieux devant votre NES, Commodore 64, CPC et autres machines Rétros ??

Admirez Papi entouré de ses "amis", danser au rythme pixelisé des deux thèmes proposés par Michael :

D'autres thèmes sont en prévision et viendront accompagner vos progressions tout au long des stages.
Bonne écoute !

[jean_kevin_musclor]

Bravo l'artiste !

[Vetea]

Bravo l'artiste !

Merci pour lui !
D'autant plus que c'est la première fois que Michael compose dans ce genre là.
Pour un premier essai, je trouve ça déjà excellent. !

Sinon, je voulais vous présenter la version originale du jeu Who Dares Win II :

( En version jouable sur site en Java : http://www.80stopgames.com/site/node/1542 )

Vidéo de Gameplay :

Version Commodore 64 avec un scrolling vertical en Hard !! Couleur assez "fade" très caractéristique de la palette du Commodore 64 ...

La version CPC 6128 est beaucoup plus belle avec ses couleurs flashy ( une palette de seulement 27 couleurs, mais toutes bien choisies avec différents niveaux de dégradé ! ), mais sans scrolling étant donné les limitations de la machine à l'époque ... Et oui, le C64 était bien le meilleur 8 bits de sa génération ...
La résolution du jeu est ici en 160x200 en 16 couleurs simultanée s'il vous plait ...

Décidément, quelle belle époque ...

[Vetea]

Bonsoir,

Je commence à m'attaquer aux véhicules blindés du jeu, et il y a du boulot vu la diversité que je me suis fixé ...
Donc, pour commencer, voici un premier Artwork d'une Jeep blindée avec son occupant ( un général C++ ) :

Taille normale :


Taille agrandie :


Bon ok, c'est pas du Metal Slug ... J'ai pas le talent de sortir des sprites aussi réussis ... Mais je suis satisfait du résultat !
C'est pas le modèle définitif ... Mais un premier jet qui sera amélioré par la suite.
Le véhicule est peint en vert Kaki avec des motifs de camouflage.
Aucune arme sur le véhicule.

Le véhicule se contentera d'aller de gauche à droite et inversement comme les trains.
On pourra les dégommer à la grenade et les véhicules devraient être sensible aux balles.

Voilà pour le moment.

[Vetea]

Un petit coucou de Marseille.

Je pense vous dévoiler prochainement une nouvelle version avec encore plus de contenus :
* Ajout des jeeps blindées.
* Ajout des vedettes blindées.
* Ajout de nouvelles musiques.
* Reequlibirage des stages.

Je réfléchi a ajouter de nouvelles armes ( bazooka, ... ), nouvelles unités, ...
Par contre, voudriez vous voir en priorité :
1/ Les tanks pilotables par Papi avec aussi des tanks IA ?
2/ Un mode coop' avec Mamie Commando ( nécessitant un pad ) ?
3/ Les deux !!

Bon week end.