Discussion :

[nouknouk]

Bonjour,

pour des besoins personnels, je suis en train de m'attquer au codage d'une petite librairie 2D.

L'idée de base serait d'offrir la possibilité de manipuler des 'sprites' (ie. des instance d'Image), de les animer et de les afficher en temp-réel. En gros, ce serait pour s'offrir les possibilités les plus basiques de Flash pour implémenter des applets 'eye candy'.

Pour le moment : l'ensemble de ma 'scène' en 2D est constituée par un arbre dont les noeuds (Node2D) ont chacun une transformation (AffineTransform) propre utilisée pour le noeud lui même et comme transformation de base pour ses enfants. La transformation définit donc une position, une rotation et une taille. Chaque noeud affiche une Image avec cette transformation quand il faut rafraîchir le layout.

Ce que j'aimerais également pouvoir faire est de gérer des 'effets' sur le rendu de chaque noeud, comme la gestion d'une transparence dynamique ou le passage progressif d'une image colorée en tons de gris. Je me suis donc tourné vers les Composites.

Problème: Bien que le (seul) composite implémenté dans la librairie standard (ie. AlphaComposite) m'autorise des performances générales correctes, dès que je cherche à utiliser d'autres composites (comme par exemple les effets fournis par l'excellent BlendComposite de Romain Guy), là ça devient totalement inutilisable (genre 2 fps).

Les effets que je cherche à implémenter ne me semblent pas si lourds en calcul et devraient pouvoir être exécutés en temps réel sans souci (Flash le fait, pourquoi pas Java), genre les compositions dynamiques comme celles implémentées par Romain Guy (couleur, saturation, luminosité, ...).

Voilà. Comment pourrais-je m'y prendre pour récupérer des performances décentes en utilisant de tels compositions ?

Merci d'avance

[CLeJ37]

Bonjour,

Romain Guy le dit lui même :

Next, these implementations are not very fast, do not try real-time drawing with them.

et par-contre:

Those composites work much better with Java SE 6; I have noticed speed improvements of x3 to x4 when compared to J2SE 5.0. A while ago, the JVM team announced they improved HotSpot's management for arrays and from what I have seen with this example, they did a great job!

Reste à voir si tu peux l'améliorer.

[Pollux]

Je suis pas certain mais il me semble que le projet Scene Graph est ce qu'il te faut (à moins que tu veuilles vraiment développer ton truc...). Ce projet est passé en open source il y a quelques jours et permet de faire ce que tu décris (à vérifier j'ai pas vraiment regardé ce que c'était).

Si ca peut t'aider...

[sinok]

Je suis pas certain mais il me semble que le projet Scene Graph est ce qu'il te faut (à moins que tu veuilles vraiment développer ton truc...). Ce projet est passé en open source il y a quelques jours et permet de faire ce que tu décris (à vérifier j'ai pas vraiment regardé ce que c'était).

Si ca peut t'aider...

C'est ce qui a déja été répondu dans l'autre sujet du monsieur .

[nouknouk]

C'est ce qui a déja été répondu dans l'autre sujet du monsieur .

note: on parle de ce thread.

Effectivement, le sceneGraph correspond pas mal à ce dont j'aurais besoin au niveau des fonctionnalités. Néanmoins, j'ai finalement décidé de ne pas l'adopter car sa license 'full open source' (comprendre genre GPL et pas genre LGPL) ne peut pas convenir à mon projet.

Pour faire profiter les autres de ce que mes recherches m'ont appris:

- l'API de Java2D utilise en standard quelques fonctionnalités d'openGL pour accélérer une petite partie des opérations de rendu 2D. Néanmoins, cela se limite principalement aux transformations simples (translation) et le stockage et le dessin d'images depuis la mémoire de la carte graphique.

- l'implémentation de nouveaux effets se fait plutôt par les RasterOp que par les Composite. cf. ce tuto.

- les seuls 'effets' qui vont profiter d'une implémentation plus bas niveau que le Java lui-même (et donc rapides) sont la composition Alpha (AlphaComposite). Tout autre effet devra être implémenté en Java, et risque d'être plus lent (ça reste évidemment relatif au poids de chaque image). Les JNI sont une option, mais posent des contraintes supplémentaires (applets à oublier, ...).

- une solution pour implémenter des effets performants serait de programmer des fragment shaders (ou pixel shaders). C'est tout à fait possible en travaillant avec un rendu entièrement géré par openGL. Malheureusement, les shaders ne sont pas supportés par les cartes graphiques anciennes, donc s'il est besoin d'avoir une compatibilité maximale, c'est pas la solution idéale (cf. ce thread)

- Une dernière chose : pousser un peu plus loin l'idée d'utiliser openGL par JOGL pour accélerer le rendu semble possible. L'idée serait d'accélérer cette fois-ci toutes les transformations et implémenter quelques effets en utilisant les fonctionnalités les plus standard d'openGL (genre composition de textures, ...). Je creuserai le sujet quand j'aurai des problèmes insolubles de performance (ou des effets de dingo à implémenter).

That's all folks

[nouknouk]

Pour ceux qui seraient intéressés, un certain Brackeen a publié sous license BSD un framework appelé PulpCore.

Il s'en sert comme framework de base pour le développement de petits jeux "à la Flash" sous forme d'Applets, visible sur le site pulpGames (testez le jeu milpa pour voir quelques possibilités du framework).

La page de présentation du framework sur le site de la société propose quelques exemples d'Applets plutôt convaincants.

Enfin, j'adore la phrase de description du framework, tellement vraie à mon goût : "Java applets that don’t suck."