Petit moteur 2D, quelle API?

S

SuperCed

Membre expert
Club iGen
20 Juin 2001
1 331
70
45
superced.rb38.eu
Je voudrais réaliser un petit moteur 2D, évidemment, j'ai quelques contraintes, et quelques exigences.

Pour le moment, j'hésite surtout entre OpenGL en Quartz 2D.

Je veux faire du code uniquement MacOS X. Il y a une partie écrite en ObjectiveC/Cocoa.
Je veux que ce soit en plein écran.
Il faut que le moteur soit rapide (le plus possible à condition que cela n'allonge pas énormément les temps de dev.
Il faut pouvoir afficher du texte, des sprites avec de l'alpha, de la transparence.

Je ne veux pas de la SDL (qui fonctionne en fait avec OpenGL) car il faut installer une librairie.
En gros, je ne veux au final qu'un éxécutable, et que l'utilisateur n'ait pas à installer des libs ou autres.

Le code doit être au maximum compatible avec les anciennes versions de MacOS X.


Sinon, je connais déjà pas mal OpenGL, par contre, je ne connais pas bien Quartz 2D. mais ce dernier n'a pas l'air bien difficile.

Autre chose, je veux absolument que l'API que j'utilise soit compatible avec un maximum de Mac différents.
Donc exit les extensions ARB complexe ou les langages proprios tels que cg.

Exit aussi Quickdraw qui est une technoloie sans trop d'avenir.

Voilà, avez-vous des conseils? Savez-vous si Quartz 2D est plus lent qu'OpenGL? (sur les systèmes déjà sortis : Jaguar, Panther).

il y aura aussi une partie son lié au moteur 2D.
Sinon, pour le son, je pense utiliser Core Audio. J'espère qu'il existe de bonnes passerelles entre QuickTime (pour l'import mp3) et Core Audio. Sinon, il y a Carbon sound manager que j'ai déjà eu l'occasion d'utiliser, mais tant qu'à utiliser des techno récentes, je me demande si ça vaut la peine de repartir là dedant.

Pour la gestion des périphériques d'entrée, j'aimerais utiliser HID manager. Existe-il quelque chose de meilleur?

Merci.
 
Non, Java ne m'intéresse pas.
C'est trop lent, désolé.

J'aime beaucoup ce lengage et son API. Très bien fait, très bien documenté, multiplateforme, mais là, j'ai besoin de quelque chose de plus rapide.


Je ne connais pas Java2D, je connais Java 3D mais je pense que ce sera toujours plus lent que du Quartz appelé depuis du langage C.

Au passage, java 3D est assez lent aussi et pourtant, ça utilise OpenGL.

Non, c'est OpenGL ou Quartz, pas autre chose. j'ai encore du mal à me décider d'ailleurs...
 
Voilà a dit:
il est difficile de déterminé de quelle des deux est le plus rapide. Les deux ont été construit en c ( à moins que ce soit en "objectif c" pour Quartz 2D je ne sais plus je ne l'ai jamais utilisé non plus). Du moins les deux sont fais en langage compilé donc trés rapide.

Pour la gestion des périphériques d'entrée a dit:
Glut si l'on veut etre cohérent... toutefois openGL ES est probablement plus actuel (je sais c'est un api en extention d'openGL et donc tu devras downloader la bibliothéque et actualiser la bibliothèque OpenGL par la meme occasion ) ainsi tu auras un code plus cohérent dans son ensemble donc plus prope et mieux lisible. :)
Cliquez pour agrandir...
Cliquez pour agrandir...
 
SuperCed a dit:
Non, Java ne m'intéresse pas.
C'est trop lent, désolé.

J'aime beaucoup ce lengage et son API. Très bien fait, très bien documenté, multiplateforme, mais là, j'ai besoin de quelque chose de plus rapide.


Je ne connais pas Java2D, je connais Java 3D mais je pense que ce sera toujours plus lent que du Quartz appelé depuis du langage C.

Au passage, java 3D est assez lent aussi et pourtant, ça utilise OpenGL.

Non, c'est OpenGL ou Quartz, pas autre chose. j'ai encore du mal à me décider d'ailleurs...
Cliquez pour agrandir...

De ce que j'ai expérimenté, et de ce que j'ai lu sur différents forums, Quartz 2D reste plus lent qu'OpenGL. Il est par contre nettement plus simple à utiliser, ça il n'y a pas photos. Mais pour faire un jeu avec un affichage un poil complexe, ça devient rapidement trop lent, ou trop gourmand. Quartz Extreme gère juste la fenetre, et les effets autour de celle-ci => Il n'y a pas d'acceleration matérielle de ce qui est affiché dans la fenetre avec Quartz 2D.

@+

Guillaume
 
SuperCed a dit:
Non, c'est OpenGL ou Quartz, pas autre chose. j'ai encore du mal à me décider d'ailleurs...
Cliquez pour agrandir...
Il y a aussi Cocoa avec des classes comme NSImage ou NSBezierPath qui permettent de dessiner. Cela me semble plus simple que Quartz, objet et peut être plus efficace ? En tout cas Quartz doit être le plus gourmand en ressource (voir les plaintes sur le "manque de réactivité" du Finder)
 
theidiot a dit:
il est difficile de déterminé de quelle des deux est le plus rapide. Les deux ont été construit en c ( à moins que ce soit en "objectif c" pour Quartz 2D je ne sais plus je ne l'ai jamais utilisé non plus). Du moins les deux sont fais en langage compilé donc trés rapide.



Glut si l'on veut etre cohérent... toutefois openGL ES est probablement plus actuel (je sais c'est un api en extention d'openGL et donc tu devras downloader la bibliothéque et actualiser la bibliothèque OpenGL par la meme occasion ) ainsi tu auras un code plus cohérent dans son ensemble donc plus prope et mieux lisible. :)
Cliquez pour agrandir...

Pour le fenêtrage, je préfère Cocoa ou CoreGraphic.
Pour OpenGL ES, c'est pas pour les téléphones mobiles ça?
 
ntx a dit:
Il y a aussi Cocoa avec des classes comme NSImage ou NSBezierPath qui permettent de dessiner. Cela me semble plus simple que Quartz, objet et peut être plus efficace ? En tout cas Quartz doit être le plus gourmand en ressource (voir les plaintes sur le "manque de réactivité" du Finder)
Cliquez pour agrandir...
Correction : apres consultation de la doc Apple, les classes Cocoa utilisent Quartz (mais je continue de penser que c'est plus simple a utiliser que Quartz en direct).
Donc le debat se resument bien a un choix entre Quartz et OpenGL.
Fin de la parenthese ;)
 
Haut Bas
Back