On s'éloigne du sujet d'origine, mais c'est intéressant. Ca veut donc dire qu'il n'y a qu'en assembleur que le bool existe. En même temps c'est mieux pour appairé la mémoire. Parcontre on doit pouvoir regrouper plusieurs bool et les tester par masque de bits genre "monGroupe and 8" ou quelque chose comme ça, non ?
On s'éloigne du sujet d'origine, mais c'est intéressant. Ca veut donc dire qu'il n'y a qu'en assembleur que le bool existe. En même temps c'est mieux pour appairé la mémoire. Parcontre on doit pouvoir regrouper plusieurs bool et les tester par masque de bits genre "monGroupe and 8" ou quelque chose comme ça, non ?
Heu ça ne veut pas dire grand chose là ta phrase j'en ai peur...
"il n'y a qu'en assembleur que le bool existe" : au niveau processeur (registres en particulier), ce que manipule l'assembleur, la notion de booléen n'est même pas connue : les régistres sont au minimum de la taille d'un octet. Les booléens n'ont toujours été en soit que des entiers (sur 8 bits ou plus), ça n'a toujours été qu'une convention du langage parce qu'on manipule souvent ce genre de données, mais en fait ce ne sont qu'une interprétation du flag Z des registres, un entier nul étant assimilé au booléen false et tout autre valeur non nulle assimilée à true (car une instruction if n'est rien d'autre qu'un JNZ déguisé, autrement dit un test si le résultat de l'expression vaut zéro ou pas)
Par contre il existe des artifices par exemple en C pour "regrouper plusieurs booléens dans un octet" évidemment, ça c'est ta façon d'organiser tes données. Tu peux par exemple créer un "bitfield", ou utiliser une variable de la taille d'un octet dans le but de stocker 8 valeurs booléennes, et ensuite tester cet octet bit à bit avec des masques. C'est ce qu'on appelle en général des "flags" voire des "OR-flags" car on fait alors un OU bit à bit pour composer le flag lorsqu'on l'affecte.
Mais en soit au niveau compilation et processeur, ça n'est pas spécialement vu comme des booléens non plus, ce n'est qu'un artifice, certes commun, mais qu'une façon comme une autre de représenter des booléens, alors que le type booléen en lui-même n'existe pas, et n'est en fait sous le capot qu'un entier interprété par les expressions de test comme "if" ou "while" comme étant false si sa valeur est nulle et true sinon.
Pour une phrase qui ne veux pas dire grand chose, t'a réussis à lui trouver une réponse et en plus ça répond bien à mes interrogations. Effectivement ça me rappel des choses tout ça et t'as raison le plus petit paquet de mémoire finalement c'est bien la taille minimale d'un registre. Même si l'on peut accéder a chacun des bits de ce registre.
Bah en assembleur il n'y a pas de types, donc pas de bool, mais la logique est purement binaire oui (dans telle condition, sauter à telle instruction, sinon, continuer...)
Bon c'est un peu hors sujet mais ça concerne toujours la 3D. J'ai fait un peu d'OpenGL mais je me rend compte que pour modéliser des objets et une map sympa ca va être un peu gallère. J'ai donc décidé de modéliser tout ça via Blender puis d'exporter le tout. Si j'ai bien compris j'aurai besoin d'un moteur 3D pour faire ça, et il n'y aura "plus" qu'à gerer la caméra. Si il y en a qui s'y connaissent un peu ce serait cool de me dire si mon raisonnement est correct. En moteur 3D je pensais prendre Irrlicht.
Oui le plus simple c'est en effet de prendre un moteur 3D... Déjà rien que pour décoder les fichiers VRML ou X3D que Blender ou tout autre outil d'authoring 3D va te générer, rien que ça sinon ça prend du temps à faire :P Et les moteurs 3D gèrent en général pas mal d'autres choses de toute façon qui est sinin bien prise de tête à gérer (chargement des ressources et des textures, avec optimisation et déchargement des textures quand il n'y en a plus besoin, gestion de divers formats d'image pour générer les textures, ainsi que le mipmapping, gestion des textures non puissance de 2, adaptation de l'algo le plus adéquat selon ce qui est supporté par la carte graphique, et j'en passe...
Par contre je n'ai jamais utilié Irrlicht, je ne connais pas ce moteur, donc je ne peux pas te conseiller dessus désolé
J'en ai pas utilisé beaucoup, mais j'ai eu l'occasion de travailler avec Torque (et j'ai pas aimé du tout... mais certainement parce que mon job était là dessus d'aller mettre les mains dans le cambouis dudit moteur pour le modifier " au lieu de juste l'utiliser comme c'est prévu pour " et que je m'y suis vite perdu ça m'a saoulé ^^). J'ai aussi eu entre les mains des projets utilisant Virtools, assez prometteurs voire impressionnants (mais j'ai pas développé avec pour ma part).
Sinon le moteur 3D du moment, c'est Unity : je l'utilise au taf pour développer des mondes 3D interactifs sur iPhone, c'est assez bluffant aussi. Mais payant (comme les 2 précédents d'ailleurs je crois ?) Dans les connus y'a Ogre aussi, qui a bonne réputation et est pas mal utilisé.
Mais bon, tout ça est loin d'être une liste exhaustive, d'autant que pour ma part, pour les projets 3D sur lesquels j'ai bossé, ce n'est pas moi qui décidait du moteur graphique à utiliser, c'est souvent le client qui l'imposait comme contrainte, ou alors un état de l'art avait été fait au début du projet bien avant mon arrivée dessus...
Du coup j'aurais du mal à te décrire les caractéristiques les meilleurs et pourquoi choisir tel ou tel autre... en plus y'en a un sacré paquet, de moteurs graphiques 3D existants, donc dur de faire un choix...
---
Sinon je viens de tomber sur un site sur lequel je te conseille d'aller faire un tour, c'est devmaster.net, sur lequel tu trouveras a une base de données de moteurs 3D disponibles assez complète... et surtout dans laquelle on peut rechercher selon des critères propres aux moteurs 3D (plateforme supportée, prix, mais aussi techno utilisée (OpenGL dans ton cas), si il implémente telle ou telle feature...
Pour les moteurs (1) gratuits (2) tournant sur Mac, (3) utilisant l'OpenGL, (4) en langage C/C++ et (5) en version stable (pas en alpha ou beta quoi), il me trouve cette liste de résultats. A toi de rafiner les résultats... ou de comparer la liste des features qu'ils offrent selon tes besoins, ainsi que les notes (facilité d'utilisation, etc) qu'ils leur donnent.
Réponses
Ben y'a pas de mal. T'as une stratégie pour convertir ton école ? Lol.
Ils savent que statistiquement les mac users ont des plus gros attributs?
"il n'y a qu'en assembleur que le bool existe" : au niveau processeur (registres en particulier), ce que manipule l'assembleur, la notion de booléen n'est même pas connue : les régistres sont au minimum de la taille d'un octet.
Les booléens n'ont toujours été en soit que des entiers (sur 8 bits ou plus), ça n'a toujours été qu'une convention du langage parce qu'on manipule souvent ce genre de données, mais en fait ce ne sont qu'une interprétation du flag Z des registres, un entier nul étant assimilé au booléen false et tout autre valeur non nulle assimilée à true (car une instruction if n'est rien d'autre qu'un JNZ déguisé, autrement dit un test si le résultat de l'expression vaut zéro ou pas)
Par contre il existe des artifices par exemple en C pour "regrouper plusieurs booléens dans un octet" évidemment, ça c'est ta façon d'organiser tes données. Tu peux par exemple créer un "bitfield", ou utiliser une variable de la taille d'un octet dans le but de stocker 8 valeurs booléennes, et ensuite tester cet octet bit à bit avec des masques. C'est ce qu'on appelle en général des "flags" voire des "OR-flags" car on fait alors un OU bit à bit pour composer le flag lorsqu'on l'affecte.
Mais en soit au niveau compilation et processeur, ça n'est pas spécialement vu comme des booléens non plus, ce n'est qu'un artifice, certes commun, mais qu'une façon comme une autre de représenter des booléens, alors que le type booléen en lui-même n'existe pas, et n'est en fait sous le capot qu'un entier interprété par les expressions de test comme "if" ou "while" comme étant false si sa valeur est nulle et true sinon.
Effectivement ça me rappel des choses tout ça et t'as raison le plus petit paquet de mémoire finalement c'est bien la taille minimale d'un registre. Même si l'on peut accéder a chacun des bits de ce registre.
En moteur 3D je pensais prendre Irrlicht.
Et les moteurs 3D gèrent en général pas mal d'autres choses de toute façon qui est sinin bien prise de tête à gérer (chargement des ressources et des textures, avec optimisation et déchargement des textures quand il n'y en a plus besoin, gestion de divers formats d'image pour générer les textures, ainsi que le mipmapping, gestion des textures non puissance de 2, adaptation de l'algo le plus adéquat selon ce qui est supporté par la carte graphique, et j'en passe...
Par contre je n'ai jamais utilié Irrlicht, je ne connais pas ce moteur, donc je ne peux pas te conseiller dessus désolé
Bon bah je vais devoir me former à Blender .... Trop de truc à faire.
Tu connais quoi en moteur ?
Hum :P
J'en ai pas utilisé beaucoup, mais j'ai eu l'occasion de travailler avec Torque (et j'ai pas aimé du tout... mais certainement parce que mon job était là dessus d'aller mettre les mains dans le cambouis dudit moteur pour le modifier " au lieu de juste l'utiliser comme c'est prévu pour " et que je m'y suis vite perdu ça m'a saoulé ^^). J'ai aussi eu entre les mains des projets utilisant Virtools, assez prometteurs voire impressionnants (mais j'ai pas développé avec pour ma part).
Sinon le moteur 3D du moment, c'est Unity : je l'utilise au taf pour développer des mondes 3D interactifs sur iPhone, c'est assez bluffant aussi. Mais payant
Dans les connus y'a Ogre aussi, qui a bonne réputation et est pas mal utilisé.
Mais bon, tout ça est loin d'être une liste exhaustive, d'autant que pour ma part, pour les projets 3D sur lesquels j'ai bossé, ce n'est pas moi qui décidait du moteur graphique à utiliser, c'est souvent le client qui l'imposait comme contrainte, ou alors un état de l'art avait été fait au début du projet bien avant mon arrivée dessus...
Du coup j'aurais du mal à te décrire les caractéristiques les meilleurs et pourquoi choisir tel ou tel autre... en plus y'en a un sacré paquet, de moteurs graphiques 3D existants, donc dur de faire un choix...
---
Sinon je viens de tomber sur un site sur lequel je te conseille d'aller faire un tour, c'est devmaster.net, sur lequel tu trouveras a une base de données de moteurs 3D disponibles assez complète... et surtout dans laquelle on peut rechercher selon des critères propres aux moteurs 3D (plateforme supportée, prix, mais aussi techno utilisée (OpenGL dans ton cas), si il implémente telle ou telle feature...
Pour les moteurs (1) gratuits (2) tournant sur Mac, (3) utilisant l'OpenGL, (4) en langage C/C++ et (5) en version stable (pas en alpha ou beta quoi), il me trouve cette liste de résultats. A toi de rafiner les résultats... ou de comparer la liste des features qu'ils offrent selon tes besoins, ainsi que les notes (facilité d'utilisation, etc) qu'ils leur donnent.