Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 31 à 45 sur 45

Discussion: Mon moteur de jeu

  1. #31
    Avant le SVN tu peux essayer dropbox.
    Ça m'a sauvé de nombreuses fois.

  2. #32
    Citation Envoyé par Froyok Voir le message
    Avant le SVN tu peux essayer dropbox.
    Ça m'a sauvé de nombreuses fois.
    Vu l'actu de dropbox je ne crois pas ! ^^

    Sinon je parle d'un SVN mais hébergé chez moi , pas d'un serveur sur internet.
    Ça aurait pas particulièrement de sens pour un projet solo !

  3. #33
    C'est quoi le problème avec dropbox ?
    Pas après un SVN je trouve ça compliqué pour moi à mettre en place.

  4. #34
    Citation Envoyé par Froyok Voir le message
    C'est quoi le problème avec dropbox ?
    Pas après un SVN je trouve ça compliqué pour moi à mettre en place.
    Des problèmes de sécurité avec une méchante faille ce week end ...
    Des clés pas si privés ! Mais un dropbox dans google actu devrait te donner une idée plus précise !

    Sinon pour mettre en place un svn local :

    - Télécharger et installer tortoise svn.
    - Créer un répertoire ( sur un disque réseau par exemple) -> click droit -> Create repository here.
    - créer un répertoire de travail sur le pc de travail -> click droit -> SVN Checkout avec dans url le chemin réseau vers le précédent répertoire

    Même pas besoin d'un service serveur dans ce cas ... ( nécessaire si tu veut faire un vrai serveur dédié évidement )

  5. #35
    Contrairement à la mise à jour de ce topic, mon projet n'est pas mort !
    Je suis peu productif mais par contre j’étudie beaucoup :

    Le monde merveilleux des shaders
    Les API son ( Je pense utiliser OpenAl )
    Et Les API physique ... ( Au départ je partais vers Newtown mais je pense plutôt utiliser ODE )

    En tout cas une chose est sure, pour pouvoir utiliser les shaders correctement je vais devoir gérer différemment le rendu :
    - Implémenter le rendu sur texture, ce qui était prévu et plus ou moins préparé.
    - Gérer les passes multiples. Prévu aussi mais pas forcement de la façon dont les shaders vont me l'imposer. J'avais bien prévu de pouvoir gérer plusieurs passe sur la scène pour certains effet mais certains shaders peuvent avoir besoin qu'on redessine plusieurs fois le même objet.
    - Et le plus "complexe": gérer les paramètres des shaders entre ma scéne et le moteur graphique. Pour ça je pense utiliser le moteur de variables en ajoutant un type de variable pouvant faire référence à une ressource.

  6. #36
    Intéressant ce planning !
    Tu avais également regardé du côté de Bullet Physics pour ton moteur physique ?

  7. #37
    Citation Envoyé par Froyok Voir le message
    Intéressant ce planning !
    Tu avais également regardé du côté de Bullet Physics pour ton moteur physique ?
    J'ai jeté un coup d'oeil mais j'ai pas trouvé de Tutorial spécialement convainquant alors j'ai pas insisté.

    Sinon pour les shaders je me suis intéressé à Cg ( le language de shader de Nvidia ) et c'est assez intéressant, je pense que je vais utiliser leur API.
    Par contre je suis confronté à pas mal de zone de floue sur le fonctionnement des shader et surtout ce qu'on doit leur passer en parametre.
    Mais là j'ai mal la tête alors j’arrête pour aujourd'hui.

  8. #38
    Je vais définitivement utiliser Cg ! Il y a des trucs formidables dans cette API qui colle parfaitement avec ma façon de vouloir gérer les Shaders !

    Par contre la doc fait 356 pages ( en anglais évidement ) !

  9. #39

  10. #40
    Doxygen me génère une doc de 392 pages :




  11. #41
    Je suis tombé sur ce topic par hasard, je sais pas s'il est encore actif
    EDIT : en fait c'est tout ce sous-forum qui a l'air inactif

    Quoiqu'il en soit si tu cherches un p'tit serveur SVN gratuit et tout, y a unfuddle.com qui permet d'héberger ses p'tits projets de manière privée sans prise de tête (j'ai un peu fait le tour de tous les sites qui proposent ce genre de service, et c'est un des meilleurs avec FogBugz, mais ce dernier utilise Mercurial et non Subversion)

    En ce qui concerne Cg je te déconseille d'utiliser leur API : il est lent et n'est pas souvent mis à jour (du coup il manque pas mal de fonctionnalités). Par exemple depuis la version 3.0 d'OpenGL les fonctions du genre glVertexPointer, glColorPointer, etc. sont deprecated, or Cg ne propose pas d'alternative. Plutôt que d'utiliser entièrement l'API de Cg, personnellement j'utilise juste leur compilo pour transformer le Cg en HLSL ou GLSL, puis je passe le résultat dans le compilo de DirectX ou d'OpenGL.

    Evidemment l'autre problème c'est que Cg ne supporte que les vertex et fragment shaders, mais ça c'est plus délicat à résoudre
    Dernière modification par Tomaka17 ; 20/09/2011 à 18h08.
    Rust fanboy

  12. #42
    Ouais il est encore "actif" ... Mais malheureusement depuis quelques temps j'ai un peu la tête dans le guidon au boulot et c'est dur de rentrer le soir et de re-coder encore ! :/
    Même si je continue à me documenter et faire des modifs de temps en temps, c'est vraiment au ralentis.

    Pour le moment je me contente d'outils locaux, je trouve pas d’intérêt à faire de l’hébergement distant sur un projet solo. Et comme c'est moi qui manage Mantis et Svn au boulot ça me convient très bien.

    Ce qui m’intéressait dans cg c'est surtout d'avoir une interface commune qui comprend un peu tout. Mais même si j'ai fait preuve de beaucoup d'enthousiasme je ne suis pas totalement fixé encore. Il se peu qu'au final je reste sur les fonctions dédié de directx, principalement pour une question de paramétrage.

  13. #43
    Bon ben pour info je peut maintenant charger des fichier ".fx" donc HLSL en passant directement par DirectX et j'arrive à les appliquer sur mes objets ... mais sans paramètres pour ce soir.
    C’était finalement moins laborieux que ce que je craignais.
    Le plus chiant maintenant va être de gérer les paramètres de façon correcte ...

  14. #44
    Si tu parles des "uniform" personnellement je me fais pas chier pour ça
    Au moment de créer le shader, je créé aussi les constant buffers de la taille correspondante, et je mets dans une unordered_map (c'est la hash map du C++11) la liste des paramètres avec leur nom, leur offset et leur taille dans le buffer (même si la taille c'est juste pour vérifier qu'on ne fasse pas de connerie en copiant des trucs trop grands)

    Ensuite quand j'active un shader, j'active en même temps tous ses constant buffers.
    Si mon code veut modifier un paramètre du shader, je map le constant buffer en mémoire, je copie la valeur dedans mais je ne le démap qu'au moment de l'appel à DrawElements, comme ça on évite de map/démap plusieurs fois si on veut modifier plusieurs paramètres.

    C'est pas forcément la méthode la plus optimisée (même s'il n'y a pas de gouffre), mais c'est la moins chiante car tout ça se fait de manière transparente pour le reste du moteur
    Rust fanboy

  15. #45
    Non, en fait je parle plus simplement de paramétrer mes objets pour qu'ils envois ensuite les bon paramètres au shader.
    En fait j'essaye de respecter une certaine conception, ce qui complique un peu les choses si je veut rester propre.

    J'ai un gestionnaire de scène, un gestionnaire de ressources, un gestionnaire de variables. Chacun des gestionnaires peu posséder des objets avec des données à envoyer à l'effet.
    La scène par exemple va contenir un "noeud" qui contient les informations de positions, ainsi que des "pseudos pointeurs intelligent" vers des objets du gestionnaire de ressource ( modèles, textures et shaders ).
    Il faut donc que je trouve un moyen propre pour paramétrer mon élément de scène afin qu'il puisse envoyer ces différents objets dans les variables correspondantes de l'effet.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •