+ Répondre à la discussion
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 21 à 37 sur 37
  1. #21
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    décembre 2006
    Messages
    1 638
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34

    Informations forums :
    Inscription : décembre 2006
    Messages : 1 638
    Points : 2 011
    Points
    2 011

    Par défaut

    salut,

    pour faire bref: j'ai le même genre de problématique (casual game multijoueur), j'ai passé du temps à hésiter entre applet java et flash et j'ai finalement choisi Java. Je n'ai pas une connaissance approfondie de Flash, mais essentiellement de java + applets + 2D.

    Je vais essayer d'être exhaustif, donc désolé d'avance pour le pavé de texte imbuvable ... mais il y a une récompense à la fin

    java est un langage de programmation alors que flash utilise des scripts très lents
    Je ne peux pas parler de Flash par expérience, donc je vais éviter de parler de ce que je connais peu. D'un autre côté, il y a pas mal de choses qui 'tournent bien' sur le web.

    flash n'a pas de vsync, le rendu n'est pas très élégant
    Java n'a pas de VSync non plus !
    Il y a bien des workarounds, mais ça implique du JNI (autant oublier pour de l'applet cause sandbox et portabilité).

    le java pose moins de problèmes de documentation: plus facile de porter du c+, beaucoup de docs en ligne, communauté très importante
    Tu soulèves un peu le point le plus important selon moi: ton profil et ton expérience.
    Tu sembles avoir un profil de 'développeur' plus que de graphiste (d'après le peu que je t'ai lu et ce que j'en ai interprété, j'ai peut-être tort).
    Il semble que Flash implique une approche du projet beaucoup plus orientée 'esprit graphiste' qui demande un temps d'adaptation quand on a plutôt une expérience de 'pisseur de code objet'.

    C'est mon cas également.
    Et ça a pesé lourd dans mon choix final de Java.

    le script de flash est moins complexe et donc le développement serait plus facile.
    cf orientations 'graphistes' vs 'développeurs'. J'ai peut-être une explication: les anims flash sont en règle générale des petits projets avec des petits budgets qui doivent être développées rapidement. Pas de quoi mettre un développeur + un graphiste sur le coup (trop cher). Flash est plus indiqué pour un projet avec une seule personne: le graphiste poru le coup.

    là je ne suis pas d'accord car la lenteur du flash fait qu'il faut trouver des optimisations exotiques qui peuvent devenir un véritable casse-tête, alors qu'avec java il suffit d'appliquer les principes de programmation classiques.
    Vrai dans la théorie.
    Dans la pratique, tu n'échaperas pas aux bidouillages à un moment ou à un autre, même avec Java.


    la portabilité du plugin flash est parfaite
    Sans aucun doute meilleure que java.


    Différents points ennuyeux avec Java qui méritent attention:

    - Java 1.1 n'est pas utiliable car trop restreint en termes de possibilités. Il ne faut donc pas compter dessus pour développer quelque chose de 'viable'. La version minimum à prendre en compte pour la portabilité est la 1.4. Ca a une scrée conséquence: beaucoup moins de monde a le plugin déjà installé, d'où un part moins négligeable des visiteurs devra installer le plugin Java. Et là, c'est le (gros) souci:

    * va-t-il accepter la popup plus ou moins obscure lui demandant d'installer un truc supplémentaire? Ca peut faire peur à certains visiteurs.

    * peut-il installer le plugin ? droits admins sur sa bécane, donc au revoir les ordis 'publics', d'une université par exemple

    * si oui, il va devoir charger une JVM. Et la JRE 1.6 c'est 12.5Mo, à comparer aux ... 1.5Mo de Flash player 10.

    De plus, une applet de 'jeu', c'est bien, mais en règle générale on aura envie à terme de l'intégrer dans un site plus complet. Cela implique deux choses:

    * pouvoir avoir plusieurs applets sur la même page éventuellement qui communiquent entre elles. Sur Java, avoir plusieurs applets qui cohabitent pose des soucis (partage de la même JVM ; interaction avec les membres statiques, ...). LA communication entre deux applets n'est pas triviale non plus.

    * pouvoir communiquer entre le javascript de la page et l'applet. Java peut également poser des soucis pour certains triplets (OS + version de JRE + navigateur). Dans certains cas (marginaux, genre Opera + MacOs si je me souviens bien), c'est impossible. Le bon point: le browser par défaut de chaque OS (Linux, MacOS, Windows) y arrive quand même. Donc au pire, on peut inciter l'utilisateur à utiliser le bon browser.

    Le plus important: Java et son SDK de base n'est vraiment pas fait pour faire du graphisme 'eye candy' en 2D. Si tu regardes du côté de l'API 2D, tu te rendras vite compte que tu devras fournir un boulot énorme pour implémenter des fonctionnalités basiques (animations non sacadées, sprites, zooms, effets 2D, ...) et un boulot encore plus énorme pour garder des performances décentes.

    Heureusement, une solution JAVA existe ... (la récompense pour m'avoir lu jusqu'au bout ).... un framework LGPL Java spécialement conçu pour faire des applets 'eye candy' et qui vont:

    * t'éviter l'immense majorité des soucis de base de compatibilité (JRE 1.4+)

    * te fournir toutes les fonctionnalités techniques pour ce genre de besoin (gestion des ressources associées à l'applet, barre de progession lors du chargement de l'applet, sprites, animations, effets 2D, ...)

    Son nom: pulpcore.

    - Le jeu milpa te donnera un aperçu général des possibilités.

    - Les quelques exemples 'techniques' parleront d'eux même quand aux possibilités du framework.

    Je participe (un peu) à ce projet (hébergé ici sur Google code), donc n'hésite pas à demander plus d'infos.

    Une dernière chose: il ne faut surtout pas croire que la portabilité n'est plus un souci avec Java. Les différences de versions, de navigateur, ... causent des soucis, bien plus que ce qu'on s'imagine au départ. Et ça alourdit d'autant la charge de travail. Donc mieux vaut commencer 'petit' et étoffer ensuite étape par étape.
    Les quelques points abordés ci-dessus n'en sont qu'un aperçu et quelques pistes de réflexion. Il y a une foultitide de petits trucs à la c** comme ça qu'on ne prévoit pas au départ.

    C'est mon cas: j'avais largement sous-estimé le nombre de petits imprévus auxquels j'ai finalement dû faire face (et pourtant, estimer des projets informatiques, ça fait partie de mon métier ).
    Bon, il est vrai aussi que mes besoins sortent quelque peu des sentiers battus par rapport à une anim' flash 'de base' (comme le réseau, la comm' inter-applets, la comm' Java<->Javascript/AJAX, ...).

    Donc en résumé: oui Java peu être une bonne solution, mais pas 'out of the box'. S'appuyer sur un framework rien que pour la partie 2D est indispensable. (je ne parle pas de la 3D, mais pour faire court dans une applet portable il ne faut même pas y penser. En Webstart à la rigueur, et encore c'est pas gagné).

    Perso, j'ai fais le choix de Java et je ne le regrette pas. Mais comme toujours la techno dépend surtout de tes besoins.

    Tu peux peut-être nous détailler ce que tu comptes faire, et on pourra certainement rentrer dans les détails ... à moins que ce ne soit 'secret défense'

  2. #22
    Membre habitué
    Inscrit en
    décembre 2007
    Messages
    180
    Détails du profil
    Informations forums :
    Inscription : décembre 2007
    Messages : 180
    Points : 119
    Points
    119

    Par défaut

    Ca fait plaisir une réponse aussi construite et argumentée ! Merci à toi beaucoup.

    Je cherche à faire des choses vraiment très basiques: des tuiles et des sprites. Pas d'effets de zoom ou autres gadgets de flash. Le rendu vecteur je m'en sers pas j'anime dans image ready, je préfère le bitmap car c'est rendu plus rapidement. Donc les librairies de ce type je n'en aurais pas spécialement besoin.
    Je fais aussi du graphisme (dessin animé essentiellement) mais je n'utilise pas flash pour ça, je code l'actionscript dans flex builder (un clone d'eclipse pour coder du flash).

    Ce qui me pousse plus à essayer java c'est que le langage est rapide alors que le script flash est lent,

    Par exemple si j'essaye de faire scroller des tuiles animées (la base ...), avec flash la manipulation des pixels et la lecture de tableaux est tellement lente que la seule façon d'avoir un truc rapide c'est de défoncer la ram et préparer à l'avance toutes les frames d'un background géant. si je fais un scroll avec des copies (même optimisé avec double buffer) la perte de millisecondes est significative.
    Avec java j'ai juste à tracer directement les tuiles à l'écran à chaque frame, ça prend 5 lignes de code et approximativement zéro millisecondes.

    En perf du code java enfonce flash les doigts dans le nez mais y'a la portabilité qui pose probleme:

    http://www.adobe.com/products/player...s/flashplayer/

    Et les clients sont souvent pénibles avec ça, d'autant que leurs sites contiennent du flash donc ils savent que leurs internautes ont flash, c'est pas dit qu'ils aient java, bref pas facile de choisir.

    Ton message me donne envie de pencher plutôt du côté de flash, il me semble avoir sous-estimé les problèmes de compatibilité posés par java... du point de vue du client c'est prioritaire sur la vitesse d'exécution du code et souvent du moment que les dessins sont jolis ça les dérange pas si ça rame (c'est surtout le codeur que ça irrite).

  3. #23
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    décembre 2006
    Messages
    1 638
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34

    Informations forums :
    Inscription : décembre 2006
    Messages : 1 638
    Points : 2 011
    Points
    2 011

    Par défaut

    Citation Envoyé par Camel LowFilter Voir le message
    Ca fait plaisir une réponse aussi construite et argumentée ! Merci à toi beaucoup.
    De rien. Je précise que je n'étais pas là pour 'descendre' java, mais pour essayer de te montrer avec quelques exemples précis que tout n'est pas parfait non plus avec Java.


    Je cherche à faire des choses vraiment très basiques: des tuiles et des sprites. Pas d'effets de zoom ou autres gadgets de flash. Le rendu vecteur je m'en sers pas j'anime dans image ready, je préfère le bitmap car c'est rendu plus rapidement. Donc les librairies de ce type je n'en aurais pas spécialement besoin.
    Merci de préciser tes besoins. Effectivement, tes besoins sont bien plus restreints que ce que j'imaginais. Et ça peut changer pas mal de choses.

    Par exemple si j'essaye de faire scroller des tuiles animées (la base ...), avec flash la manipulation des pixels et la lecture de tableaux est tellement lente que la seule façon d'avoir un truc rapide c'est de défoncer la ram et préparer à l'avance toutes les frames d'un background géant. si je fais un scroll avec des copies (même optimisé avec double buffer) la perte de millisecondes est significative.
    As-tu jeté un oeil à l'exemple tileMap qui correspond - je crois - exactement à tes besoins ?

    Avec java j'ai juste à tracer directement les tuiles à l'écran à chaque frame, ça prend 5 lignes de code et approximativement zéro millisecondes.
    La librairie pulpcore ne fait justement que du bitmap, des sprites au niveau graphisme.

    De plus, question compatibilité, si tes besoins sont si restreints, là tu pourras peut-être finalement te cantonner à ce que propose Java 1.1 'out of the box' et sa classe 'Graphics' (donc même sans Java2D qui est apparu avec Java 1.2 et la classe 'Graphics2D').

    Si vraiment tu n'as que très peu de besoins et que la fonction drawImage te suffit, tu pourrais presque en effet envisager de te passer de framework de base.

    Bon, après il ne faut pas oublier non plus qu'un framework comme pulpcore ne fait pas QUE ça, mais propose d'autres fonctionnalités annexes plus ou moins utiles:
    - gestion des animations, déplacements de sprites
    - gestion des ressources (images ,sons, ...)
    - gestion du 'splash' loader (barre de progression pdant le chargement de l'applet).
    - éléments d'UI (boutons, textFields, ...)
    - etc...

    A toi de voir en fonction de tes besoins.

    En perf du code java enfonce flash les doigts dans le nez mais y'a la portabilité qui pose probleme: http://www.adobe.com/products/player...s/flashplayer/
    Moui, perso je ferais moyennement confiance à un site adobe pour comparer les taux de pénétration de Flash et Java

  4. #24
    Membre habitué
    Inscrit en
    décembre 2007
    Messages
    180
    Détails du profil
    Informations forums :
    Inscription : décembre 2007
    Messages : 180
    Points : 119
    Points
    119

    Par défaut

    oui adobe a du "arrondir" les chiffre à son avantage mais je ne trouve pas de stats sur le site de sun

    par contre j'ai les mêmes là:

    http://www.stargeek.com/item/104536.html



    J'ai regardé la démo tilemap de pulpcore, j'ai l'impression que le plug flash en vitesse de retracage est plus rapide que java 2d, niveau cpu ta démo consomme pas mal (100% sur un process 1.5 ghz), avec flash c'est ce que ça demande au cpu pour une vitesse de 120 fps (or sur la démo java ça ressemble plus à du 60)

    Si le moteur graphique de flash est plus rapide ça devrait compenser la lenteur du script.


    L'autre interêt que j'avais à essayer java c'est la possibilité de vsync avec les librairies opengl mais leur portabilité m'a pas l'air d'être au point.

  5. #25
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    décembre 2006
    Messages
    1 638
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34

    Informations forums :
    Inscription : décembre 2006
    Messages : 1 638
    Points : 2 011
    Points
    2 011

    Par défaut

    Citation Envoyé par Camel LowFilter Voir le message
    J'ai regardé la démo tilemap de pulpcore, j'ai l'impression que le plug flash en vitesse de retracage est plus rapide que java 2d, niveau cpu ta démo consomme pas mal (100% sur un process 1.5 ghz), avec flash c'est ce que ça demande au cpu pour une vitesse de 120 fps (or sur la démo java ça ressemble plus à du 60)
    Effectivement, dans pulpcore le FPS est volontairement bloqué à 60fps. C'est justement pour limiter au maximum les soucis de vsync (car quasiment tous les écrans LCDs d'ordi - qui sont majoritaires maintenant - tournent à 60Hz).

    Ceci dit, pulpcore pour cet exemple précis est effectivement un peu juste (quoique je ne consomme que 25% de CPU sur mon Core2Duo 1.8GHz).

    Mais techniquement parlant le résultat est excellent quand on sait que pour assurer une compatibilité ascendante maximum avec les vieilles version de java, le rendu est uniquement logiciel (ie. Chaque point affiché est calaculé par du code Java).

    Bon, ensuite il faut comparer avec tes besoins. L'exemple tileMap est un scrolling sur la totalité de l'affichage de l'applet en 640x480. Est-ce que ce sera le cas de ton applet ?

    L'autre interêt que j'avais à essayer java c'est la possibilité de vsync avec les librairies opengl mais leur portabilité m'a pas l'air d'être au point.
    Je te déconseille très vivement l'openGL dans une applet: même avec des centaines d'heures perdues à résoudre des soucis de compatibilité, tu finiras de toute façon avec des problèmes insolubles: qui dit openGL dit appels systèmes spécifiques à la plateforme (JNI). Et bien qu'il existe des bidouilles pour faire du JNI dans des applets (qui ne l'autorisent pas par défaut), ça marche rarement à 100%, et de toute façon *pas* avec Java 1.1

    Un exemple concret: cet exemple chez moi avec WinXP, le dernier JRE (donc pas vraiment une config' excentrique), m'affiche des bugs quand je scrolle verticalement (exemple). Et je le reproduis à la fois sous IE7 et Firefox 2. Pourtant c'est une démo officielle.

  6. #26
    Membre habitué
    Inscrit en
    décembre 2007
    Messages
    180
    Détails du profil
    Informations forums :
    Inscription : décembre 2007
    Messages : 180
    Points : 119
    Points
    119

    Par défaut

    Les applets plantent quand on scrolle la page web, normalement il faut se débrouiller pour que ça ne scrolle pas.

    La différence de rendu avec et sans vsync est vraiment flagrante... et le rendu openGl est vraiment rapide (la démo des roues dentées prend 0% de mon cpu).

    C'est très alléchant vu de loin.

    Après si la portabilité de jogl laisse à désirer... il faudrait attendre encore un peu

    Mais je suis tenté, le rendu jogl est vraiment puissant


    A vue de nez sur combien d'os ou machines jogl est susceptible de planter? Est-ce que ça marche sur vista, mac intel...?

  7. #27
    Membre habitué
    Inscrit en
    juillet 2008
    Messages
    104
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 104
    Points : 101
    Points
    101

    Par défaut

    NB: juste une precision en passant pour les stats (à qui ont fait dire ce que l'ont veut) de penetration flash. aucune version n'est precisé, non ? parceque la aussi si tu utilise des specificitées flash 9 et que le client a flash 7 tu retombe sur le meme problème que si tu utilise java 1.4 et qu'il a java 1.1.

    NB2: je ne suis pas tout à fait d'accord sur le fait que java 1.1 n'est pas une solution viable, il est plus restreint, c'est certain et logique aussi..., mais il permet de tout faire en 2D (precision : en non signé je veux dire et donc sans lib externe ce qui est le plus plaisant pour le visiteur). les deux gros blocage etant le son et la memoire disponible. mais tu peux sans souci faire un jeu de plateau ou un shoot them up ou un jeu de tir (tres à la mode en flash) en Java 1.1 sans bouffer tout le CPU du client. bcp de jeu en flash aurait/peuvent etre refait en Java 1.1. apres pour un projet plus gros c'est sur que la memoire et le son risque de poser problème. encore une fois tout depend du projet.

  8. #28
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    décembre 2006
    Messages
    1 638
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34

    Informations forums :
    Inscription : décembre 2006
    Messages : 1 638
    Points : 2 011
    Points
    2 011

    Par défaut

    Citation Envoyé par DzzDDzzD Voir le message
    NB2: je ne suis pas tout à fait d'accord sur le fait que java 1.1 n'est pas une solution viable, il est plus restreint, c'est certain et logique aussi..., mais il permet de tout faire en 2D
    Effectivement, je ne voulais pas dire que Java 1.1 n'était pas capable de faire ça.

    Mais soyons clairs: garantir une rétrocompatibilité vers java 1.1 a quand même un sacré coût supplémentaire !!!

    Java 1.1 date de 1997 et pas mal de choses se sont passées entre temps. Quelques exemples: la possibilité de lire des JPG et des PNG en natif n'a été ajoutée qu'à Java 1.4, le son à Java 1.3, le framework 'Collections' à Java 1.2, etc...

    donc effectivement, ce n'est pas impossible. Par exemple, réimplémenter un PNGReader est tout à fait envisageable, etc.
    Le framework 3DzzD - dont ton pseudo se rapproche étrangement - est un exemple (une performance ?) technique très probant, et un challenge certainement instructif et passionnant pour un 'core développeur'.

    Mais, du point de vue d'un développeur de jeu, combien de temps de développement supplémentaire (perdu ?) cela va-t-il demander pour développer le même jeu au final ? C'était le sens de mon qualificatif 'viable'...

  9. #29
    Membre habitué
    Inscrit en
    juillet 2008
    Messages
    104
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 104
    Points : 101
    Points
    101

    Par défaut

    Java 1.1 date de 1997 et pas mal de choses se sont passées entre temps. Quelques exemples: la possibilité de lire des JPG et des PNG en natif n'a été ajoutée qu'à Java 1.4, le son à Java 1.3, le framework 'Collections' à Java 1.2, etc...
    oui c'est clair que pas mal de truc sympa ont été ajouté, mais en fait le language Java en lui meme n'a pas vraiment/bcp changé mais des librairies ont été ajoutées, d'ailleurs j'en veu un peu à "Java" sur ce point , pour certaines améliorations ou c'etait possible (pas vraiment possible pour toutes) ils auraient mieux fait de les fournir en librairies externes, par exemple effectivement un chargeur de png, ou les collections plutot que de les implémenter au coeur de Java, c'est vraiment dommage en fait comme choix . Pas sûr mais je crois qu'ils ont un peu changé leurs fusil d'epaule maintenant, ca devrait eviter que le JRE monte à 50 MO. Je trouve que la sortie succesive de differente JVM fonctionnellements différentes (alors que le bytecode java lui n'a pas vraiment changé) va à l'encontre de l'idée même d'origine du Java.

    Mais soyons clairs: garantir une rétrocompatibilité vers java 1.1 a quand même un sacré coût supplémentaire !!!
    oui c'est plus que vrai, mais peutetre dans certain appli cela peut etre interressant, il y'a par exemple une JVM 1.1 pour les plateformes window mobile (mysaifu) ca peu devenir interressant du coup car tu couvre les os standard java : win/mac/lin/solaris plus les window mobile + d'autres peutetre ?

    par exemple pour un simple projet de tetris, sudoku ou de petits puzzle je conseillerais Java 1.1 pour un FPS je dirais plutot 1.4+

    Mais, du point de vue d'un développeur de jeu, combien de temps de développement supplémentaire (perdu ?) cela va-t-il demander pour développer le même jeu au final ?
    plus c'est sur, mais c'est tjrs interressant de refaire la roue comme ca on comprend pourquoi elle est ronde

  10. #30
    Membre habitué
    Inscrit en
    juillet 2008
    Messages
    104
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 104
    Points : 101
    Points
    101

    Par défaut

    donc effectivement, ce n'est pas impossible. Par exemple, réimplémenter un PNGReader est tout à fait envisageable, etc.
    Le framework 3DzzD - dont ton pseudo se rapproche étrangement - est un exemple (une performance ?) technique très probant, et un challenge certainement instructif et passionnant pour un 'core développeur'.
    merci, non pas vraiment une performance un pass temps

    mais, par contre, ca c'est une performance

    9h:
    http://demo.dzzd.net/FPSSample/

    un peu plus de 9h:
    http://demo.dzzd.net/FPSSample3/

    et avec un model 3d du level plus sympa
    http://demo.dzzd.net/FPSSample4/

  11. #31
    Membre habitué
    Inscrit en
    décembre 2007
    Messages
    180
    Détails du profil
    Informations forums :
    Inscription : décembre 2007
    Messages : 180
    Points : 119
    Points
    119

    Par défaut

    Après quelques tests, updates d'ie et recherches sur google je suis au regret de constater un argument de taille en défaveur de flash: microsoft est entré en guerre contre flash pour "promouvoir" silverlight (une technologie concurrente loin d'être au point) et ils ont fait du sabotage pur et simple du player flash dans iexplorer. Alors que flash plugin dans ie marchait encore très bien l'an dernier, désormais ça saccade complètement, les plaintes concertant le conflit entre flash et ie ont proliféré, youtube plante sur iexplorer...

    C'est plus possible de faire un jeu décent en flash sur iexplorer, désormais java tient beaucoup mieux la route

  12. #32
    Membre Expert

    Inscrit en
    janvier 2005
    Messages
    732
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 732
    Points : 1 090
    Points
    1 090

    Par défaut

    Citation Envoyé par Camel LowFilter Voir le message
    Après quelques tests, updates d'ie et recherches sur google je suis au regret de constater un argument de taille en défaveur de flash: microsoft est entré en guerre contre flash pour "promouvoir" silverlight (une technologie concurrente loin d'être au point) et ils ont fait du sabotage pur et simple du player flash dans iexplorer. Alors que flash plugin dans ie marchait encore très bien l'an dernier, désormais ça saccade complètement, les plaintes concertant le conflit entre flash et ie ont proliféré, youtube plante sur iexplorer...

    C'est plus possible de faire un jeu décent en flash sur iexplorer, désormais java tient beaucoup mieux la route
    Bien que la guerre silverlight et les technos flash ne me soit pas inconnue. Les problèmes que tu cites le sont plus. Sur mon windows XP (SP2) et le vista de mes parents, je n'ai pas rencontré de problème particulier.

  13. #33
    Membre habitué
    Inscrit en
    décembre 2007
    Messages
    180
    Détails du profil
    Informations forums :
    Inscription : décembre 2007
    Messages : 180
    Points : 119
    Points
    119

    Par défaut

    Ben chez moi, sur mozilla le flash a une cadence bien propre, sur iexplorer ça saccade et ça bride la vitesse très bas, ce qui n'était pas le cas sur les anciennes versions d'ie... avant le début de la "guerre" silverlight, iexplorer était le navigateur où le flash marchait le mieux, maintenant que je vois comment les jeux flash tournent sur ie ça fait pas envie

  14. #34
    Membre éclairé

    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2006
    Messages
    260
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : janvier 2006
    Messages : 260
    Points : 327
    Points
    327

    Par défaut

    J'ai toujours été frilleux face aux applets Java. J'ai toujours préféré Flash, qui est une technologie vraiment associé au multimédia (à l'inverse de Java, qui lui est un langage plutôt associé architecture bien lourde).

    Il reste une alternative entre Java et Flash, qui est Flex. ça se code comme du Java (enfin presque), et ça se lit avec le Flash Player.

    De plus, il existe tout un tas de lib graphiques 2D et 3D très performantes utilisables avec de l'ActionScript.

    Lib 2D : http://www.degrafa.org/
    lib 3D : http://away3d.com/

    Zecreator
    "Papa, c'est quoi l'Europe ? Ceux sont des gens qui voudraient être américains, mais qui n'en n'ont pas les moyens.

  15. #35
    Invité régulier
    Inscrit en
    août 2008
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : août 2008
    Messages : 13
    Points : 5
    Points
    5

    Par défaut

    Bonjour,
    encore un avantage pour java: on peut jouer avec un joypad.
    La preuve avec karate spirit.

  16. #36
    Membre habitué
    Inscrit en
    décembre 2007
    Messages
    180
    Détails du profil
    Informations forums :
    Inscription : décembre 2007
    Messages : 180
    Points : 119
    Points
    119

    Par défaut

    Tiens mon vieux topic a été déterré ^^

    Bon de l'eau a coulé sous les ponts depuis et maintenant il est clair que flash a explosé l'applet java...

    La vitesse saccadée n'est plus qu'un mauvais souvenir vu que depuis flash cs4 y'a la vsync dans le player.

    Par contre flash reste un affreux gouffre à cpu, perfs de l'ordre de celles d'un émulateur, ce qui nous oblige à régresser aux techniques d'optimisation des années 80 (ce qui simplifie pas tellement la vie aux devs, contrairement à ce que prétendent les pubs adobe...) Depuis qu'android peut lire les jeux flash browser ça pardonne plus on est obligés d'optimiser comme des malades, on passe limite plus de temps à faire des benchmarks qu'à produire des jeux

    Ca devrait s'améliorer avec la release de molehill, enfin espérons-le, on verra.

  17. #37
    Membre expérimenté
    Avatar de Marwindows
    Inscrit en
    mars 2010
    Messages
    37
    Détails du profil
    Informations forums :
    Inscription : mars 2010
    Messages : 37
    Points : 525
    Points
    525

    Par défaut

    Flash ca te tue un Mac, au sens propre du terme, ouvre une appli flash et laisse ton mac tourner une heure sans y toucher, tu reviens et là je t'assure que tu peux cuisiner dessus.
    Après ca dépends si tu veux t'adresser à toutes les machines, je te propose le HTML5 ou le JS, car le JAVA reste malgré tout lent à charger.
    Pour ma part même si tu as finis ton projet depuis 2 ans, je te propose de jeter un oeil sur ma modeste lib qui est portable, qui ne demande pas trop de ressource, sauf au premier chargement (mais depuis on bosse à l'optimisation)
    http://santalib.fr ->santalib-objs
    (il y a d'ailleurs un concours en ce moment, dès fois que )
    Bien que d'autre lib soit plus performante, l'avantage de celle-ci c'est que tout est made home, tu as donc un meilleur controle de la lib, pas de jquery ni de HTML5.
    Voili Voilà,

    Sur ce je te souhaite une bonne journée.

    Cordialement,

    M.

Liens sociaux

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
  •