Estoy buscando a alguien con experiencia en programación en C que quiera trabajar para crear un blitter 2D basado en OpenGL que pueda coexistir con el blitter por software actual.
Si alguien conoce a alguien con conocimientos de C que quiera ayudar al proyecto decidles que me escriban. No importa que esa persona no conozca el funcionamiento de Bennu: si hace falta puedo ayudarle y estoy seguro de que Splinter también resolverá dudas allá donde yo no pueda.
Es importante notar que no se trata de un proyecto oficial sino uno iniciado por mí de forma que el código -inicialmente, al menos- no entraría en los repositorios oficiales.
He puesto algunos detalles más aquí:
http://bennugd-mobile.blogspot.com/2012/06/opengl-coder-needed.html
Tendrias que "reclutar" a Hiperbou que me acuerdo que con su DivGL hizo un acercamiento al OpenGL del mundo Div, aunque creo recordar que su interprete estaba basado en el lenguaje Lua.
Salu2
TransDiv
Quote from: josebita on June 03, 2012, 05:37:28 PM
Estoy buscando a alguien con experiencia en programación en C que quiera trabajar para crear un blitter 2D basado en OpenGL que pueda coexistir con el blitter por software actual.
Si alguien conoce a alguien con conocimientos de C que quiera ayudar al proyecto decidles que me escriban. No importa que esa persona no conozca el funcionamiento de Bennu: si hace falta puedo ayudarle y estoy seguro de que Splinter también resolverá dudas allá donde yo no pueda.
Es importante notar que no se trata de un proyecto oficial sino uno iniciado por mí de forma que el código -inicialmente, al menos- no entraría en los repositorios oficiales.
He puesto algunos detalles más aquí:
http://bennugd-mobile.blogspot.com/2012/06/opengl-coder-needed.html (http://bennugd-mobile.blogspot.com/2012/06/opengl-coder-needed.html)
Quote from: Transdiv on June 04, 2012, 08:22:33 PM
Tendrias que "reclutar" a Hiperbou que me acuerdo que con su DivGL hizo un acercamiento al OpenGL del mundo Div, aunque creo recordar que su interprete estaba basado en el lenguaje Lua.
Salu2
TransDiv
Quote from: josebita on June 03, 2012, 05:37:28 PM
Estoy buscando a alguien con experiencia en programación en C que quiera trabajar para crear un blitter 2D basado en OpenGL que pueda coexistir con el blitter por software actual.
Si alguien conoce a alguien con conocimientos de C que quiera ayudar al proyecto decidles que me escriban. No importa que esa persona no conozca el funcionamiento de Bennu: si hace falta puedo ayudarle y estoy seguro de que Splinter también resolverá dudas allá donde yo no pueda.
Es importante notar que no se trata de un proyecto oficial sino uno iniciado por mí de forma que el código -inicialmente, al menos- no entraría en los repositorios oficiales.
He puesto algunos detalles más aquí:
http://bennugd-mobile.blogspot.com/2012/06/opengl-coder-needed.html (http://bennugd-mobile.blogspot.com/2012/06/opengl-coder-needed.html)
parece buena idea, sí. Mil gracias.
La librería hiperGL está bajo licencia GPL, tal y como lo entiendo, si se usara junto con Bennu, éste tendría que pasar a ser GPL también. Lo cual supongo que sería un problema.
¿Me equivoco?
Quote from: hiperbou on June 15, 2012, 07:20:17 AM
La librería hiperGL está bajo licencia GPL, tal y como lo entiendo, si se usara junto con Bennu, éste tendría que pasar a ser GPL también. Lo cual supongo que sería un problema.
¿Me equivoco?
Entiendo que es así, sí.
Hiperbou lo comenta porque he estado hablando con él de tratar de convertir HiperGL en el blitter que comentaba.
Su blitter es GPL y eso obligaría (según he estado leyendo en la web de la FSF) a que el paquete completo BennuGD+Blitter OpenGL se distribuyera como GPL a pesar de tener partes del código con licencia Zlib.
Según tengo entendido, el único sitio donde esto podría dar problemas sería en iOS (donde no se podrían distribuir en la App Store aplicaciones hechas con ese blitter y habría que usar el blitter por software). Por otra parte, en iOS es donde más falta haría.
Personalmente no tengo muy claro, entonces, si merece la pena que me ponga a hacer esto teniendo en cuenta que tampoco tengo demasiado tiempo ultimamente para hacer estas cosas.
con tener el engine de hiperbou con el que hizo el robox bastaria ;D
Lo que no veo claro es el baile de licencias, si se usara hipergl+bennu la zlib se puede convertir a GPL, pero no tiene sentido que luego se distribuya en otro paquete como zlib siendo lo mismo.
Quote from: FreeYourMind on June 15, 2012, 07:58:01 AM
con tener el engine de hiperbou con el que hizo el robox bastaria ;D
Algún día le haré un hermanito. xD
no es asi...
hiperbou, tu eres el creador de la librerias y puedes cambiarle la licencia si asi lo deseas...
por otro lado, no tienes que portar la hiperGL a BennuGD, la idea es hacer un blitter para BennuGD, y ahi no habria problemas de licencias.
si por otro lado, y en caso de que tu puedas encargarte del soporte openGL para BennuGD, y tu no quieres optar por la licencia de BennuGD para hacer el blitter, entonces el port openGL puede ser no oficial, y creo que ahi puedes cambiarle al BennuGD de tu port la licencia por licencia GPL, pero yo debo seguir manteniendo los terminos de la licencia actual en el BennuGD oficial.
que josebita me corrija si me equivoco.
No se si me estoy metiendo donde no me llaman, pero me parece que la licencia es exclusiva del modulo como dice Splinter, siendo GPL la lib final, debería ir acompañada del source code del propio modulo bennu, para que cualquiera que quiera modificarla pueda hacerlo, y esto no afecta al propio bennu, aunque no estoy seguro del todo.
El probliemilla mas serio es que la GPL es rechazada por Apple y no se podría colgar nada que la use en ninguna de sus tiendas, tanto la de mac como la de ios.. es una pena este pensamiento de apple..
Quote from: Erkosone on June 15, 2012, 06:21:12 PM
No se si me estoy metiendo donde no me llaman, pero me parece que la licencia es exclusiva del modulo como dice Splinter, siendo GPL la lib final, debería ir acompañada del source code del propio modulo bennu, para que cualquiera que quiera modificarla pueda hacerlo, y esto no afecta al propio bennu, aunque no estoy seguro del todo.
El probliemilla mas serio es que la GPL es rechazada por Apple y no se podría colgar nada que la use en ninguna de sus tiendas, tanto la de mac como la de ios.. es una pena este pensamiento de apple..
no es lo que quise decir, pero si, eso tambien me parece que es asi... ya que el modulo se carga dinamicamente...
No me queda claro cuál debe ser la licencia de un programa zlib que utilice un plugin GPL. De todas formas, eso se podría resolver casi seguro con la cláusula de enlazado (que habría que ver si hiperbou acepta, claro):
http://en.wikipedia.org/wiki/GPL_linking_exception
El tema es que esto es un poco distinto de lo que había planteado: nadie se ha ofrecido para hacer el blitter y miraba la opción de usar esto como blitter. En realidad no serviría como blitter para iOS por los temas de licencia así que no sé si me merece la pena, suponiendo que pudiera adaptarlo, claro.
En todo caso, como mucho quedaría como módulo no oficial... No sé si merece la pena o si podría servirme para aprender qlgo y luego poder escribir un blitter nuevo zlib. Sinceramente me parece mucho curro y no tengo claro que pudiera hacerlo: no tengo demasiado tiempo...
Vamos, que estoy un poco rallado con esto...
en tu caso, la version iOS si necesitas compilacion estatica, entonces si afecta la licencia a todo, pero bueno, no seria un port oficial... una pena...
pero como sea, la idea no es usar algo ya hecho, sino hacer algo nuevo con la experiencia ya adquirida, que es algo muy diferente.
Quote from: SplinterGU on June 15, 2012, 08:35:39 PM
en tu caso, la version iOS si necesitas compilacion estatica, entonces si afecta la licencia a todo, pero bueno, no seria un port oficial... una pena...
pero como sea, la idea no es usar algo ya hecho, sino hacer algo nuevo con la experiencia ya adquirida, que es algo muy diferente.
lo ideal sería usar el hipergl para aprender y luego escribir yo el mío, claro. el problema es el tiempo...
Bueno, este tema ya sabemos que no es nuevo.
Si sirve de algo, yo apoyo hacer una colecta dedicada a animar a un desarrollador que implemente ese blitter openGL con la mayor parte de las características ya existentes en Bennu.
Quote from: PiXeL on June 15, 2012, 10:16:36 PM
Bueno, este tema ya sabemos que no es nuevo.
Si sirve de algo, yo apoyo hacer una colecta dedicada a animar a un desarrollador que implemente ese blitter openGL con la mayor parte de las características ya existentes en Bennu.
La verdad es que no es mala idea... Yo pondría algo de dinero.
¿Qué os parece a los demás?
no se preocupen, ya hare yo el port a opengl, lo unico que no lo podre hacer a corto plazo...
Por eso el crowdfunding, para que te merezca la pena hacerlo a corto plazo xD
Acabo de hacer una pequeña donación para motivar a Splinter xDDD
gracias KeoH, ya la he recibido...
ahora mismo estoy en proyecto de darle al motor un motor para hacer juegos tipo outrun... y me tiene un poco ocupado.
Quote from: SplinterGU on June 16, 2012, 01:08:04 AM
ahora mismo estoy en proyecto de darle al motor un motor para hacer juegos tipo outrun... y me tiene un poco ocupado.
Por fin! XD
No sería lo más fácil usar la SDL 1.3?? Parece sencilla, y además ya tiene ports a todo cacharro viviente.
O algún invento como esto:
http://code.google.com/p/sdl-gpu/
Quote from: hiperbou on June 16, 2012, 09:47:25 AM
Quote from: SplinterGU on June 16, 2012, 01:08:04 AM
ahora mismo estoy en proyecto de darle al motor un motor para hacer juegos tipo outrun... y me tiene un poco ocupado.
Por fin! XD
No sería lo más fácil usar la SDL 1.3?? Parece sencilla, y además ya tiene ports a todo cacharro viviente.
O algún invento como esto:
http://code.google.com/p/sdl-gpu/
a favoritos y a revisar... gracias!
Quote from: hiperbou on June 16, 2012, 09:47:25 AM
Quote from: SplinterGU on June 16, 2012, 01:08:04 AM
ahora mismo estoy en proyecto de darle al motor un motor para hacer juegos tipo outrun... y me tiene un poco ocupado.
Por fin! XD
No sería lo más fácil usar la SDL 1.3?? Parece sencilla, y además ya tiene ports a todo cacharro viviente.
O algún invento como esto:
http://code.google.com/p/sdl-gpu/
hiper, probe la sdl-gpu, pero va para atras... con los demos va a 60fps constantes, ahora cuando a los demos le pones 1000 sprites, ya la performance cae a 7fps... peor que bennugd... no entiendo.
quizas estoy linkeando con alguna libreria gl de software o no se.
Ahora mismo no tengo nada de dinero para colaborar... pero vengo a dar algo de apoyo moral :D
Vamos Splinter! Tu Puedes! Tu Puedes!
:)
PASANOS EL CODIGO Y TE ECHAMOS UNA MANO HABER QUE ES..
;D
Quote from: l1nk3rn3l on August 11, 2012, 03:03:04 PM
PASANOS EL CODIGO Y TE ECHAMOS UNA MANO HABER QUE ES..
;D
Como comentaba en otro hilo, link, también podeis echarle un ojo al código de cocos2d-x, que es c++ y está orientado a la misma clase de juegos que Bennu:
https://github.com/cocos2d/cocos2d-x/
Quote from: l1nk3rn3l on August 11, 2012, 03:03:04 PM
PASANOS EL CODIGO Y TE ECHAMOS UNA MANO HABER QUE ES..
;D
el codigo es el sample de la SDL
OK checkaremos haber como nos va
Yo añado 30€ de recompensa para el que lo consiga xD
Añadiría más, pero mi novia me mataría xD
¿Alguien está trabajando en esto?
Ojalá. Me han reportado que PiXFrogger en un Samsung Galaxy Tab 2 de 10.1 va a 2 o 3 fps xD
Quote from: PiXeL on October 04, 2012, 01:14:26 PM
Ojalá. Me han reportado que PiXFrogger en un Samsung Galaxy Tab 2 de 10.1 va a 2 o 3 fps xD
yo he tenido que reducir la resolucion del juego para obtener performance.
Ya, pero al usuario no le gusta que los juegos no llenen la pantalla :\
si se llena :P usamos el scale_resolution :D
wait... decis que con scale_resolution el juego va mejor que sin scale_resolution, ambos ocupando toda la pantalla?
como es posible esto? josebita hizo el scale_resolution por acceleracion?
sino, algo no puede ser.
Quote from: SplinterGU on October 04, 2012, 04:32:40 PM
wait... decis que con scale_resolution el juego va mejor que sin scale_resolution, ambos ocupando toda la pantalla?
como es posible esto? josebita hizo el scale_resolution por acceleracion?
sino, algo no puede ser.
No, creo que lo que dicen es que a mitad de resolución+scale_resolution les va mejor que a resolución normal+scale_resolution.
Por cierto, la última versión de SDL2 del repositorio de desarrollo introduce el concepto de resoluciones virtuales con escalado por hardware: que nos vendría de perlas para hacer esto.
pixel, te has precipitado y te has metido en un buen marrón, ya veras que las molestias que vas a tener en miles de dispositivos android y sus usuarios. Deberias haber esperado mas tiempo a que se probará bennu en mas dispositivos.
Quote from: FreeYourMind on October 04, 2012, 06:55:02 PM
pixel, te has precipitado y te has metido en un buen marrón, ya veras que las molestias que vas a tener en miles de dispositivos android y sus usuarios. Deberias haber esperado mas tiempo a que se probará bennu en mas dispositivos.
¿A qué viene eso?
Quote from: josebita on October 04, 2012, 06:01:42 PM
Quote from: SplinterGU on October 04, 2012, 04:32:40 PM
wait... decis que con scale_resolution el juego va mejor que sin scale_resolution, ambos ocupando toda la pantalla?
como es posible esto? josebita hizo el scale_resolution por acceleracion?
sino, algo no puede ser.
No, creo que lo que dicen es que a mitad de resolución+scale_resolution les va mejor que a resolución normal+scale_resolution.
Por cierto, la última versión de SDL2 del repositorio de desarrollo introduce el concepto de resoluciones virtuales con escalado por hardware: que nos vendría de perlas para hacer esto.
eso de la resolucion virtual con escalado por hardware suena mejor... quiero meterme con el port a la SDL2, pero ahora el poco tiempo libre que tengo lo dedico a Paper (ya decir que tengo poco tiempo)... y tambien quiero cambiar algunas interioridades del motor en cuanto a video...
PiXeL, si bien tengo pensado comprarte el juego... si quieres pasamelo por mail, que lo pruebo en mis dispositivos android y te comento, no puede ser que vaya tan lento...
si quieres tambien comentarme todo lo que usas por privado o mail, mejor, puedo ver que sugerirte o que revisar para lograr mayor performance.
Quote from: josebita on October 04, 2012, 06:57:36 PM
Quote from: FreeYourMind on October 04, 2012, 06:55:02 PM
pixel, te has precipitado y te has metido en un buen marrón, ya veras que las molestias que vas a tener en miles de dispositivos android y sus usuarios. Deberias haber esperado mas tiempo a que se probará bennu en mas dispositivos.
¿A qué viene eso?
No entiendo porque preguntas. Pixel ha pedido betatesters para el juego, y yo mismo le he reportado que todavia no funcionaba por ejemplo en la Yinlips, con version 2.3.
Deberia haber esperado a que probaramos en mas plataformas, porque con tantos usuarios usando dispositivos distintos le van a salir mas cosas de este tipo, y cuando algo es comercial despues para dar soporte a esta gente va a tener mas molestias que alegrias.
Ya veremos, espero que no las tenga, pero ya se como son estas cosas en mi empresa ocurre lo mismo, tenemos siempre algo nuevo que aparece en dispositivos que teoricamente deberian funcionar igual, y tu sabes esto mejor que nadie ya que eres el que lleva los ports....
free, no, esta excelente lo de PiXeL, primero imagino que no es decision de el, cuando el juego entra en el market o no, e imagino que no es cosa de subirlo y ya, que te dan vueltas, asi que si logro subirlo excelente...
ademas, si no funciona en galaxy tab 2, mala suerte, no es compatible con galaxy tab 2, y listo... como si todas las aplicaciones del market funcionaran en todos los dispositivos android... no es asi, aca en casa hay unos cuantos dispositivos android y no todas las aplicaciones funcionan en todos los dispositivos.
Quote from: SplinterGU on October 04, 2012, 04:32:40 PM
wait... decis que con scale_resolution el juego va mejor que sin scale_resolution, ambos ocupando toda la pantalla?
como es posible esto? josebita hizo el scale_resolution por acceleracion?
sino, algo no puede ser.
lo que digo es que a mitad de resolucion + scale_resolution va mas rapido que a resolucion normal sin scale_resolution.
seguro que si no usas scale_resolution y seteas el video segun el modo del dispositivo te va mas rapido aun.
Quote from: SplinterGU on October 04, 2012, 11:48:50 PM
seguro que si no usas scale_resolution y seteas el video segun el modo del dispositivo te va mas rapido aun.
en iphone, por no menos, puedo decirte que no pasa asi.
Si seteo el video en la resolucion nativa del juego el FPS caen a la mitad.
es raro, porque el escalado es por software y lleva translacion pixel a pixel, de un mapa a pantalla, leyendo las direcciones donde van los pixels de una tabla en memoria precalculada.
Yo creo que depende de cada juego, en mis pruebas yo tenia un par de procesos con flag 16 que en tamaño normal significaban muchos pixel mas por procesar que cuando estaban a mitad de resolucion
si usas profundidad de color diferente de la del dispositivo y fuerzas con eso un conversion de la SDL tambien tienen mas proceso...
pero no se como setea el tema en los dispositivos.
la clave es buscAR esto en google
SDL_OPENGLBLIT
permite usar las surfaces de bennu 2d con las de opengl al tiempo
parece que otra solucion seria convertir las surfaces2d a las surfaces 3d
http://www.linuxquestions.org/questions/programming-9/sdls-ttf-api-doesnt-work-with-opengl-468448/ (http://www.linuxquestions.org/questions/programming-9/sdls-ttf-api-doesnt-work-with-opengl-468448/)
pero seria impractico ya que se haria doble trabajo..
espero sirva de algo..
http://www.libsdl.org/tmp/SDL-1.2/test/testgl.c
nosotros no usamos surfaces...
y ya estoy trabajando en una version opengl como mencione...
lo que sucede es que tengo que pensar en como resolver el tema de que mapas subir a la placa de video y cuales no... o sea, nadie querra un mapa de durezas consumiendo memoria de video... tengo que pensar que hacer con esto y como resolverlo.
para mi, lo ideal es agregar nuevas funciones para decir que mapas van acelerados y cuales se procesaran de la vieja forma...
otra cosa en cuanto a opengl, se perdera el render a 8bits/1bit, se deberan convertir (automaticamente en memoria) los mapas a 32bits... o quizas se pueden hacer algunos trucos, para evitar usar 32bits, pero no dejara de tener que convertirse y se perderan las maravillas de tener (cambiar) paletas individuales para los mapas de 8 bits sin sacrificio de rendimiento.
son algunos temas que tengo que pensar, si rompo y sigo adelante pensando en el futuro o compatibilizo y hago chapuzas para que funcione.
Si se me deja opinar, soy de la opinión de romper y pensar en el futuro.
Quote from: osk on December 12, 2012, 05:37:48 PM
Si se me deja opinar, soy de la opinión de romper y pensar en el futuro.
Sep, ya estamos grandecitos para los 8 bits
si claro el que desee usar 8 bits que use el render sobre software y si corres un juego de 8 bits en
la version opengl no deberia correr para no perder tiempo..
me parece bien
claro que se permite opinar, de hecho eso quiero, opiniones al respecto.
Me parece que si va a ser mejor openGL en todo lo demas, es mejor tirar hacia adelante. Ademas los mismos efectos de coloreado se pueden conseguir con 32 bits.
osea que todo bennu pasaría a funcionar en opengl? no seria un modulo opcional nomás?
Quote from: gecko on December 12, 2012, 06:13:33 PM
osea que todo bennu pasaría a funcionar en opengl? no seria un modulo opcional nomás?
posiblemente estaran las 2, sin poder convivir en el mismo dcb.
ah, pero digamos que esos cambios son solo para los que "quieran usar opengl" y el modulo de video "comun/sdl" seguirá funcionando como ahora?
si es asi esta bien, dale para adelante nomas! :P
ok, igual si no quieren opengl, avisen, no me hagan trabajar al pedo...
Quote from: SplinterGU on December 12, 2012, 07:46:03 PM
ok, igual si no quieren opengl, avisen, no me hagan trabajar al pedo...
YO QUIERO!!!
los ports a mobiles y a OUYA lo van a necesitar!!
jajajajaja si si, queremos! para GPUs y aparatos modernos opengl debe ser una bestialidad en rendimiento me imagino. Y por eso mismo esta bueno que se cambie/rompa todo lo que haga falta.
Pero para las cositas simples, o capas aparatos viejos, o remakes de juegos simples, está bueno mantener lo que ya está.
Igual es mi opinión nomás. y no soy precisamente de los mas productivos o colaboradores en esta comunidad, así que tampoco es que me tengan que dar demasiada bola! :P
genial
Voy a hacer como si no hubiera leído este hilo, porque sino me va a dar algo hasta que el módulo sea publicado xD
modulos, son varios muchos.
Quote from: SplinterGU on December 12, 2012, 08:31:06 PM
modulos, son varios muchos.
Guau, jolin, lo que trabajas splinter, no creo que sea tan paciente de esperar a que lo acabes. ;D
Suena bien lo de openGL, y, lo de muchos modulos, menuda intriga.
muchos, son 4 o 5 para mi
OpenGL sí, por favor!
Y por cierto, lo de la compatibilidad con modos de menos colores tampoco lo veo tan importante, no hay lucha gente que siga jugando con las paletas y el look se puede emular sin problemas.
Yo estoy a favor de romper la compatibilidad hacia atrás xDD hay q mirar al futuro. Sino siempre se puede bajar alguien la version anterior del compilador e interprete y distribuir sus juegos con el (al menos en PC) :)
Quote from: KeoH on December 12, 2012, 10:34:58 PM
Yo estoy a favor de romper la compatibilidad hacia atrás xDD hay q mirar al futuro. Sino siempre se puede bajar alguien la version anterior del compilador e interprete y distribuir sus juegos con el (al menos en PC) :)
Traducción:
Yo mataría a todas las personas viejas porque son más lentas y nos frenan al resto xD
Na, realmente, con la modularidad de BennuGD, creo que podremos tener ambas y que convivan. Cuantas más posibilidades, ¡mejor!
Hay smartphones supercutres en los que PiXFrogger funciona realmente bien y Angry Birds realmente mal, por la dependencia de aceleración gráfica.
Pixel ... no desveles mis planes de dominación mundial !!! xDDDDDDDD
Quote from: PiXeL on December 12, 2012, 11:00:21 PM
Hay smartphones supercutres en los que PiXFrogger funciona realmente bien y Angry Birds realmente mal, por la dependencia de aceleración gráfica.
si, eso me preocupa, bueno, vamos a ver como soluciono el tema para que dependiendo de las posibilidades de hardware podamos usar una u otra, o que las funciones aceleradas no afecten si no hay aceleracion grafica... pero definitivamente, funciones nuevas se necesitan.
Splinter, una sugerencia, estuve leyendo varios foros donde hay gente que se curra muchos efectos impresionantes para juegos, y leí que para hacer posible todos esos efectos hay que trabajar con "Pixel Buffer Objects" sería una genialidad si logras implementar las funciones MAP_GET_PIXEL() y MAP_SET_PIXEL() con esta técnica, así se podrá manipular la imagen a una velocidad de vértigo, esto trata sobre manipular un pixel sin hacer el paso intermedio de copia de su información a la memoria ram de sistema, se hace directamente desde la memoria de vídeo.
Si te pones con esto, mi sugerencia es que apliques aceleración al sistema destination que hiciste o como lo llamaras, ahora no recuerdo bien, hablo del sistema que permite usar un mapa creado desde el programa como canvas para los procesos o scroll, si lo dejas acelerado y las funciones que te comento usan los buffer de pixel se pueden hacer algoritmos ultra rápidos para manipular la imagen y dar efectos muy interesantes, además de poder hacer "fade" a un mapa con transiciones muy elaboradas de color.
Sea como sea, animo con el trabajo :)
si, es la idea.
Quote from: SplinterGU on December 12, 2012, 05:33:17 PM
otra cosa en cuanto a opengl, se perdera el render a 8bits/1bit, se deberan convertir (automaticamente en memoria) los mapas a 32bits... o quizas se pueden hacer algunos trucos, para evitar usar 32bits, pero no dejara de tener que convertirse y se perderan las maravillas de tener (cambiar) paletas individuales para los mapas de 8 bits sin sacrificio de rendimiento.
son algunos temas que tengo que pensar, si rompo y sigo adelante pensando en el futuro o compatibilizo y hago chapuzas para que funcione.
Yo también digo que rompas y siguas adeltante...
Tener opengl, sobre todo en dispositivos móviles donde las resoluciones varían y los gráficos se necesitan escalar mucho para alcanzarlas, es una gran ventaja.
Yo tambien quiero!
Si eso resulta una mejora en todos los procesos a nivel gráfico, como escalados o rotaciones sin perdida de resolución, que ahora se pixelan al rotar o cambiar de tamaño aunque estén en 32bits.
Quote from: Coptroner on September 16, 2013, 09:13:13 AM
Yo tambien quiero!
Si eso resulta una mejora en todos los procesos a nivel gráfico, como escalados o rotaciones sin perdida de resolución, que ahora se pixelan al rotar o cambiar de tamaño aunque estén en 32bits.
Si te interesa, hemos armado un bote para animar a Splinter :)
http://forum.bennugd.org/index.php?topic=3606.msg61482#msg61482 (http://forum.bennugd.org/index.php?topic=3606.msg61482#msg61482)
Me parece que esta todo muy parado. :S
Quote from: Comandante on March 20, 2015, 11:02:12 AM
Hola,refloto para saber cómo va esto.
Sonaba más que interesante. ;D
mi fork de bennu usa OpenGL, aunque indirectamente a través de SDL. Sólo soy código fuente, eso sí.
Tiene, además, algunas limitaciones respecto a bennu como que el renderizado a mapas es ahora más lento que antes.
https://bitbucket.org/josebagar/pixtudio