Disons qu'organiser toutes les données d'une application dans de gros buffers globaux, ce n'est pas naturel en développement objet :-)
Tu veux dire en java :D ? (ok ok, c'était un blague...)
Mais pas tant que ça en fait, d'un point de vue optimisation mémoire (surtout gestion cache et fragmentation), avoir des données "volumineuses" dans de gros buffer et que les objets aient juste les entrées pour y acceder n'est pas si mauvais que ça.
Et d'un point de vue programmation objet, je ne vois pas de soucis non plus. La POO pour moi (c'est un avis personnel et discutable) me donne surtout des outils pour gêrer les relations entre les données et leur traitement ainsi le flux d'execution (à un niveau assez élevé, je ne parle pas des for, if, ...)
Mais je prends toujours (ok, pas toujours du tout... mais je sais que c'est mal !) soin de séparer correctement mes données de mon code de traitement.
Au final, cela est assez agnostique de "l'endroit" ou tu ranges tes données, il suffit de bien encapsuler tes accès et tout se passe bien.
Après, on parle d'optimisation ! C'est sur que si tu n'en as pas besoin, et bien ça peut paraitre lourd à faire de cette manière.
Mais je pense aussi que si tu n'en as pas besoin, c'est que tu n'as pas besoin d'un accès direct au métériel non plus, donc peut-être qu'utiliser une surcouche comme SDL (si tu reste en 2D) serait plus intéressant pour toi.
Il faut bien se rendre compte que la lib OpenGL est écrite pour les gros besoins en performance, donc ça ne me surprends pas que cela colle avec une organisation optimale de données en mémoire.
Je trouve que les premières versions d'opengl avaient réussit à abstraire la réalité du hardware
OpenGL a toujours été près du matériel, la différence c'est qu'à l'époque, les cartes fonctionnaient de façon très différente.
Je pense que ce mouvement qui vise à donner aux développeurs un accès direct au hardware est bon pour les performances, mais mauvais pour la concurrence et l'innovation: un nouveau constructeur de carte graphique ne peut que faire comme les autres.
Là dessus je suis d'accord. Je ne pense pas que cela favorise l'innovation car il faudrait que quelqu'un avec une approche différente arrive avec un truc bien mieux que ce qu'il se fait actuellement pour arriver à percer (un peu comme à l'époque du glide).
Mais si on arrive par le bas (ce qui est un peu plus réaliste), on n'a pas le choix et il faut se contenter de suivre.
[^] # Re: OpenGL antique
Posté par moi1392 . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 4.
Tu veux dire en java :D ? (ok ok, c'était un blague...)
Mais pas tant que ça en fait, d'un point de vue optimisation mémoire (surtout gestion cache et fragmentation), avoir des données "volumineuses" dans de gros buffer et que les objets aient juste les entrées pour y acceder n'est pas si mauvais que ça.
Et d'un point de vue programmation objet, je ne vois pas de soucis non plus. La POO pour moi (c'est un avis personnel et discutable) me donne surtout des outils pour gêrer les relations entre les données et leur traitement ainsi le flux d'execution (à un niveau assez élevé, je ne parle pas des for, if, ...)
Mais je prends toujours (ok, pas toujours du tout... mais je sais que c'est mal !) soin de séparer correctement mes données de mon code de traitement.
Au final, cela est assez agnostique de "l'endroit" ou tu ranges tes données, il suffit de bien encapsuler tes accès et tout se passe bien.
Après, on parle d'optimisation ! C'est sur que si tu n'en as pas besoin, et bien ça peut paraitre lourd à faire de cette manière.
Mais je pense aussi que si tu n'en as pas besoin, c'est que tu n'as pas besoin d'un accès direct au métériel non plus, donc peut-être qu'utiliser une surcouche comme SDL (si tu reste en 2D) serait plus intéressant pour toi.
Il faut bien se rendre compte que la lib OpenGL est écrite pour les gros besoins en performance, donc ça ne me surprends pas que cela colle avec une organisation optimale de données en mémoire.
OpenGL a toujours été près du matériel, la différence c'est qu'à l'époque, les cartes fonctionnaient de façon très différente.
Là dessus je suis d'accord. Je ne pense pas que cela favorise l'innovation car il faudrait que quelqu'un avec une approche différente arrive avec un truc bien mieux que ce qu'il se fait actuellement pour arriver à percer (un peu comme à l'époque du glide).
Mais si on arrive par le bas (ce qui est un peu plus réaliste), on n'a pas le choix et il faut se contenter de suivre.