Anonyme a écrit 589 commentaires

Elle envoie le bytecode au cpu sans rien faire ?
Nan elle envoie le resultat de la compilation.

Et quand ça marche tu vires dmalloc pour ne conserver que les contrôles nécessaires. C'est une pratique très courrante...
Et qui te garantie que tu as prevu tous les cas d'utilisation... A mais c'est vrai tu es tres fort et tu as tout prevu meme les cas les plus tordus ... A t'endendre les bugs n'existeraient pas.

Une jvm en java qui se bootstrap sans jvm additionnel
C'est assez fort comme truc effectivement, mais a mon avis ils utilisent tout de meme une mini JVM pour initier le noyau de Jikes. Une fois cette base en memoire, le reste de la JVM peut s'executer. Ou alors ils ont resolu le probleme de l'oeuf et de la poule...

Même si c'est du bytecode, le bytecode doit être interprété
Mais non !!! puisqu'on te dis que quand la JVM le peut, le bytecode est compilé par anticipation !!!! donc plus d'interpretation pendant l'execution...

Et le développeur en C peut utiliser son cerveau et voir qu'il n'y a pas de débordement et ne jamais faire de teste.
Oulala la bonne idée ;)

Et pourquoi ils le font pas en Java alors ?
Parce qu'il faudrait une machine virtuelle pour faire fonctionner cette machine viruelle ecrite en Java.

Il me semble qu'au moment où j'ai lu la news, cette remarque n'y était pas encore...

Oui tout a fait, j'ai fait une news pour ca mais le modero a preferé l'inclure dans celle de Java3D. Je pense qu'il aurait fallu modifier le titre aussi mais bon .... au passage mon pseudo a ete ecorché :(

Je n'est pas dit qu'OpenGL etait difficile d'utilisation. Les mecanismes d'OpenGL sont relativement simples a comprendre et on peut faire tres facilement en quelques lignes un cube qui tourne par exemple.

Mais OpenGL n'est pas fait pour etre utilisé directement dans un jeux. Les routines proposées sont de bas niveaux (au sens 3D) et tu devras coder la plupart des algorithmes de reduction du nombre de polygones, d'eclairage, d'ombres, d'effets speciaux ... en gros ecrire un moteur. Et crois moi cette tache n'est pas a la portée de tout le monde.

J'essayais juste d'expliquer pourquoi Java3D n'as pas vraiment eu de succes. La discussion a tournée sur la comparaison entre des binddings OpenGL et Java3D ce qui n'a aucun sens a mon avis. J'ai expliqué en quoi cette comparaison n'avait pas de sens et qu'il etait plus simple et plus facile (voir meme plus efficace) d'utiliser Java3D pour faire un jeux que de se baser sur des binddings OpenGL meme si ceux-ci exploitent les dernieres fonctionnalités des spec.

Oui tout a fait d'accord, mais j'ai du mal m'expliquer, avec un dessin ca va etre plus clair :


Application
^
|
Moteur
^
|
OGL

Tu compares Java3D a OpenGL c'est comme si tu comparais l'assembleur au C++ (pas top comme exemple mais ca illustre bien ce que je veux dire).

les jeux state of the art sont écrits en OpenGL
Les jeux state of the art ne sont pas ecrits en OGL, c'est le moteur utilisé par ces jeux qui exploite OGL, le jeux en lui meme "ne connait pas" OGL.

OGL et D3D ne connaissent qu'une primitive : le triangle. Si tu programmes un cube directement sur OGL, tu devras explicitement decrire l'ensemble des triangles composant ton cube. Le but du moteur est justement d'eviter cela et de te fournir des routines de plus haut niveau pour demander directement un cube en une seule ligne (a peu pres).

Tu veux modifier ton cube : en OGL tu devras modifier a la main l'ensemble des triangles, avec le moteur uniquement la largeur du cube.

Donc le developpeur a le choix entre :

- utiliser Java3D ;
- reecrire un moteur complet au dessus de Jogl en sachant qu'aujourd'hui cette tache n'est envisageable que pour une equipe d'expert tres motivé (il suffit de regarder l'etat d'avancement des projets de moteurs 3D libres ...)

Vu que Java3D n'est pas une solution viable pour un jeux, les developpeurs se tournent naturellement vers d'autres moteurs libres plus complet (CS, Ogre, ...)

J'ignore si le parcours d'un graphe a réellement un tel impact sur les performances
Nan le parcours en lui meme est ce qu'il y a de plus efficace. Le probleme des graphe de scenes de ce type est la place memoire occupee d'une part et surtout la modification de l'arbre qui peut etre catastrophique en terme de performance. Si le developpeur sait ce qu'il fait (encore une fois ;) il saura eviter les manipulations de l'arbre tres couteuse a l'inverse du debutant fonctionnant par copier/coller.

Encore une fois ce type d'abstraction de haut niveau parait etre tres simple d'utilisation et tres accessible au debutant, mais sans une connaissance exacte de la mecanique interne on fait tres vite n'importe quoi.

https://jogl.dev.java.net/(...(...))
Coool je connaissais pas, par contre je trouve cette lib redondante avec java3d-core (j'ai pas trop regarder dans les details, mais a priori il s'agit dans les deux cas de bindings OpenGL)

même avec OpenGL ou Direct3D qui sont des API pensées presque exclusivement pour les performances brutes
OpenGL/Direct3D ne sont pas comparables a Java3D. OGL et D3D ne sont qu'une interface standard entre les routines de ta carte 3D et ton application. Ecrire un jeux directement sur OGL ou D3D est non seulement tres complexe mais aussi tres lent (car tu enverras a la carte 3D plus de polygonne que necessaire). Il te faut un intermediaire capable de t'afficher des objets plus complexes, des ombres, ... et surtout qui optimise le nombre de polygonnes envoyés. Java3D fait partie de cette categorie mais la structure de données utilisée privilegie la simplicité aux performances. Crystalspace et consort font eux aussi parties de cette categorie mais privilegie la rapidité en proposant une strucure de la scene plus performante et plus legere mais moins simple a utiliser.

Utiliser JOGL n'est dont pas suffisant pour faire un jeux, c'est faisable mais tres vite le developpeur se rendra compte qu'il passera plus de temps a tweaker son code pour avoir l'effet desire et surtout qu'il obtiendra un gros plat de nouille melangeant la visu et son modele de scene. Pas tres maintenable tout ca.

Java3D se prete tres mal a la creation de jeux car il s'agit en fait d'un arbre de scene, c'est a dire que les elements de la scene (camera, texture, transformation, trianlge, lumiere, ...) sont reliés les uns aux autres par l'intermediaire d'un graphe. Le rendu est effectué en parcourant ce graphe. Une modification de la scene necessite une modification du graphe. C'est tres facile a programmer, tres simple a manipuler, mais pas tres performant. Pour plus d'infos par exemple : http://rvirtual.free.fr/programmation/java3d/chap1/chap1.html(...)

Java3D est plus destiné aux applications de visualisation en 3D (modeleurs par exemple). Il trouve sa place dans les laboratoires et centre de recherche qui ont par exemple besoin de developper tres rapidement de petits outils de visualisation portables (car il y a souvent cohabitation entre des stations unix et des PC).

De plus, Java3D n'est pas le seul a se positionner sur ce marché : il existe une bibliotheque C++, plus complete, plus performante et surtout libre : www.coin3D.org qui propose en plus des bindings java ...

Je n'ai pas voulu relancer le troll, j'ai juste voulu expliquer en quoi le mythe sur la lenteur de Java est responsable du peu d'engoument enver Java3D.

alors si mm compilé Java est aussi lent
Je n'ai pas dit ca, c'est juste que les machines virtuelles actuelles sont capables d'effectuer les memes optimisations que les compilateurs. Ce qui explique qu'au final il n'y a pas tant de difference. Ceci n'est valide que pour la derniere version ainsi que sous Windows, car sous Linux la JVM reste encore lente.

le compiler en natif pour plus de performance.
Le mythe sur les performances de java ont la vie dur ;)
http://www.osnews.com/story.php?news_id=7372(...)
Je ne pense pas que le gain soit reelement important.

Mais heu... c'est utilisé ? ;-) Je veux dire, ils ne le font pas parce que Java 3D est peu utilisé, qu'il a peu de valeur stratégique et qu'ils comptent sur le modèle communautaire pour pousser à son utilisation ?
Le vrai probleme est que les developpeurs ont tendance a associer le mot lenteur a Java. Des applications 3D necessitent beaucoup de ressources par definition et il parait a priori naturel que Java ne soit pas le bon choix. Donc tout le monde se tourne vers le C/C++ et la communauté Java faisant de la 3D est par consequent tres reduite. C'est bien dommage. D'autant plus que Java3D est tres interessant car d'un niveau beaucoup plus haut qu'un simple bindings OpenGL.

La liberation des sources va certainement permettre de mettre au gout du jour ce moteur 3D avec l'ajout de fonctionnalité lui faisant cruellement défaut.

Je connais, mais je dois avouer que je n'utilise pas ;)

Je n'ai aucun chiffre, et le peu d'experience que j'ai ne me permette pas d'en tirer des conclusions, mais je pense que msdn n'est pas tant utilisé que ca, en tout cas pas dans les SSII et editeur de logiciel que j'ai fait. La raison est simple, le code doit tourner sur unix ou mieux : NT et Unix. Donc exit msdn et toutes les technos proprio Microsoft. On utilisait essentiellement des lib portables (Qt par exemplre) et certaines ouvertes (pour des raisons de couts) ou aucune lib a part la lib standard c++.

Compte tenu du travail que je faisais et vu qu'il etait similaire a de nombreuses SSII je pense que les technos microsoft n'y sont pas tres developpés (d'ailleur les mots revenant le plus souvant etaient Eclipse, Struts, Apache, J2EE, Soap, perl, .... que des technos ouvertes :)

D'ailleur tout developpeur C++ qui se respecte n'utilise pas les MFC ;)

Penses-tu que microsoft ne va pas fournir un support de XAML dans windows XP ?
Effectivement, je n'avais pas pensé a cette eventualité, surtout si ce support de XAML est inclut dans un SP ou une nouvelle version d'IE. Mais d'un autre coté, cette migration ne se fera pas tres vite du cote des entreprises et administrations. De plus ce temps depend a mon avis tres fortement du temps mis par les developpeurs a adopter cette technologie.

C'est fort probable a court et a moyen terme car le parc de navigateurs tournant sous ie 5 et 6 reste encore tres tres important, et ce sera le cas encore pendant longtemps. Par contre le risque est de voir une communaute grandir autour de cette technologie aveuglee par microsoft sans qu'elle est le choix d'utiliser une autre implementation que celle proposee par Microsoft.

Si des le debut Mono se positionne en tant qu'alternitve fiable et viable, on peut etre sur que le libre prendra une place de plus en plus importante dans les developpements et sensibilisera de plus en plus de developpeurs.

Le but est de ne pas creer une nouvelle communaute de developpeurs autour d'un produit Microsoft. Il ne faut pas que .Net et compagnie soit enseigne dans les ecoles sans qu'une alternative soit evoquee ou mieux utilisee. Il faut s'accaparer cette technologie. Et la force de mono est de proposer une implementation disponible sous Unix et je pense que c'est ce qui fera la difference (en particulier chez les editeurs developpant des applications visant ces deux plateformes)

Ouai, c'est vrai, mais bon en meme temps c'est que 1%, et encore sans compter ceux qui ont toujours un windows sous la main (au boulot, sur une autre partition,...). De plus c'est deja un peu le cas aujourd'hui et certaines boites ou meme institutions ne se genent pas pour faire ce genre de discriminations (virginmega par exemple, les impots, ...).

Par contre ce sera effectivement un perte de clients quand les alternatives libres (ou pas) auront depassees un taux dont le retour sur investissement sera profitable.

Et on revient donc a la meme question : Doit on rester dans notre coin, innover au risque d'etre incompatible et finallement devenir de plus en plus minoritaire (car nous n'avons pas encore la force pour imposer un standard) ou devons nous choisir plutot une strategie d'immitation, de compatibilite et de seduction en montrant d'autres avantages lies au libre (performance, liberte, faible cout, communaute, ...) et c'est ce que nous faisons en ce moment et ca a l'air de marcher, alors pourquoi changer.

Oui effectivement, ils en ont parlé sur la ML de GNUstep.

J'ai pas été super clair sur ce coup la ;)

Donc je m'explique, pour le debutant en programmation objet, Objective C est plus simple a apprendre car il contient beaucoup moins d'ambiguités et de cas particuliers que le C++. De plus il est plus orienté objet que le C++ et on retrouve syntaxiquement par exemple les principes d'interfaces, d'extensions... Ces principes ne sont implémentables en C++ qu'en jouant avec la syntaxe (Ex : Une interface est "assimilable" a une classe virtuelle pure, mais le principe d'interface en C++ n'existe pas).
En gros pour faire simple, C++ est une grosse mécanique générale permettant d'implémenter de tres nombreux paradigmes de programmation. C'est pourquoi il peut paraitre tres complet et tres complexe par rapport a tout autre langage objet pour un debutant.

Un developpeur comfirmé aura lui aucun probleme pour passer a l'ObjC car il retrouvera certains principes de POO ainsi que de nouveaux qu'il devra assimiler. Cette assimiliation est normallement tres rapide car plus naturelle et plus "cadrée" par la syntaxe. De plus l'utilisation de bibliotheques telles que GNUstep aide grandement cette migration en privilegiant la simplicité et l'efficacité.

C'est parce qu'ils n'ont pas le choix
Si, ils pouvaient ecrire leur propre compilateur. De plus ils ne repartaient pas de rien car ils disposaient deja du compilateur utilisé pour NextStep. Ils pouvaient aussi lié un partenariat avec StepStone qui propose un compilateur très complet. Au lieu de ca ils ont préféré les logiciels libres et joue le jeux en tirant partie des avantages et en s'y impliquant.

apple n'a dévelloppé objective-c++ que parce que ça permet aux dévelloppeurs c++ de ne pas avoir a apprendre l'objective-c.
Faux, le but est de pouvoir appeler des fonctions C++ dans du code ObjC, pas l'inverse. De plus l'apprentissage de l'objC est plus aisé et simple que celui du C++ et le passage du C++ a l'objC n'est qu'une affaire de syntaxe après avoir digérer les quelques principes supplémentaires.

L'Objective C est un langage objet reprenant la syntaxe du C en lui ajoutant les principes de la POO. Il est possible avec ce langage de melanger dans un meme source en ObjC du C ou du C++. Certains compilateurs commerciaux proposent ces deux possibilités mais pas Gcc jusqu'à aujourd'hui.

Cela implique une chose tres importante : la possibilité d'utiliser des lib C++ directement sans passer par des wrappers en C. De plus il montre une fois de plus qu'apple est actif et s'implique au sein de projets libres.

>> notez bien l'heure, je reviendrais quand je serais sous Gentoo
Et alors ? ;)

Personnelement j'ai mis plus d'une semaine a avoir un truc potable, mais bon maintenant je dois avouer que je regrette pas. Fo pas ce decourager c'est tout.

Oui sauf qu'ici beaucoup de personnes moinssent encore les commentaires avec lesquels ils ne sont pas d'accord, et souvent il s'agit de commentaires interessants mais n'etant pas forcement de l'avis general du site. Du coup on arrive a une certaine pensée unique ne laissant pas la place à d'autres pensées même minoritaires. Et je trouve ca dommage car cela ne permet pas de forger sa propre opinion par la diversité de celles-ci. On se contente d'approuver et d'accepter souvent l'opinion générale. Mais heureusement cette tendance tend a s'inverser ces derniers mois je trouve.

Oui mais le metro ne passe pas du tout par beaulieu (Université des sciences) donc ca sert un peu a rien le metro pour y aller ;)

Par contre coté bus c'est tres bien desservit : Quand j'y etais il y avait plusieurs lignes : des normales tres frequentes aux heures de pointes permettant de rejoindre le centre en 20min, des (tres) rapides rejoignant le centre ou la gare en 10min, et des lignes de nuit (toute la nuit le jeudi, vendredi et samedi soir).

Et sinon bonne chance pour ton DESS !

Cherche le long de la ligne 16 ou 10. Surtout la 16 car c'est une ligne de nuit qui rejoint beaulieu en passant par le centre. En plus il y a des lignes express vers la gare et le centre qui suivent a peu pres le meme tracé. L'interet est de pouvoir se passer totalement de voiture.

Sinon pour le logement, oublie beaulieu/Cesson (rond point), car c tres cher ou sinon c'est cite U. En plus c pas top le soir il n'y a rien a faire et il n'y a meme pas de boulangerie.

Villejean c'est super sympa et pas cher, un peu loin de beaulieu (1/2heure en bus) mais il y a le metro pour rejoindre le centre en 3 minutes.

Sinon le top c'est le centre, mais je te deconseille autour de la rue StMichel, les lices et autour de la mairie car c'est tres bruyant.

Derriere la gare, on m'a dit que c'est pas mal non plus et pas trop cher. Tu seras a 10mn a pied du centre.

Sinon il y a les nouveaux quartiers dans le sud, mais ca je ne connais pas trop.

Voili voilou.