Infographie...

[poneyman]

Salutati, salutatous !

Je cherche depuis quelques temps comment afficher des pixels à l'écran, et je trouve tout sauf ça ! Quelle serait la meilleur façon de procéder, quel langage, etc... (autre qu'en libX sous X11, je veux faire ca sous aqua...)

 

[ntx]

Bonsoir,
afficher des pixels : vaste sujet ! Le langage de prédilection pour développer des applications sur Mac OSX est l'objective-c en utilisant le framework Cocoa. Dedans tu trouveras les classes d'objets nécessaires pour dessiner dans une vue. Pour modéliser le "crayon", la classe à utiliser est NSBezierPath : elle permet de dessiner des points, des traits, des arcs de cercles ... Mais avant d'arriver à dessiner quelque chose à lécran, un petit apprentissage sera nécessaire

 

[claque2000]

Quitte à dire une connerie, je vais la dire : pourquoi ne pas utiliser OpenGL ?

 

[ntx]

Si c'est pour faire de la 2D, les fonctions Cocoa sont plus simples à maîtriser ... enfin je pense. OpenGL n'est pas vraiment destiné à des débutants.

 

[poneyman]

Merci pour les reponses, mais ce que je cherche c'est une fonction du genre pixel_put(x, y, color)... Je commence a maitriser le C, et j'ai de bonnes notions de POO, donc objective-c / cocoa, pourquoi pas (jviens de me taper l'introduction sur projectomega.org...), mais je patauge... suis-je obligé de passer par NSBezierPath pour afficher un seul tout petit pixel ? Y'a pas plus simple ? J'avais aussi pensé a opengl, mais c'est un peu tordu non ?

 

[Didier Guillion]

Merci pour les reponses, mais ce que je cherche c'est une fonction du genre pixel_put(x, y, color)... Je commence a maitriser le C, et j'ai de bonnes notions de POO, donc objective-c / cocoa, pourquoi pas (jviens de me taper l'introduction sur projectomega.org...), mais je patauge... suis-je obligé de passer par NSBezierPath pour afficher un seul tout petit pixel ? Y'a pas plus simple ? J'avais aussi pensé a opengl, mais c'est un peu tordu non ?

Personnellement, je passe par des GWorld :
http://developer.apple.com/document...aw_Ref/qdref_main/chapter_2.1_section_14.html

Tu obtient l'access a une zone memoire formatée comme tu le veut (taille, nbre de couleurs) qui tu tranfere ensuite a l'ecran.

Cordialement

 

[ntx]

Certes, c'est une maniere de faire mais le probleme des GWorld, c'est que c'est du Carbon qui n'est pas appele a un grand avenir. (voir Steve et ces x86 )
Sinon pour la doc de base pour dessiner en Cocoa, c'est ici. Mais desole, il n'y a pas de pixel_put.
D'un autre cote, je ne vois pas trop la difference entre un pixel_put et dessiner une ligne de 1 pixel

 

[Didier Guillion]

Certes, c'est une maniere de faire mais le probleme des GWorld, c'est que c'est du Carbon qui n'est pas appele a un grand avenir. (voir Steve et ces x86 )

j'ai un peu suvit l'histoire, a aucun moment la fin de Carbon n'a été annoncée.. Mais peut etre as tu de plus recentes references ?

L'avantage des GWorld, c'est que cela fonctionne également sur les versions antérieures de Mac OS (8.6 à 9 .2), que c'est très simple a comprendre et que cela correspond presque mot à mot aux DIB de Windows ce qui permet a terme, de faciliter le portage.

Cordialement

 

[poneyman]

C'est bien marqué que toutes les fonctions GWorld sont "deprecated" sous tiger... Mais bon c'est à peu près ce que je cherchais... Mais vu que j'ai jamais rien codé sous OsX et tout le tralala d'interface builder etc, je risque de patauger un bon moment avec d'avoir un truc à l'écran... T'aurais pas un exemple d'app en GWorld Didier ?

 

[Ptit-beignet]

j'ai un peu suvit l'histoire, a aucun moment la fin de Carbon n'a été annoncée.. Mais peut etre as tu de plus recentes references ?

L'avantage des GWorld, c'est que cela fonctionne également sur les versions antérieures de Mac OS (8.6 à 9 .2), que c'est très simple a comprendre et que cela correspond presque mot à mot aux DIB de Windows ce qui permet a terme, de faciliter le portage.

Cordialement

Ce que ntx veut dire c'est qu' Apple a annoncé que le portage des applis cocoa serait très facile pour les x86 car même framework. Par contre, pour les carbons bah deja depuis un bout de temps Apple pousse à l'adoption de Cocoa. Carbon va rendre le portage vers x86 plus difficile donc je pense qu'Apple va vraiment tout faire pour le faire disparaitre car c'est une mauvaise pub de faire une appli que pour seul monde (PPC ou x86 pas le deux)
Je pense que commencer une appli en Carbon de nos jours est un enfermement inutile. D'accord c'est compatible avec les anciens OS mais bon mieux vaut regarder vers l'avenir nan ?

 

[Didier Guillion]

Ce que ntx veut dire c'est qu' Apple a annoncé que le portage des applis cocoa serait très facile pour les x86 car même framework. Par contre, pour les carbons bah deja depuis un bout de temps Apple pousse à l'adoption de Cocoa. Carbon va rendre le portage vers x86 plus difficile donc je pense qu'Apple va vraiment tout faire pour le faire disparaitre car c'est une mauvaise pub de faire une appli que pour seul monde (PPC ou x86 pas le deux)
Je pense que commencer une appli en Carbon de nos jours est un enfermement inutile. D'accord c'est compatible avec les anciens OS mais bon mieux vaut regarder vers l'avenir nan ?

Je pense qu'il vaut mieux regarder vers les utilisateurs. Mais c'est mon point de vue...
Plus ca va, moins j'essaie de m'enfermer dans des technologies propriétaires, meme si, a priori elles semblent capable de produire un résultat rapide et sympa.
La plus grosse erreur que j'ai faite ses dix dernieres années a été de me lancer dans une application Mac "pure", utilisant Cocoa, Obj-C, AppleScript, QuickTime, etc. à fond la calle. Maintenant, elle est bloquée sur Mac et je m'y sens à l'étroit.
Ne parions pas trop gros sur l'avenir, tout en croisant les doigts pour qu'Apple continue longtemps son voyage, gardons a l'esprit qu'un jour il faudra peut etre abandonner le navire.
Et ce jour la, ne survivrons au naufrage que ceux qui auront anticipé et regardé vers les autres plateformes...

Cordialement

 

[Didier Guillion]

C'est bien marqué que toutes les fonctions GWorld sont "deprecated" sous tiger... Mais bon c'est à peu près ce que je cherchais... Mais vu que j'ai jamais rien codé sous OsX et tout le tralala d'interface builder etc, je risque de patauger un bon moment avec d'avoir un truc à l'écran... T'aurais pas un exemple d'app en GWorld Didier ?

Essaie de faire une recherche sur les exemples Apple sur le site de l'ADC. Il y en a (avait) pas mal si je me rappelle. Si tu ne trouve rien, reviens poser la question. Je dois avoir des trucs utilisables dans mes cartons mais il faut que je les retrouve.
Toutes mes applis utilisent des GWorld mais elles ne sont pas open source et de toute manière trop éloignées de ce que tu veut faire.
Par contre j'ai recupéré un bout de code qui travaille sur les GWorld mais en plus rapide que les routines Apple. Il faut que je vérifie la licence, je crois que je peut le diffuser.

Cordialement

 

[mpergand]

Carbon va rendre le portage vers x86 plus difficile donc je pense qu'Apple va vraiment tout faire pour le faire disparaitre car c'est une mauvaise pub de faire une appli que pour seul monde (PPC ou x86 pas le deux)

A mon avis ça va être duraille, puisque Cocoa repose sur Carbon
Lorsque tu utilises les NSArray, NSDictionary etc, en fait se sont des structures Carbon que tu manipules: CFArray, CFDictionary, etc...

Un truc marrant et incompréhensible: il n'y a pas d'objet de type boolean en Cocoa, c'est un NSNumber, mais si l'on regarde le nom de la classe pour un NSNumber contenant un bool, ça donne: NSCFBoolean j'ai du mal à suivre...

 

[SuperCed]

Essaie de faire une recherche sur les exemples Apple sur le site de l'ADC. Il y en a (avait) pas mal si je me rappelle. Si tu ne trouve rien, reviens poser la question. Je dois avoir des trucs utilisables dans mes cartons mais il faut que je les retrouve.
Toutes mes applis utilisent des GWorld mais elles ne sont pas open source et de toute manière trop éloignées de ce que tu veut faire.
Par contre j'ai recupéré un bout de code qui travaille sur les GWorld mais en plus rapide que les routines Apple. Il faut que je vérifie la licence, je crois que je peut le diffuser.

Cordialement

Les GWorld, c'est pas du QuickDraw?
Dans ce cas, il faut savoir qu'en effet, Apple pourrait ne pas poursuivre cet API. Déjà, elle est pas accélérée par la carte graphique comme Quartz 2D à ce que j'ai compris.
Corrigez moi si je me trompe.

D'autre part, pour moi, Carbon est aussi propriétaire que Cocoa non?

Donc si tu souhaites du vrai multiplateforme, Java/SWING est parfait, mais un peu plus lent.
Sinon, en plus rapide, tu as du code compilé pour chaque OS avec des librairies comme QT.

Si c'est que pour du Mac, alors, Cocoa est à conseiller.

 

[Didier Guillion]

Les GWorld, c'est pas du QuickDraw?
Dans ce cas, il faut savoir qu'en effet, Apple pourrait ne pas poursuivre cet API. Déjà, elle est pas accélérée par la carte graphique comme Quartz 2D à ce que j'ai compris.
Corrigez moi si je me trompe.

D'autre part, pour moi, Carbon est aussi propriétaire que Cocoa non?

Donc si tu souhaites du vrai multiplateforme, Java/SWING est parfait, mais un peu plus lent.
Sinon, en plus rapide, tu as du code compilé pour chaque OS avec des librairies comme QT.

Si c'est que pour du Mac, alors, Cocoa est à conseiller.

Tout a fait, la question essentielle est le degré de portabilité désiré.

Cordialement

 

[poneyman]

Je veux juste que ca marche sous mon tiger... en fait ca serait pour faire (entre autres) un raytracer, donc java / swing ca risque d'être un peu trop lent, mais j'ai pas besoin non plus d'acceleration 2D... je vais regarder du coté de GWorld, ou sinon je me rapatrierais sur Cocoa...

 

[SuperCed]

Manipuler les GWorld, c'est surtout bien si tu veux une compatibilité avec les version antérieure à MacOS X.

Si ce n'est que pour Tiger, je te conseille soit Quartz 2D, soit OpenGL.
Il sont plus facile à maîtriser que QuickDraw, et ils sont accélérés par la carte graphique.

S'il y a peu d'éléments graphiques comme des boutons, des slides, des champs, etc, je te conseille vivement OpenGL.
OpenGL est multiplateforme, très documenté, pas trop difficile à maîtriser.
Pour un Raytracer, ça te permettra de débuguer facilement car tu peux faire un autre contexte OpenGL à coté qui te fait un rendu temps réel afin de vérifier que tu es bien calé.

Si tu ne veux pas d'élément d'interface du tout, GLUT peut être intéressant avec OpenGL.
Il est livré en standard sous OS X avec les dev tools.