tipos - OpenGL: ¿Cuál es el problema con la depreciación?
tipos de depreciacion (5)
¿Por qué encuentran la necesidad de desaprobar una función tan útil que todos usan y para la que ninguna compañía de hardware en serio va a quitar soporte?
Supongo que Apple debe estar loco, porque MacOSX 10.7 solo admite 3.2 núcleos . Sin soporte de especificaciones de compatibilidad, sin extensión de compatibilidad ARB, nada. Puede crear un contexto 2.1 o un contexto básico 3.2.
Sin embargo, si quieres razones:
Por el bien de lo completo: lo que dijo Jesse Hall. El ARB ya no tiene que considerar la interacción entre la función fija y las nuevas características. Las matemáticas enteras, las texturas de matriz y varias otras características están definidas para no ser utilizables con la interconexión de funciones fija. OpenGL realmente ha mejorado en los últimos 3 años desde que salió GL 3.0; el ritmo de los cambios del ARB es bastante sustancial. ¿Habría sido posible si tuvieran que encontrar la manera de hacer que todas esas características interactúen con la función fija? Y si no tenían interacciones de funciones fijas, ¿no se estaría quejando entonces de que no puede acceder a las nuevas funciones desde su código anterior? Lo cual conduce muy bien a:
Sirve como una fuerte indicación de lo que uno debería estar usando. Incluso si el contexto de compatibilidad está siempre disponible, puede consultar OpenGL central para ver cómo se debe estar abordando la resolución de problemas.
Hace que la eventual unificación de escritorios GL y GL ES sea mucho más razonable. ES 2.0 descartó todas las cosas viejas y acaba de adoptar lo que podrías pensar como núcleo GL 2.1. El objetivo final será tener solo un OpenGL. Para hacer eso, debes poder eliminar el GL de escritorio de todos los cruft.
OpenGL 3.0 y 3.1 han dejado de lado bastantes características que considero esenciales. En particular, el uso de la función fija en sombreadores.
¿Alguien puede explicar cuál es realmente el problema con eso?
¿Por qué encuentran la necesidad de desaprobar una función tan útil que todos usan y para la que ninguna compañía de hardware en serio va a quitar soporte?
Como dijo, ninguna empresa de hardware eliminará el soporte para sombreadores de función fija, porque hay tantas aplicaciones existentes que los usan. Lo que no quieren hacer, sin embargo, es averiguar cómo especificar las interacciones entre los sombreadores FF y cada extensión futura que agreguen. Esas interacciones son muy complicadas (en parte porque los sombreadores FF son tan complicados), lo que genera errores y implementaciones inconsistentes entre los proveedores, las cuales son malas para los desarrolladores y los usuarios finales.
Entonces están dibujando una línea: si quieres usar sombreadores FF, no obtienes ninguna de las nuevas funcionalidades. Si desea una nueva funcionalidad, no puede usar sombreadores FF. Esto es muy similar a lo que hizo Microsoft en D3D10: agregó un montón de nuevas funcionalidades, pero al mismo tiempo eliminó por completo los sombreadores de función fija. La creencia es que el conjunto de desarrolladores que necesitan la nueva funcionalidad sin sombreador pero que no necesitan también sombreadores programables es muy pequeño.
Los sombreadores de funciones fijas se reemplazan con facilidad con sombreadores GLSL estándar, por lo que es difícil ver por qué lógicamente no deberían ser desaprobados.
Estoy menos seguro que usted de que no se eliminarán de mucho hardware en el futuro cercano ya que OpenGL ES 2.0 no es compatible con la cartera de FF (por lo que no es compatible con OpenGL ES 1.x). Me parece que gran parte del impulso con OpenGL en estos días proviene de la adopción generalizada de OpenGL ES en plataformas móviles y, con la funcionalidad FF, a partir de ahí habrá una considerable presión para alejarse de su uso.
De hecho, esperaría que la implementación más sencilla de OpenGL ES para reemplazar OpenGL estándar ampliamente en los próximos años, y la funcionalidad de FF puede desaparecer más porque la mayoría de hardware implementará OpenGL ES en lugar de porque se elimina del hardware que implementa el OpenGL completo
OpenGL permite tanto un perfil ''core'' como un perfil ''compatible''. Entonces, para la mayoría de los sistemas, no perderá ningún tipo de acceso a las funciones obsoletas o eliminadas.
Pero si quieres asegurarte de que sea compatible, es mejor que te mantengas en el núcleo. No se le garantizará un perfil de compatibilidad (incluso si la mayoría del hardware tiene uno y en el estado actual es más probable que encuentre un OpenGL desactualizado en lugar de uno solo central). También OpenGL ES ahora es un subconjunto de OpenGL, es posible escribir un programa OpenGL ES 2.x / 3.x y ejecutarlo en OpenGL 4.3 casi sin cambios.
Consola de juegos como las PlayStations y las de Nintendo que se envían con sus propias bibliotecas de gráficos en lugar de usar OpenGL.
Se basaban en OpenGL, pero aquí se desglosaron de forma similar a ES (no creo que ES 2.0 hubiera salido). Esos sistemas necesitan escribir sus propios controladores de gráficos y bibliotecas, pedirle a un proveedor de hardware que escriba lo que es básicamente una carga completa de bibliotecas de envoltura heredadas es un poco demasiado (todas las funciones fijas terminarían siendo implementadas en sombreadores en algún momento y es probable que glBegin / glEND solo se convierta en un VBO automáticamente de todos modos).
Creo que también ha sido importante garantizar que los desarrolladores conozcan la forma actual en que deberían estar programando. Durante décadas, a las personas se les ha enseñado la forma "incorrecta" de hacer las cosas de forma predeterminada y los objetos de búfer de vértice se han enseñado como un extra.
Se debe aclarar que una característica que está marcada como "obsoleta" no se elimina realmente. Por ejemplo, un contexto OpenGL 3.0 tiene todas las características: nada se ha ido. Además, algunos proveedores enviarán controladores que pueden crear contextos 3.1 y 3.2 utilizando un perfil de compatibilidad que también habilitará las características en desuso. Por lo tanto, observe de cerca qué hardware de proveedor va a admitir y pregunte sobre el modo de compatibilidad ARB para las características anteriores. (También existe el perfil "central" a partir de 3.2, que permite a los proveedores crear un controlador más delgado y malo si desean hacer tal cosa)
Tenga en cuenta que cualquier tarjeta actual ya no tiene una sección de hardware FF, solo ejecutan sombreadores. Cuando solicita el comportamiento de FF, el tiempo de ejecución de GL está creando sombreadores en su nombre.