Discussion :

[Vetea]

Bonsoir Ynothan !
Ravi que les travaux reprennent !
Au plaisir de lire et surtout, tester tes nouveaux travaux !
Bon courage !!

[Ynothan]

Bonsoir à tous !

Je reviens ici donner quelques nouvelles

Je rentre dans une période où je ne pourrai pas vraiment vous faire profiter de mes avancées au niveau du développement puisque celles-ci touchent le moteur en lui-même.
Cela signifie que le temps passé et les lignes de code écrites ne seront pas proportionnels avec les résultats visibles pour les joueurs

En revanche je peux vous révéler quelques éléments du futur jeu !
En complément du 1er message, qui vous donne le synopsis, voici quelques informations :

• Comme vous l'avez compris il s'agira d'un jeu de science fiction dans lequel vous en apprendrez plus en avançant dans le jeu
• Vous pourrez communiquer avec les survivants rencontrés
• Ils pourront vous apprendre des informations vous aidant à recouvrer la mémoire
• Ils pourront pour certains vous aider davantage et vos donneront des informations capitales pour avancer
• Vous comprendrez ainsi petit à petit qui vous êtes, d'où vous venez, et ce qui a conduit l'humanité à cette situation critique
• Bien sûr, vous rencontrerez bien assez tôt vos ennemis et apprendrez à les appréhender
• Certains éléments du décors seront utiles à votre survie
• Votre nano-équipement sera votre meilleur allié

Je vous invite, si vous le souhaitez, à participer en me donnant vos impressions, vos idées, vos remarques !
J'ai déjà 1 million d'idées mais je suis certains que vous en avez vous aussi

A bientôt

[Ynothan]

Bonsoir à tous,

Un petit passage sur le forum pour vous communiquer mon avancement

Comme dit plus haut, je travaille actuellement sur la partie physique, qui constitue pour moi la partie la plus délicate d'un moteur tel que le mien
J'avance donc doucement mais surement !

Je reprends le concept du premier moteur, avec une archi complètement revue et une bien meilleure souplesse, ce qui offre beaucoup plus de possibilités.

A l'image des objets à dessiner qui sont constitués de "Drawable", les objets dont les collisions sont calculées sont constitués de "Collidable".
Ce sont ces "Collidable" qui peuvent entrer en collision et engendrer une réponse à cette collision.

Il s'agit de cercles et/ou de segments.

Par exemple, le héros, qui commence à ressembler à un héros , est constitué de 2 cercles :



Il est évident que ces "Collidable" ne seront plus affichés dans le jeu. Leur affichage dépend d'un paramétrage du moteur graphique.

Vous pouvez voir également les quelques évolutions à travers la nouvelle démo, et notamment le déplacement du héros grâce aux touches prévues à cet effet

Je vous rappelle les touches par défaut :

• Passer de l'écran d'accueil à l'écran de jeu : Touche Entrée
• Afficher l'écran de choix des armes : Presser la touche CTRL
• Choisir l'arme : Utiliser la molette
• Cacher l'écran de choix des armes : Relâcher la touche CTRL
• Reculer : Touche Q
• Avancer : Touche D
• S'accroupir : Touche S
• Viser : Déplacer le pointeur de la souris
• Frapper : Touche F
• Tirer : Clic gauche (renouveler ou laisser appuyé selon l'arme choisie)
• Lancer un projectile : Clic droit
• Explosion du sprite du héros : Touches F1 à F4

Ma signature contient toujours le lien vers la toute dernière démo

PS : Je préfère vous le rappeler à chaque nouvelle démo : pour le moment il vous faut ouvrir puis fermer une fenêtre de la barre de menu (ex : Audio Setting) afin de débloquer le focus de la fenêtre principale pour que le clavier fonctionne.

[yahiko]

Je ne peux pas évaluer la complexité que cela pourrait avoir, mais tu pourrais peut-être modéliser ton masque de collision sous la forme d'ellipses (qui sont une généralisation du cercle).

C'est juste une idée comme cela.

Sinon, bonne continuation.

[Ynothan]

Merci

Effectivement les ellipses compliqueraient un certains nombre de calculs. Ta remarque est relativement pertinente mais à priori je vais conserver mes cercles

A l'heure actuelle je peux utiliser maintenant 3 collidables :

• Cercle
• Segment
• Box

Je me suis repenché également sur mon quadtree.
L'objectif ce soir, si tout se passe bien, est de l'améliorer et le finaliser.

A bientôt

[Ynothan]

Bonsoir à tous,

Pour compléter mon intervention d'hier, j'ai le plaisir de vous annoncer que mon quadtree est opérationnel

Pour rappel :
Source Wikipedia : "Les quadtrees sont le plus souvent utilisés pour partitionner un espace bidimensionnel en le subdivisant récursivement en quatre nœuds."

En pratique dans SpinyENGINE :
En clair, la scène, qui est un rectangle, est divisée récursivement en 4 rectangles de tailles identiques. Néanmoins, un sous-rectangle est créé si et seulement si il contient au moins un objet.
Les objets sont répartis de telle façon que chaque objet sera contenu dans le plus petit rectangle qui le contient entièrement.

Rien de mieux qu'une capture d'écran pour illustrer ce concept abstrait
(Sur cette capture, j'ai désactivé l'affichage des sprites et des collidables afin de présenter uniquement le Quadtree. Le héros se résume donc à un carré noir )



Pour le même prix , je vous mets à disposition, dans ma signature, le lien vers une nouvelle démo qui vous permettra de voir la mise à jour du quadtree en temps réel en fonction des déplacement du "héros"... ou plutôt du carré qui le représente

Vous n'aurez besoin que des 2 touches "Q" et "D" pour vous déplacer, une fois dans l'écran de jeu.


Ma signature contient toujours le lien vers la toute dernière démo

PS : Je préfère vous le rappeler à chaque nouvelle démo : pour le moment il vous faut ouvrir puis fermer une fenêtre de la barre de menu (ex : Audio Setting) afin de débloquer le focus de la fenêtre principale pour que le clavier fonctionne (problème SFML). Appuyez ensuite sur une touche du clavier, après la barre de chargement, afin d'accéder à l'écran de jeu.

[maeiky]

Super le projet, j'adore

J'ai pour habitude de mettre les DLL en "fichiers cachés" pour que ne soient visibles que le fichier exécutable ainsi que le dossier "data".
Car avec Qt + SFML, cela fait un certain nombre de DLL... (on est maniaque ou on ne l'est pas )

Je me demandais justement comment tu avais fait pour faire disparaître ces DLL pour S&K , j'ai pensé un moment à une compilation statique. . Mais tu ne peux pas être aussi maniaque que moi, j'ai un projet entier tout de zéro pour éliminer les dépendances .

J'ai voulue tester ta dernière démo, mais elle bloque à l'écran "EERIE INABITANT", j'ai essayé toutes les touches. J'ai pas de problème avec S&K.

Malgré tout, c'est prometteur

[Ynothan]

Merci maeiky

Il s'agit d'un gros projet qui débute avec la refonte du moteur. Les résultats visibles pour le joueur sont donc parfois minimes pour le moment.
Lorsque j'aurai terminé cette partie, je pourrai laisser parler mon imagination et proposer un jeu original

Pour ce qui est de la démo, c'est ce que je précise à la fin de mon message.
En effet un problème dû à la SFML 2.1 retire le focus de la fenêtre, ce qui provoque l'absence de gestion des événements clavier.

La solution que je propose est d'ouvrir puis fermer une fenêtre annexe depuis la barre de menu (ex : Audio Setting). Cela permet à la fenêtre principale de reprendre le focus.
Ensuite, il suffit de presser n'importe quelle touche du clavier pour accéder à l'écran de jeu.

Je suis conscient que cette manipulation est ennuyeuse
Visiblement le problème a été corrigé par Laurent Gomila, mais seule les sources sont disponibles. Je vais essayer de compiler une version de SFML.

[maeiky]

Ok, c'était ça
Juste 2 petits détails :
La rotation serait tellement plus magnifique avec une petite interpolation linéaire des pixels, avec ça tu n'aurais même pas besoin d' anti-aliasing (que je trouve plutôt étrange).
Ça serait bien qu'il y aie une détection du clavier qwerty ou bien utilisé les flèches directionnels, de plus la config clavier ne fonctionne pas.

Par curiosité, as-tu l'intention de rendre ça open-source?

[Ynothan]

Au niveau de la rotation j'utilise la méthode des Drawable de SFML et sincèrement je ne pense pas qu'un simple algorithme donne un résultat plus efficace

Je viens de tester la config du clavier et effectivement elle ne fonctionnait plus. Merci pour l'info J'ai identifié le problème. Il est corrigé

Pour ce qui est des sources, je me laisse le temps d'y penser étant donné qu'il y a encore pas mal de travail à fournir sur le moteur

[maeiky]

Bon, je t'ai concocté une petite application et une image pour que tu voie la différence :




Et voici l'application où tu peux appliquer n'importe quel transformation sur l'image en question, il n'y a qu'un .exe car tout est "embed" (ce n'est pas un virus):

EE_Pixels.exe

[Ynothan]

Bonjour maeiky,

J'ai testé ton application, plusieurs points.

Le résultat est très convaincant visuellement, rien à redire
Néanmoins un petit bémol sur la consommation CPU qui me semble élevée mais c'est un simple constat. Peut-être as-tu une explication, il y a peut-être une raison à cela ?

Ensuite pour mon moteur, je souhaite garder un esprit un peu ancienne génération donc le fait que les images soient un poil pixelisées ne me choque pas du tout, je dirais même que c'est voulu.
Et encore une fois, je suis un peu sceptique sur le fait qu'un algorithme "maison" puisse donner un résultat visuel meilleur pour une consommation CPU identique

Cependant félicitation pour ton appli qui est agréable à l’œil, propre et efficace

[maeiky]

Merci, oui c'est voulue, la consommation CPU est élevé car tout est entièrement dessiné par CPU (en 60fps et certaines optimisations ne sont pas terminer comme le dessin par régions). C’est à la base surtout pour un question de portabilité et puisque l'on ne fait pas nécessairement des jeux, que j'ai eu le projet assez fou de faire du dessin pixel par pixel. Aujourd'hui je travail à intégrer la carte graphique à tout ça. Avec OpenGL, ça se fait sans trop de mal (difficile de battre la complexité de ce que j'ai dû faire auparavant). J'ai un résultat au pixel près, résultant un consommation CPU pratiquement null.

Puisque SLMF utilise OpenGL, il est normal que la consommation soit moindre que l'application que je présente. La bonne nouvelle, c'est que l'algorithme dont que je parle est déjà intégré à OpenGL, il suffit d'appliquer un filtre à ton image :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

De plus, si tu crée une minimap de ton image, lors d'un "downsize" le résultat pourra être encore plus beau.

J'aime le principe du pixelisé qui donne un style, mais les rotations à la GL_NEAREST brise l'image.

[Ynothan]

Il n'est pas impossible que je revienne sur cet aspect par la suite mais à l'heure actuelle j'ai déjà beaucoup de points sur lesquels travailler

Je continue à améliorer mon quadtree ainsi que ses interactions avec les objets.
J'avance doucement mais surement dans mon architecture concernant les collisions.

Par ailleurs j'améliore également la gestion de la caméra qui sera activée sans doute dans la prochaine petite démo.

Ces derniers jours j'ai également créé de nouvelles classes que je range dans "utilities", telle que les classes "Point", "Line", Circle", "Rectangle", "Color"...

Conclusion cela avance tout de même pas mal, un jour vous aurez un jeu digne de ce nom

A bientôt

[maeiky]

Je viens de voir dans les source de la SFML qu'en activant l'option "smooth" de la texture ça active le filtre linéaire d'OpenGL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
void Texture::setSmooth(bool smooth)
{
    if (smooth != m_isSmooth)
    {
        m_isSmooth = smooth;
 
        if (m_texture)
        {
            ensureGlContext();
 
            // Make sure that the current texture binding will be preserved
            priv::TextureSaver save;
 
            glCheck(glBindTexture(GL_TEXTURE_2D, m_texture));
            glCheck(glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, m_isSmooth ? GL_LINEAR : GL_NEAREST));
            glCheck(glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, m_isSmooth ? GL_LINEAR : GL_NEAREST));
        }
    }
}

Une autre petite remarque :



Gérer inutilement du vide est mortel, même si c'est afficher par GPU. Pourquoi ne pas juste recadré ton image et lui associer les coordonnées d’affichages? Si les autres n’ont pas la même dimension, leurs coordonnées donneront la même position. Mais ce n'est qu'une question d'optimisation qui peut attendre. Tu pourrais aussi séparer l'arme du personnage.

Tu utilise des images trouvé sur le web. Est-ce le personnage définitif, ou c'est temporaire?

En passant j'adore la physique pour S&K, si jamais tu réussi à intégrer des courbes ça serait encore plus génial.

[Ynothan]

Bonsoir,

Je viens de voir dans les source de la SFML qu'en activant l'option "smooth" de la texture ça active le filtre linéaire d'OpenGL

Oui le "smooth" de SFML c'est exactement ce que j'utilise dans mon option d'anti-aliasing

Gérer inutilement du vide est mortel, même si c'est afficher par GPU. Pourquoi ne pas juste recadré ton image et lui associer les coordonnées d’affichages? Si les autres n’ont pas la même dimension, leurs coordonnées donneront la même position. Mais ce n'est qu'une question d'optimisation qui peut attendre. Tu pourrais aussi séparer l'arme du personnage.

Oui c'est "inutile" et j'en suis conscient.
Néanmoins je crée une grille (comme tu peux le voir dans le dossier "data/png/game/") avec les différentes actions du héros. Le programme choisi, à chaque tour de boucle, la case de la grille à afficher qui correspond à l'action du héros. Ma grille doit avoir des cases assez grandes pour que tous les sprites puissent entrer dans une case.
Ce qui fait qu'il y a du vide.
Pour d'autres objets moins complexes que le héros, il y a beaucoup moins de pixels transparents.

Quant à séparer les armes du personnage cela me parait inconcevable. Cela compliquerait énormément la gestion compte tenu du nombre de combinaisons action/arme possibles, la rotation du buste etc
Et dans l'absolu, cela n'apporterait rien de plus...

Tu utilise des images trouvé sur le web. Est-ce le personnage définitif, ou c'est temporaire?

Le personnage est définitif. Cela fait longtemps que j'avais envie d'utiliser ces sprites pour faire un jeu de plateforme différent de Sonic

En passant j'adore la physique pour S&K, si jamais tu réussi à intégrer des courbes ça serait encore plus génial.

Mon moteur gèrera évidemment les courbes, puisque tout ce qui était possible dans le 1er moteur, le sera dans le nouveau.
J'imagine que tu veux dire "intégrer des courbes dans ce nouveau jeu" ?

Je souhaite effectivement proposer des courbes dans ce prochain jeu, dans la mesure où il serait frustrant de n'avoir que des plateformes horizontales en utilisant mon tout nouveau moteur tout neuf

[maeiky]

Oui le "smooth" de SFML c'est exactement ce que j'utilise dans mon option d'anti-aliasing

Ça me surprend un peu ... quoi que pas tant que ça, c’est vraiment pas évident d'avoir le bon alignement des vertex et un shader au pixel près.

Mon moteur gèrera évidemment les courbes, puisque tout ce qui était possible dans le 1er moteur, le sera dans le nouveau.

Tu gère une série de droites pour faire une courbe, je pensais plus à l’intégration directement de courbes (de préférence quadratique) comme ici :

http://lab.andre-michelle.com/physics-engine
http://recycle.andre-michelle.com/as3/beta3/revive/

Cela fait longtemps que j'avais envie d'utiliser ces sprites pour faire un jeu de plateforme différent de Sonic

Je ne sais pas quel quantité d'image tu as, mais si tu ajoute des décors ou autre éléments, les images d'un autre auteur risque de ne pas être du même style.

Pour le vide autour des images, faire un système d'auto-recadrage avant de créer le sprite pourrait faire.

[Ynothan]

Tu gère une série de droites pour faire une courbe, je pensais plus à l’intégration directement de courbes (de préférence quadratique) comme ici :

http://lab.andre-michelle.com/physics-engine
http://recycle.andre-michelle.com/as3/beta3/revive/

Hmm ce sont de vrais moteurs physiques que tu présentes là

Comme je l'ai dit plus tôt, je pense que la partie physique est sans doute la partie la plus délicate et la plus complexe dans un moteur de jeu amateur. Je ne sais pas si tu as idée de la complexité des moteurs que tu me présentes, mais c'est une autre pair de manches

Par ailleurs ce type de moteur ne serait pas rentabilisé pour un jeu comme le mien donc je préfère réaliser mon propre moteur physique, plus simple mais adapté à mes besoins.

Je ne cherche pas à reproduire le CryEngine

[maeiky]

Je te lance des idées, le niveau de complexité est pas si pire dans le sens qu'il est déjà écris
Par ailleurs là où ça peu devenir plus compliqué est au niveau des performances, résoudre les bogues et l'ajout d'autre fonctionnalité.

Je te félicite d'avoir fait ta propre physique original et surement bien plus adapté pour les jeux que tu envisage, sans avoir copier un box2D ou autre.

Je ne cherche pas à reproduire le CryEngine

C'est là tout le contraire, la physique des courbes est utilisé nul part, du moins pas à ma connaissance. C'est aussi encore un moteur 3D qui se base sur des triangles, et comment fait ton une courbe? Avec encore plus de triangles. Pourtant la 3D avec courbe est bien possible et ça en résulterait une définition parfaite pour de meilleurs performances. Tout ça pour dire qu'au lieu de tenté de faire mieux, on peu faire différent.

Je me demandais aussi ce que tu allais utilisé comme graphique pour les autres éléments du jeu?

[Ynothan]

Je te lance des idées, le niveau de complexité est pas si pire dans le sens qu'il est déjà écris
Par ailleurs là où ça peu devenir plus compliqué est au niveau des performances, résoudre les bogues et l'ajout d'autre fonctionnalité.

Bien sûr oui ce sont des idées C'est toujours intéressant de débattre sur différentes orientations.
Cela dit je compte garder la direction que j'ai prise. Si je parviens à mettre en oeuvre ce que je prévois, mon moteur sera très efficace pour le type de jeu visé.

"Inutile d'utiliser un lance-roquettes pour tuer une mouche"
J'aime assez cette image

Ça ne veut pas dire que je ne veux pas me confronter aux difficultés, je t'assure que j'ai mon lot

Mais la finalité étant de sortir un jeu qui utilise mon moteur, je ne veux pas prendre des années à développer celui-ci.

Après, qui sait, peut-être que je souhaiterai par la suite améliorer la partie physique

Je te félicite d'avoir fait ta propre physique original et surement bien plus adapté pour les jeux que tu envisage, sans avoir copier un box2D ou autre.

Merci

C'est en effet le but recherché.
Je n'ai pas la prétention de créer quelque chose d'exceptionnel, mais ce qui me caractérise, c'est le perfectionnisme et la persévérance

Je me demandais aussi ce que tu allais utilisé comme graphique pour les autres éléments du jeu?

Ma première idée était de piocher des graphismes libres. Car pour le coup, je dois me rendre à l'évidence, je suis incapable de créer mes propres graphismes. Je peux faire les plateformes, quelques objets ou quelques paysages mais en aucun cas je pourrai modéliser des personnages par exemple.

La deuxième solution que j'envisage, c'est de me rapprocher d'un graphiste.