hello : Inateno

[Inateno]

'soir tout l’monde

Bon voilà moi c’est Inateno, ptét déjà vue sur d’autres fofo (déjà vue sur SFML 4ian)
Passioné de plein de chose, déteste peu de chose ^^
Etudes en animation 3D et images de synthèse (je fais du dessin aussi), 1ère anné (vue que je savais pas dessiné du tout c’était et c’est toujours dur ><)

But → travailler dans le monde du jeux vidéo
But ici → réaliser des jeux plus ou moins sympa afin de compléter mon book et aussi de mettre en application mon apprentissage.

Pourquoi j’ai choisis GD ? : déjà la raison numéro 1 qui à fait que j’ai pris ce log (à la base je voulais utiliser rpg maker pour faire un rpg et…) la gestion de la full HD (pas de limite, apparemment) dans les résolutions, gestion de la transparence, collisions par système physique (physx ??)

Bien que ça soit un sujet de présentation je vais quand même faire un petit point sur ce que j’ai pu voir du log (ça va éviter 40 sujet hein)
Dommages que:
_Ce soit un système de lecture XML uniquement (ou executer un commande ou lancer un fichier…) sans passer par le xml les .ini sont sympa aussi.
_la gestion du “mapping” soit vraiment primitive (alors là c’est certain on va pas s’amuser à faire du carreau par carreau comme rpg maker car faire un objet à chaque fois ouf ^^’) → en même temps c’est mieux pour certain type de jeux comme un shooting game
_on ne peut faire que “si la souris est sur” → un objet sprite (je pense qu’il aurait ptét été mieux de mettre dans souris puis, si la souris est sur l’objet → nom de l’objet (texte particule etc…)
_on ne peut pas (ou alors c’est bien caché) faire un changement de résolution de l’écran en faisant un redimensionnement automatique des images “sprite” et objet “texte” automatiquement (à part faire mettre à l’échelle si, pour chaque résolution
_le copier coller (ctrl+c / v / x) dans les évènement marche pas top
_le copier coller (ctrl+c / v / x) est inexistant dans les objets / scène / images
_on ne peut pas naviguer au clavier dans les évènement (bas haut / droite gauche, puis ctrl + c / v par exemple )
_on ne peut pas centrer le point d’origine sur un point précis dans la scène afin de faciliter l’édition / le déplacement en édition est un peu bof à la souris mais fonctionne avec les barre de scrolling
_peut être spécial à comprendre mais peut être plus rapide à l’édition (avis perso) un double clic sur un objet lors de l’édition permet, soit d’accéder à ses propriétés (plutôt qu’un message d’erreur), soit de créer directement un évènement avec la condition si on clique dessus, et nous placer le curseur dans la partie évènement (mais moins global)

Ce qui est bien, déjà dit en haut, franchement beau boulot je tiens à le dire (et je serais pas la pour poster en plus ), du coup il semble que j’ai trouvé, le moteur gratuit sympa, performant, qui gère la hd (enfin !) et qui à l’air d’en permettre vraiment pas mal, bien que comme tout moteur il à des défauts, il me semble qu’il est encore jeune et que par rapport à d’autre bien plus vieux, il est sur une très bonne voie ! (et des moteurs de jeux, j’en ai pas testé qu’un)
Ah oui, les petites fenêtre style débugger, performances, etc, vraiment super, mais faudrait éviter que ça en crée une par scène c’est assez saoulant (en plus ça doit bouffer pour rien) puis faut chercher la bonne fenêtre ><

Donc voilà j’ai découvert ce log il y à 6 mois sur le forum de SFML mais j’avais pas testé (les études tout ça) voilà qui est fait depuis plus de 2 semaine et j’adhère vraiment à la conception du moteur.
Quelques petits screen de ce que j’ai commencé à faire pour la route (un jeux de shoot je sais mais je commence d’abord par ça depuis le temps j’hésite à en faire un ) notez que tout est de ma réalisation perso et qu’un collègue de classe va s’y mettre aussi.

Mon Devian’art : http://inateno.deviantart.com/gallery/28649697#
Voilà, i’a que le hangar que j’ai honteusement piqué sur le net et texturé sur photoshop, mais je le ferais en 3D d’ici là que j’ai finis toute la prog.
Et le vaisseau aussi qui est pas fait dans la vue “hangar” mais ça sera fait aussi.

Merci de m’avoir lu et a+

[Colin]

Bienvenue !
Voilà une belle présentation !
En effet game dévelop a encore quelques soucis d’ergonomies (pas si grave que ça), mais comme tu le dis si bien : il est encore jeune et en voie de développement, et sinon pour mapper, tu peux y aller à coup de copier/coller (moi je l’utilise dans la mesure du possible, mais la plupart du temps, j’y vais à la main)
A ce que je vois, on va avoir droit à de bons jeux, très bons graphismes en tout cas ! S’ils sont bien réussis, ils peuvent se retrouver sur la page de présentation des meilleurs jeux créés GD (où il faut souvent des graphismes attirants et ton autorisation bien sûr).

Bonne création

[Crone123]

Bienvenue !
Belle présentation et bravo pour les graphismes !

[Neorigg]

Bienvenue !
J’adore les vaisseaux

[4ian]

_Ce soit un système de lecture XML uniquement (ou executer un commande ou lancer un fichier…) sans passer par le xml les .ini sont sympa aussi.

Les INI sont sympa, mais ce format date de 1985 et est ultra limité par rapport au XML. Par exemple, je vois pas comment on peut faire des sous groupes avec un fichier INI. Rien que ça, ça rend les INI inutilisable pour autre chose que stocker 2/3 infos.

_la gestion du “mapping” soit vraiment primitive (alors là c’est certain on va pas s’amuser à faire du carreau par carreau comme rpg maker car faire un objet à chaque fois ouf ^^') → en même temps c’est mieux pour certain type de jeux comme un shooting game

En effet, c’est dû au fait que GD ne soit orienté vers aucun type de jeu.
On peut quand même activer une grille et la magnétiser pour faciliter le mapping.

_on ne peut faire que “si la souris est sur” → un objet sprite (je pense qu’il aurait ptét été mieux de mettre dans souris puis, si la souris est sur l’objet → nom de l’objet (texte particule etc…)

Les autres objets n’ont pas possibilité d’être testé aussi “facilement” qu’un Sprite. Par exemple, je n’ai pas moyen de récupérer tous les pixels d’un texte pour ensuite faire une comparaison pour voir si la souris est sur le texte : Pareil pour les particules.
Mais par contre, la prochaine version aura un système de collision permettant de tester les collisions entre tout type d’objets : Si tu colle un objet à la souris, tu pourra donc tester si elle est sur un autre objet.

_on ne peut pas (ou alors c’est bien caché) faire un changement de résolution de l’écran en faisant un redimensionnement automatique des images “sprite” et objet “texte” automatiquement (à part faire mettre à l’échelle si, pour chaque résolution

La prochaine version proposera un paramètre pour choisir l’image sera étirée ou si les caméras devront avoir leur taille augmentée.

_le copier coller (ctrl+c / v / x) dans les évènement marche pas top

C’est corrigé pour la prochaine version.

_le copier coller (ctrl+c / v / x) est inexistant dans les objets / scène / images

Si, si, il est bien là pour les objets et les scènes. ( Clic droit, ou même Ctrl-C/Ctrl-V/Ctrl-X pour les objets ). Pour les images, c’est moins courant car on fait surtout qu’en ajouter ou retirer, d’où le fait que j’ai pas pris la peine d’implémenter ça.

_on ne peut pas naviguer au clavier dans les évènement (bas haut / droite gauche, puis ctrl + c / v par exemple )

Oui en effet.

_on ne peut pas centrer le point d’origine sur un point précis dans la scène afin de faciliter l’édition / le déplacement en édition est un peu bof à la souris mais fonctionne avec les barre de scrolling

Perso dans l’éditeur de scènes, je me déplace toujours avec la souris ( clic molette ) sans trouver que ça pose de problème ? Ca evite de bouger pour aller chercher les barres de défilements.
J’ai pas trop compris l’histoire du point d’origine ?

Ah oui, les petites fenêtre style débugger, performances, etc, vraiment super, mais faudrait éviter que ça en crée une par scène c’est assez saoulant (en plus ça doit bouffer pour rien) puis faut chercher la bonne fenêtre ><

Tu peux les “scotcher” dans l’éditeur de scène en les déplaçant jusqu’à qu’un cadre bleu apparaisse. Ca permet de rassembler les fenêtres et de cacher automatiquement celle qui ne correspondent pas à la scène actuellement éditée.

collisions par système physique (physx ??)

Box2D : box2d.org/

Jolie début de création en tout cas, content que GD te convienne

[Inateno]

Merci de cet accueil ^^
Pourquoi pas le mettre en présentation si vous voulez, je suis pas contre loin de là, mais je penses que ça sera plutôt à 4ian d’en décider
Heureux que les graphismes vous plaisent, j’espère qu’il en sera de même pour mes autres projets

_Ce soit un système de lecture XML uniquement (ou executer un commande ou lancer un fichier…) sans passer par le xml les .ini sont sympa aussi.

Les INI sont sympa, mais ce format date de 1985 et est ultra limité par rapport au XML. Par exemple, je vois pas comment on peut faire des sous groupes avec un fichier INI. Rien que ça, ça rend les INI inutilisable pour autre chose que stocker 2/3 infos.

_Hé bien, il est vrai que le xml est mieux adapté, p’tét juste une question de mauvaise habitudes (programmeur VB6 powa ^^ entre autres)

_la gestion du “mapping” soit vraiment primitive (alors là c’est certain on va pas s’amuser à faire du carreau par carreau comme rpg maker car faire un objet à chaque fois ouf ^^') → en même temps c’est mieux pour certain type de jeux comme un shooting game

En effet, c’est dû au fait que GD ne soit orienté vers aucun type de jeu.
On peut quand même activer une grille et la magnétiser pour faciliter le mapping.

_J’ai vue pour la grille automatique magnétisé, en effet ça facilite les choses, mais j’ai eu une idée pour mapper très rapidement des jeux de type RPG grâce à la collision réelle, par contre faut avoir un bon niveau en graphisme, et c’est plus lourd graphiquement !

_on ne peut faire que “si la souris est sur” → un objet sprite (je pense qu’il aurait ptét été mieux de mettre dans souris puis, si la souris est sur l’objet → nom de l’objet (texte particule etc…)

Les autres objets n’ont pas possibilité d’être testé aussi “facilement” qu’un Sprite. Par exemple, je n’ai pas moyen de récupérer tous les pixels d’un texte pour ensuite faire une comparaison pour voir si la souris est sur le texte : Pareil pour les particules.
Mais par contre, la prochaine version aura un système de collision permettant de tester les collisions entre tout type d’objets : Si tu colle un objet à la souris, tu pourra donc tester si elle est sur un autre objet.

_Pour le test, je pensais plus simplement, la source d’origine des particules, le texte compté comme un carré (prendre un peu au dessus à gauche jusqu’à un peu en dessous à droite

_on ne peut pas centrer le point d’origine sur un point précis dans la scène afin de faciliter l’édition / le déplacement en édition est un peu bof à la souris mais fonctionne avec les barre de scrolling

Perso dans l’éditeur de scènes, je me déplace toujours avec la souris ( clic molette ) sans trouver que ça pose de problème ? Ca evite de bouger pour aller chercher les barres de défilements.
J’ai pas trop compris l’histoire du point d’origine ?

Alors, le déplacement à la molette bug chez moi, quand je sort de la zone de la map visible, ça déclic pas du coup quand je reviens pour décliquer, retour à la case départ et je me déplace très doucement (un système de clic molette à la mozilla ? tu clic sur la molette et ça te fais survoler la zone en gardant ton curseur à peu près au milieu, jusqu’au déclic

Pour le point d’origine, quand tu clic sur revenir à l’origine ça te ramène à la position x: 0 y:0 placé en haut à gauche de ton écran je crois bien, si on pouvait le changer pour par exemple le placer sur la zone de départ, ou même en faire plusieurs point clé choisissable afin de naviguer rapidement et précisément.

Aussi je pense qu’un truc pour placer les sprite à une coordonnée précise serait utile (à par compter les cases, ou faire des test)
Je prend l’exemple de mon jeux de shoot, le fond d’écran j’ai du faire plusieurs test car j’ai limité le déplacement de la caméra jusqu’à une zone, hors le placement était un peu aléatoire et on voyait des bandes noirs sur les bords, replace, retest

Si j’avais pus faire : placer le point haut gauche de l’image en 0:0, j’aurais moins été embêté

Et aussi, ça viens de me revenir, si on pouvais bloquer la position d’objets dans l’éditeur (lock délock) pour éviter les mégardes

Ah oui, les petites fenêtre style débugger, performances, etc, vraiment super, mais faudrait éviter que ça en crée une par scène c’est assez saoulant (en plus ça doit bouffer pour rien) puis faut chercher la bonne fenêtre ><

Tu peux les “scotcher” dans l’éditeur de scène en les déplaçant jusqu’à qu’un cadre bleu apparaisse. Ca permet de rassembler les fenêtres et de cacher automatiquement celle qui ne correspondent pas à la scène actuellement éditée.

Allé dernier truc après j’embête plus xD
Les scotcher dans la fenêtre c’est bien joli mais ça réduit considérablement l’espace d’édition. Vue que j’édite en 1920*1080 j’ai besoin de tout l’écran, et vue que je suis en multiscreen j’en profite pour mettre les petite fenêtre détachable sur un autre écran.

Bonne journée les gens

[victor]

Bienvenue Inateno.

Les INI sont sympa, mais ce format date de 1985 et est ultra limité par rapport au XML. Par exemple, je vois pas comment on peut faire des sous groupes avec un fichier INI. Rien que ça, ça rend les INI inutilisable pour autre chose que stocker 2/3 infos.

Faut dire que le XML de GD est assez limité.

[4ian]

Faut dire que le XML de GD est assez limité.

J’avoue, mais ça fournit le minimum pour être mieux qu’un fichier INI quoi.

_Pour le test, je pensais plus simplement, la source d’origine des particules, le texte compté comme un carré (prendre un peu au dessus à gauche jusqu’à un peu en dessous à droite

C’est plus ou moins comme ça que ça se passera ( Utilisation de masque de collisions ) pour les collisions “inter objets” de la prochaine version.

(un système de clic molette à la mozilla ? tu clic sur la molette et ça te fais survoler la zone en gardant ton curseur à peu près au milieu, jusqu’au déclic

Mouais, je trouve le clic molette aussi pratique, si il faut parcourir de longues distances, un coup de “dezoom” et avec la molette, on se déplace alors très vite.

Aussi je pense qu’un truc pour placer les sprite à une coordonnée précise serait utile (à par compter les cases, ou faire des test)

Tu peux faire clic droit > Propriétés pour changer précisement les coordonnées ou utiliser les flèches du clavier.

Et aussi, ça viens de me revenir, si on pouvais bloquer la position d’objets dans l’éditeur (lock délock) pour éviter les mégardes

Oui, ça serait intéressant.

[Inateno]

Pour le déplacement à la souris dont je parle, il est bien à la molette.
Essayes avec firefox, tu réduit la fenêtre de façon à avoir un double scroll puis tu mets ta souris vers le milieu de l’écran et tu clic avec la molette en te déplaçant la où tu veux aller.

Faudra je fasse une vidéo en cas car moi ça saccade vraiment, ça donne mal à la tête