Bien, acabo de mirar un poco como va el SDL 1.3.
La verdad que tiene cosas buenas y cosas malas...
Buenas:
- tiene soporte de acceleracion de hardware (opengl).
- tiene soporte de otras cosas que comento josebita como acelerometros y otras cosas.
- se usa utf16 para las keys
Malas:
- para sacarle provecho a la acceleracion habria que trabajar directamente con texturas SDL en lugar de manejar los mapas nativamente, con lo cual perdemos rendimiento al usar rotaciones (a menos que tenga ya rotaciones nativas usando opengl, cosa que no se) o al querer acceder a los pixels o hacer un map_put (sobre otro mapa)
- no hay soporte de CDROM, fue eliminado.
- cantidad de plataformas que este disponible
- podemos usar la capa de compatibilidad con 1.2, pero esto significa una perdida de rendimiento, y no se asegura compatibilidad 100%
bueno, aca les dejo el link de la wiki de la guia de migracion
http://wiki.libsdl.org/moin.cgi/MigrationGuide
No tengo ni idea de como va esto xD me temo q no podré ayudar en nada xDDD
Quote from: SplinterGU on July 18, 2011, 05:08:02 PM
Bien, acabo de mirar un poco como va el SDL 1.3.
La verdad que tiene cosas buenas y cosas malas...
Buenas:
- tiene soporte de acceleracion de hardware (opengl).
- tiene soporte de otras cosas que comento josebita como acelerometros y otras cosas.
- se usa utf16 para las keys
Malas:
- para sacarle provecho a la acceleracion habria que trabajar directamente con texturas SDL en lugar de manejar los mapas nativamente, con lo cual perdemos rendimiento al usar rotaciones (a menos que tenga ya rotaciones nativas usando opengl, cosa que no se) o al querer acceder a los pixels o hacer un map_put (sobre otro mapa)
- no hay soporte de CDROM, fue eliminado.
- cantidad de plataformas que este disponible
- podemos usar la capa de compatibilidad con 1.2, pero esto significa una perdida de rendimiento, y no se asegura compatibilidad 100%
bueno, aca les dejo el link de la wiki de la guia de migracion
http://wiki.libsdl.org/moin.cgi/MigrationGuide
Perder el soporte con el CDROM, es algo que se puede asumir, ya que con wavs y oggs es mucho más flexible el asunto.
Lo de aceleración por hardware es algo que veo necesario.
es mas bien un pensamiento en voz alta y comentar un poco que rumbo o ideas pretende seguir el proyecto... no pretendo que nadie se enrolle en ayudar.
La aceleración por Hardware suena muy interesante. Podría mejorar el rendimiento en iPhone?
Hombre, supongo que si se usa OpenGL, esta llevará sus algoritmos de rotación y escalado, porque para eso se diseñó ¿no?
Lo de perder rendimiento con las funciones PUT es una put*da (;D) porque precisamente son las funciones más lentas, aunque a lo mejor es más rápido que antes con las SDL a pelo, habría que mirarlo.
Si no, a las malas ¿costaría mucho tener una rama dedicada a SDL 1.2 y otra a 1.3? Es decir, que si no hay muchos módulos que cambien, lo mismo se pueden tener módulos oficiales que soporten una u otra ¿no era la idea original de bennu?
Sólo es una idea al viento.
drumpi, OpenGL tiene rotaciones, obviamente, lo que no implica que SDL las tenga, de hecho SDL nunca tuvo rotaciones, salvo por modulos externos que son bastante poco performantes.
con especto al PUT es porque las texturas (ya no serian surfaces SDL, sino texturas SDL) van en la placa de video, por eso es que van aceleradas, hacer un put, seria traerlo de la memoria de video a la convencional, hacer el put y volver a subirlo... en la wiki lo dice claramente, que estas funciones seran mas lentas.
y con respecto a la capa de compatibilidad que es mas lento una aplicacion SDL 1.2 usando SDL 1.3 lo dice en la misma wiki.
nadie dijo que esto no podria ser una rama separada, lo que se dice es que se ganan ciertas cosas y se pierden otras... la cosa no es los fuentes y cosas internas que se necesiten hacer... el problema es lo externo (de cara al usuario) que se pierde o que se arruina a nivel rendimiento...
javis, con respecto a iPhone, depende de si la SDL 1.3 esta disponible en iPhone... cosa que desconozco, pero claro que seria grandioso.
Teniendo en cuenta que me dijo un pajarito que el soporte CD en Bennu tampoco ya iba en condiciones, tampoco se pierde nada xD
Antes en distros fisicas se entendia, pero ahora ya nadie distrivuye sus juegos por los amigos en CD, y encima depender de la drive de cd's para escuchar musica...
el soporte CD de bennugd anda perfecto... si tenes algun ejemplo que no funciona, ponelo... por otro lado, la idea del soporte de CD no es sacar solamente un juego con musica en CD, sino tambien poder hacer un reproductor de CD...
como sea, cualquier funcionalidad que se saca siempre da problemas y criticas.
Venturer usaba reproducción de CDs para la música ambiente, aunque nunca se probó.
Por otro lado, es cierto que, existiendo formatos como MP3 u OGG, el formato CD Audio queda desfasado, teniendo los dos primeros la misma calidad o mejor en la décima parte del espacio. Sólo se notaría la diferencia en ordenadores P-III, que les costase más descodificar el MPEG-layer3 que reproducir un CD.
Te digo la verdad, sacrificar el soporte al CD para ganar la aceleración por hardware me parece un sacrificio minimo :P
obviamente el CD no es lo unico que se pierde...
a ver si recapitulamos entonces :)
se perderia el CD y la compatibilidad con algunos dispositivos, no? Algo mas?
usar sdl 1.3 pero con la capa de 1.2
;D
Quote from: JaViS on July 19, 2011, 01:21:58 AM
a ver si recapitulamos entonces :)
se perderia el CD y la compatibilidad con algunos dispositivos, no? Algo mas?
leete la wiki del link que puse...
Quote from: l1nk3rn3l on July 19, 2011, 01:57:09 AM
usar sdl 1.3 pero con la capa de 1.2
;D
esa no es una opcion... para eso se usa la 1.2... funcionaria incluso mas lento que la 1.2 nativa... asi dice en la wiki.
SDL1.3 no tiene soporte para rotaciones. Se propuso para las texturas pero al final no salió. Muchas plataformas por debajo ya usan OpenGL(ES) o similares pero para esa clase de cosas lo mejor es usar opengl directamente parael blitter o parchear SDL.
En cuanto al soporte: mi rama ya sólo usa las funciones de compatibilidad para el set_mode, me gustaría mejorarlo pero no encuentro el momento. Así que ya está escrito.
Por lo que estoy viendo lo mejor es evitar la capa de compatibilidad SDL1.3<->SDL1.2 SIEMPRE. Parece que algunos de los bugs que tienen mis ports a iOS y Android vienen de ahí.
A mucha gente le están dando problemas.
en la wiki desaconsejan usar la capa de compatibilidad...
Ahora tienen un buildbot para SDL 1.3:
http://forums.libsdl.org/viewtopic.php?t=7518
http://buildbot.libsdl.org/waterfall
SDL1.3 se llama ahora SDL2 y se han cambiado las rutas de forma que se pueda instalar en paralelo con la SDL original.
Se busca así facilitar el trabajo a la gente para que SDL2 pueda entrar en los repositorios oficiales de las distros linux y más gente pueda utilizarla de forma sencilla. Además Sam ha vuelto al proyecto y está bastante activo.
Además se ha lanzado una versión nueva de SDL1.2 con fallos arreglados y soporte para versiones modernas de los sistemas operativos.
eso es muy buena noticia joseba.
gracias.
Oh, sí!!
Sólo por manteneros informados, ya que suele estar por la lista de SDL:
El ABI de SDL2 se considera congelado (http://lists.libsdl.org/pipermail/sdl-libsdl.org/2013-March/087261.html) desde hará cosa de una semana. Esto significa que las funcionalidades que ya existan no se van a cambiar hasta la futura SDL3 y que el código que se compile contra la versión actual no dejará de funcionar al actualizar las librerías a versiones futuras.
Eso NO significa que no se vayan a añadir características nuevas antes de la release oficial.
Lo han hecho así porque, según creo, el SDK de Steam ahora se basa en SDL2 para Linux/Mac.
Como comentaba en otro hilo, la versión HG ahora incluye soporte para joysticks en Android a partir de un parche que inicialmente escribí yo (y que alguien amplió y mejoró) y parece que van a incluír oficialmente mi API para sensores. Aunque todavía no está añadido en el código, parece que hay consenso en la lista en torno a que es una buena idea tenerlo y Sam Lantinga (fundador y ppal desarrollador de SDL) ha dicho que está interesado. Estoy particularmente orgulloso de este par de parches dado que me han llevado bastante trabajo y he aprendido tb bastante escribiéndolos :)
[Edito] Enlace al anuncion de Steam en el que se avisa del uso del ABI final de SDL2:
http://steamcommunity.com/groups/SteamClientBeta/announcements/detail/1657595249086333287
felicitaciones josebita!
entonces estas diciendo que ya se puede meter (y que ya es hora) la SDL2 a bennugd definitiva y oficialmente?
Quote from: SplinterGU on March 22, 2013, 09:10:51 PM
felicitaciones josebita!
entonces estas diciendo que ya se puede meter (y que ya es hora) la SDL2 a bennugd definitiva y oficialmente?
Algo así, sí.
Lo que significa es que para la funcionalidad que ya existe sólo se van a corregir bugs y no van a cambiar comportamiento. Vamos, que si ahora compilas bennu para windows contra SDL2, dentro de un año podrás cambiar las .dll con las que haya entonces y el ejecutable seguirá funcionando.
Y yo diría que en escritorio es bastante estable. Piensa que muchos de los juegos de steam que están saliendo para Linux usan SDL2.
Enhorabuena Joseba! Y qué buena noticia la verdad para el resto también! ;D
Felicidades Josebita, meter la cabeza en algo así y que se te reconozca y acepte el trabajo no es cosa fácil, disfrutalo que te lo mereces.
josebita es de lo mejor que tenemos por aqui, nos hace orgullosos ;D
Felicidades, Josebita, por ese pequeño pero gran aporte para el mundo SDL.
Como poco te mereces un karma. El jamón virtual ya va por correo (mientras no lo intercepte futu o geca, te debería llegar entero :D)
Bueno, pues SDL 2 ha sido lanzado hoy.
Podeis descargarlo aquí:
http://www.libsdl.org/
Estoy leyendo la información que han puesto sobre actualización de SDL 1.2 a 2.0 (http://wiki.libsdl.org/moin.fcg/MigrationGuide) y hay un punto que, creo, es muy interesante:
* El API de renderizado basicamente elimina la necesidad de todo el código de escalado por software en BennuGD. Y, si es posible, escala los gráficos usando la GPU.
Hay un montón de cambios muy interesantes más, pero ese creo que ayudará mucho con los juegos que usen scale_resolution.
sin dudas...
es hora de migrar.
hay rotaciones?
Quote from: SplinterGU on August 13, 2013, 02:08:36 PM
hay rotaciones?
Pues yo diría que sí:
http://wiki.libsdl.org/moin.fcg/SDL_RenderCopyEx?highlight=%28%5CbCategoryRender%5Cb%29%7C%28CategoryEnum%29%7C%28CategoryStruct%29 (http://wiki.libsdl.org/moin.fcg/SDL_RenderCopyEx?highlight=%28%5CbCategoryRender%5Cb%29%7C%28CategoryEnum%29%7C%28CategoryStruct%29)
Habría que cambiar algo la forma de funcionar del blitter, pero aquí tienes una guía muy interesante de cómo funciona el nuevo sistema de vídeo y hay cosas que son directamente aplicables a Bennu, creo.
Si usamos el API de renderizado, puede que incluso consigamos renderizado acelerado por GPU "gratis" (seguro que tiene sus pegas, claro).
la idea que tengo es tirar el blitter y pasar directamente a SDL 2.0, con sprites controlados por la SDL, y dejar de hacer el blitter por software, tengo que ver si no me quita cosas, como renderizado sobre mapas, y demas.
esto implica un cambio grande, y no se si ya deberia ser mas bien una version 2.0 de bennugd.
pues mucho animo !! :D
La verdad que sería genial, ¡sinceramente espero que se pueda hacer!
Quote from: SplinterGU on August 13, 2013, 03:06:48 PM
la idea que tengo es tirar el blitter y pasar directamente a SDL 2.0, con sprites controlados por la SDL, y dejar de hacer el blitter por software, tengo que ver si no me quita cosas, como renderizado sobre mapas, y demas.
esto implica un cambio grande, y no se si ya deberia ser mas bien una version 2.0 de bennugd.
Creo que esa es la mejor opción. SDL primero intenta crear renderizadores por hardware (OpenGL, OpenGL ES, DirectX...) y, si no lo consigue, tiene su propio renderizador por software.
Lo suyo sería que a cada proceso, en lugar de asignársele un GRAPH * se le asignara una SDL_Texture* (representación en la RAM de la tarjeta gráfica del bitmap) y trabajar con el renderer de SDL y las texturas. Y lo que ahora es el blitter sólo se encargaría de decirle a SDL que pinte las texturas por orden de Z.
Incluso puede que los dirty rectangles ya ni hagan falta.
Sobre lo de renderizar las cosas a una textura, en ppio. debería poder hacerlo con cosas como SDL_SetRenderTarget (http://wiki.libsdl.org/moin.fcg/SDL_SetRenderTarget?highlight=%28%5CbCategoryRender%5Cb%29%7C%28CategoryEnum%29%7C%28CategoryStruct%29)
Es más (y es sólo mi opinión) yo mataría incluso el soporte para las distintas densidades de color. Hace mucho que no veo juegos que anden jugando con la paleta y la gente -creo- sólo usa los 16bpp cuando el juego es muy pesado para 32bpp por software o por compatibilidad con Fenix. Seguro que quitarlo te reducirá mucho la complejidad del código y dudo que afecte realmente a nadie.
PD: Cuando vayas a echarle un ojo a migrar a SDL2, es mejor que no mires mi código. Ahora mismo está escrito de forma que el número de cambios respecto del BennuGD oficial sean mínimos, pero no es la mejor forma, ni mucho menos, de hacer la inicialización gráfica.
WOW q interesante :D
Creo q en otro hilo se comento la idea de romper con el pasado xDD Splinter .. si tienes que hacer cambios gordos, incluso en el lenguaje de Bennu .. que no te dé miedo xDD Hazlo xD
Quote from: josebita on August 13, 2013, 06:36:02 PM
Quote from: SplinterGU on August 13, 2013, 03:06:48 PM
la idea que tengo es tirar el blitter y pasar directamente a SDL 2.0, con sprites controlados por la SDL, y dejar de hacer el blitter por software, tengo que ver si no me quita cosas, como renderizado sobre mapas, y demas.
esto implica un cambio grande, y no se si ya deberia ser mas bien una version 2.0 de bennugd.
Creo que esa es la mejor opción. SDL primero intenta crear renderizadores por hardware (OpenGL, OpenGL ES, DirectX...) y, si no lo consigue, tiene su propio renderizador por software.
Lo suyo sería que a cada proceso, en lugar de asignársele un GRAPH * se le asignara una SDL_Texture* (representación en la RAM de la tarjeta gráfica del bitmap) y trabajar con el renderer de SDL y las texturas. Y lo que ahora es el blitter sólo se encargaría de decirle a SDL que pinte las texturas por orden de Z.
Incluso puede que los dirty rectangles ya ni hagan falta.
Sobre lo de renderizar las cosas a una textura, en ppio. debería poder hacerlo con cosas como SDL_SetRenderTarget (http://wiki.libsdl.org/moin.fcg/SDL_SetRenderTarget?highlight=%28%5CbCategoryRender%5Cb%29%7C%28CategoryEnum%29%7C%28CategoryStruct%29)
Es más (y es sólo mi opinión) yo mataría incluso el soporte para las distintas densidades de color. Hace mucho que no veo juegos que anden jugando con la paleta y la gente -creo- sólo usa los 16bpp cuando el juego es muy pesado para 32bpp por software o por compatibilidad con Fenix. Seguro que quitarlo te reducirá mucho la complejidad del código y dudo que afecte realmente a nadie.
PD: Cuando vayas a echarle un ojo a migrar a SDL2, es mejor que no mires mi código. Ahora mismo está escrito de forma que el número de cambios respecto del BennuGD oficial sean mínimos, spero no es la mejor forma, ni mucho menos, de hacer la inicialización gráfica.
exacto, esa es la idea, usar texturas sdl en lugar de graph.
si, luego de comentar, vi lo del target para dibujar sobre otra textura...
lo de la profundidad no quiero limitar, sera lo que permita sdl
Ojalá lo cojas con ganas y te duren hasta terminarlo Splinter, mucho animo, menudo notición para bennu, la mejor noticia que podría leer hoy. :)
mas que noticion esto es un deseo...
veremos de donde saco tiempo... estoy en demasiadas cosas y realmente no doy abasto.
Del deseo a la realidad solo hay un paso entre medio jeje, si el cuerpo te pide marcha, dasela!
Parece que hay movimiento...: http://www.phoronix.com/scan.php?page=news_item&px=MTQzNjU
He estado buscando el video de dragon ball en el que todos dan su energía vital a Goku pero he sido incapaz, aquí quedaría muy bien, pero bueno, ahí lo dejo.
Mucho ánimo :)
Quote from: laghengar on August 14, 2013, 07:57:57 PM
He estado buscando el video de dragon ball en el que todos dan su energía vital a Goku pero he sido incapaz, aquí quedaría muy bien, pero bueno, ahí lo dejo.
Mucho ánimo :)
http://youtu.be/LBs8jJ-020k :D
Quote from: josebita on August 14, 2013, 08:21:28 PM
Quote from: laghengar on August 14, 2013, 07:57:57 PM
He estado buscando el video de dragon ball en el que todos dan su energía vital a Goku pero he sido incapaz, aquí quedaría muy bien, pero bueno, ahí lo dejo.
Mucho ánimo :)
http://youtu.be/LBs8jJ-020k :D
http://www.youtube.com/watch?v=Jk8IqZokwJI (http://www.youtube.com/watch?v=Jk8IqZokwJI)
Dos mejor que uno XD
Bueno, dejando a Goku a lo suyo, vuelvo con el tema.
Lo que veis abajo es la gráfica de rendimiento de cierto juego (http://forum.bennugd.org/index.php?topic=3231.0) funcionando en mi iPod Touch 4G:
(http://forum.bennugd.org/index.php?action=dlattach;topic=2510.0;attach=3047)
Como podeis ver, el juego funciona a 10fps. En realidad debería ir a 30 y lo cierto es que no es jugable.
Bueno, pues debajo teneis el mismo DCB utilizando el API de renderizado de SDL 2 sólo para hacer el escalado (la labor que normalmente haría scale_resolution):
(http://forum.bennugd.org/index.php?action=dlattach;topic=2510.0;attach=3049)
Como veis, los FPS se han doblado dado que ahora el escalado se hace por GPU en el iPod, y el juego es jugable. También es cierto que he aplicado un escalado con algo de suavizado, que creo que BennuGD no lo hace por defecto con scale_resolution.
Mi código es, de momento, poco más que un apaño rápido y no es genérico aún. De hecho, tengo deshabilitados los dirty rectangles. Los voy a tratar de habilitar ahora, antes de ir a dormir, para ver cómo mejora el rendimiento, pero esto promete.
Ya os cuento.
[Edito] Los dirty rectangles no parecen ayudar demasiado (o no los estoy implementando bien) pero quitando el filtrado del escalado, el rendimiento sube hasta 25fps, con picos en 50fps.
Como ventaja adicional, el código de la función que hace el set_mode (gr_set_mode) se simplifica bastante :)
[Edito 2] En un iPad 2 a resolución nativa (768x1024) funciona a 60fps sin problema, así que imagino que en dispositivos mejores irá todavía mejor.
Pues si es solo una prueba y ya da el doble de rendimiento la cosa pinta muy bien, ultimamente le están dando un empujón a las SDL de la leche.
Oye Joseba mucho animo con esto, que aunque no sea un nuevo blitter, si hace esto que dices ya es la leche.
y sin usar scale_resolution?
el scale_resolution es muy costoso... sin tocar el render, es claro que lo que cuesta es el scale.
la idea es cambiar todos los graph por textures.
pero no se cuando lo hare.
Quote from: SplinterGU on August 15, 2013, 03:21:08 AM
y sin usar scale_resolution?
el scale_resolution es muy costoso... sin tocar el render, es claro que lo que cuesta es el scale.
la idea es cambiar todos los graph por textures.
pero no se cuando lo hare.
Claro, pues eso es lo que digo, que incluso sin tocar el renderer podemos convertir la operación de escalado en algo mucho más eficiente.
No quiero decir con eso que no haga falta tocar el renderer, pero sólo con esto podemos mejorar mucho el rendimiento.
Viene bien para cosas como portar juegos con resoluciones bajas a los 1080p que pide la ouya.
claro, yo cambiare el render, si tu quieres hacer esto como un parche para "mientras tanto...", seria grandioso.
Quote from: SplinterGU on August 15, 2013, 01:40:56 PM
claro, yo cambiare el render, si tu quieres hacer esto como un parche para "mientras tanto...", seria grandioso.
GRANDIOSO!!! :D :D :D :D
joseba, las texturas pueden ser de cualquier tamaño? o ahora hay que hacerlas cuadradas? por ejemplo, 128x128? ( estoy empezando a ver el tema, pero soy tan ansioso que no puedo esperar... ni evitar preguntar... :D )
Quote from: SplinterGU on August 18, 2013, 07:20:50 PM
joseba, las texturas pueden ser de cualquier tamaño? o ahora hay que hacerlas cuadradas? por ejemplo, 128x128? ( estoy empezando a ver el tema, pero soy tan ansioso que no puedo esperar... ni evitar preguntar... :D )
No he visto nada de problemas de tamaño.
De hecho, en el código que tengo (el de las pruebas anteriores) las creo así:
if(enable_16bits) {
format = SDL_PIXELFORMAT_RGB565;
} else if (enable_32bits) {
format = SDL_PIXELFORMAT_RGBA8888;
}
texture = SDL_CreateTexture(renderer,
format,
SDL_TEXTUREACCESS_STREAMING,
width, height);Te voy a subir una copia del código, para que puedas echar un ojo a cómo funciona SDL2 contra SDL1.2 pero úsalo sólo como base, que yo he hecho algunos cambios medio grandes.
En cuanto esté pongo el enlace.
https://www.dropbox.com/s/f4kjpiqrwvz4jno/bennugd_SDL2_src.tar.bz2
gracias!
Quote from: SplinterGU on August 18, 2013, 10:13:00 PM
gracias!
Ese código sólo tiene soporte para SDL2. Algunas cosas que creo que merece la pena que revises:
* mod_wm: Es increíble la cantidad de código que nos ahorra SDL. Y encima, con hacerlo se soportan plataformas que hasta ahora no lo estaban.
* libvideo/g_video.c: Échale un ojo a gr_set_mode(). Ahora mismo no está soportado hacer varias llamadas a set_mode cambiando entre full_screen/ventana porque no me hace falta en mi código, pero sí hacer varias llamadas a set_mode con distintas resoluciones cuando se mantiene el scale_resolucion.
Creo que te harás una idea de lo simple que es establecer el modo gráfico y hacer el escalado por hardware.
Además, renderizar a textura nos debería ayudar con los temas de BGR de OS X e iOS e incluso nos abre la puerta a usar formatos tipo YUV, que seguro que es útil para las librerías de reproducción de vídeos.
* librender/g_screen.c: He cambiado la función gr_unlock_screen() para hacer el pintado del frame renderizado a la textura y después a pantalla.
Además, el código tal y como viene permite hacer cosas como poner set_mode(640, 0) y el modo gráfico se pondrá con 640px de ancho y resolución nativa de alto.
No se soporta rotación, pero debería ser muy fácil de implementar con las texturas, copiando una a otra (a través de SDL) girada, si hiciera falta. De todas formas lo mejor es que sea la plataforma nativa quien lo haga, en caso de ser necesario.
* libkey: Han cambiado algunas cosas, aunque la idea global es la misma. Parece que funciona bien pero hace falta un testeo profundo.
* mod_cd: SDL2 no soporta la reproducción de audio desde CD, pero creo que eso ya no lo usa nadie, en realidad. Habría que documentar una rotura de compatibilidad hacia atrás en Bennu, pero no creo que fuera muy grave.
Cosas que he borrado del código:
* Los dirty rectangles.
* Soporte para cualquier tipo de escalado tal y como se hacía antes (tanto la versión de Bennu de scale_resolution como scale_mode). He dejado las constantes por compatibilidad, pero no hacen nada.
He quitado estas cosas un poco a la ligera aunque tengo mis razones: como dije, la implementación de los dirty rects no aportaba ganancia de rendimiento sensible y será aún más irrelevante cuando haya renderizado por GPU y los escalados anteriores carecen de sentido tal desde mi punto de vista.
A la hora de implementarlo oficialmente en Bennu habrá que pensarlo con un poco más de cariño y pensar en todos los usos posibles.
De todas formas, quizás sea el momento de pensar romper en parte la compatibilidad hacia atrás (llámalo Bennu 2.0, si quieres) para estas cositas a costa de las ganancias que aporta la nueva versión de SDL. Por lo que veo, actualizar a SDL2 implica tener menos código en Bennu pero que funciona mejor.
ya tenia en cuenta esas cosas.
ademas, tengo que pensarlo en ventanas, agregar soporte multiples ventanas de render, y elegir incluso en cual se dibuja tal o cual proceso... seguramente lo manejare como regions.
lo que me preocupa es el tema de las colisiones pixel perfect... no lo pense mucho, desconozco el api de la nueva sdl, pero si tenes alguna idea al respecto, soy todo oido y ojos.
ah, tambien desapareceran algunos modulos/libs y habra otros nuevos... incluso, seguramente redistribuya los existentes. luego pensare en una capa de compatibilidad (hasta donde sea posible) para crear modulos dummy que llamen a los modulos reales.
edit: por favor, no tomen esto como noticia oficial anunciada con bombos y platillos... es solo un comentario informal.
Quote from: SplinterGU on August 18, 2013, 11:28:34 PM
ademas, tengo que pensarlo en ventanas, agregar soporte multiples ventanas de render, y elegir incluso en cual se dibuja tal o cual proceso... seguramente lo manejare como regions.
Tiene sentido, sí, siempre que sea similar a regiones y no mediante regiones :)
Quote from: SplinterGU on August 18, 2013, 11:28:34 PMlo que me preocupa es el tema de las colisiones pixel perfect... no lo pense mucho, desconozco el api de la nueva sdl, pero si tenes alguna idea al respecto, soy todo oido y ojos.
Lo he pensado. Se puede convertir una textura en pixmap, pero es lento. Para las colisiones pixel-perfect habría que hacerlo y creo que es importante tenerlo, pero en muchas aplicaciones quizás bastara (desde el punto de vista del usuario) con collision boxes/círculos/elipses, tal y como lo tienes implementado ahora.
No sólo eso: otras cosas como map_get_pixel se volverían lentas... Es algo que me parece feo. Quizás sería práctico dejar al usuario elegir si el pixmap que carga va como GRAPH o como textura, en función del uso que le vaya a dar. El usuario haría algo tipo:
png_load("mi.png", GRAPH_PIXMAP); // el segundo parámetro sería opcional y por defecto indicaría textura
Y bennu sabría que debe cargar el PNG en RAM.
Y realmente éstos no ralentizaría el renderizado en juegos tipo plataformas, donde el mapa de durezas no suele ser el mismo mapa sobre el que el prota camina.
lo de regiones, estoy pensando al igual que usamos regiones ahora, tanto para dibujar como para scroll y demas.
si quito el render por software no vamos a poder hacer el collision pixel perfect desde RAM, por otra parte me parecio leer que todo el manejo incluso de pixel de las texturas en sdl2 estaba optimizado y se podia hacer desde la gpu.
en todo caso, si se hace manejo de pixel en los mapas, seran basicas, no habra escalado, ni rotaciones por software, la idea es quitar el blitter definitivamente.
en esto tambien quedaran atras algunas viejas plataformas, asi esta dicho en el link que has puesto de sdl2.
en fin, tengo que pensar muchas cosas.
Yo creo que ante este punto de inflexión es un buen momento para plantearse adoptar chipMunk como motor de colision poligonal por defecto en el lenguaje.
Es rápido y funciona casi a pixel perfect ya que todo lo que se puede vectorizar se puede calcular la colisión.
De verdad que yo me iría olvidando ya del pixel perfect, el camino no es otro que avanzar hacia la aceleración por GPU, y si eso implica perder el colisión clásico a nivel de pixel.. pues que mas da=?
Lado A de la balanza:
- colisión a pixel perfect. LENTISIMA.
- renderizado por software sin ningún tipo de aceleración.
- posibilidad de map_put_pixel etc etc..
- juegos pixelados, lentos etc..
Lado B de la balanza:
- colisión poligonal [rápida].
- aceleración por hardware mediante GPU.
- no posibilidad de map_put_pixel etc etc.. [que seguro que se puede de algúna manera].
. juegos con gráficos suavizados, juegos rápidos.
Vaya que por mi le pueden dar morcilla al map_put_pixel XD..
Quote from: Erkosone on August 19, 2013, 01:51:09 PM
Yo creo que ante este punto de inflexión es un buen momento para plantearse adoptar chipMunk como motor de colision poligonal por defecto en el lenguaje.
Es rápido y funciona casi a pixel perfect ya que todo lo que se puede vectorizar se puede calcular la colisión.
De verdad que yo me iría olvidando ya del pixel perfect, el camino no es otro que avanzar hacia la aceleración por GPU, y si eso implica perder el colisión clásico a nivel de pixel.. pues que mas da=?
Lado A de la balanza:
- colisión a pixel perfect. LENTISIMA.
- renderizado por software sin ningún tipo de aceleración.
- posibilidad de map_put_pixel etc etc..
- juegos pixelados, lentos etc..
Lado B de la balanza:
- colisión poligonal [rápida].
- aceleración por hardware mediante GPU.
- no posibilidad de map_put_pixel etc etc.. [que seguro que se puede de algúna manera].
. juegos con gráficos suavizados, juegos rápidos.
Vaya que por mi le pueden dar morcilla al map_put_pixel XD..
No digo que no se vaya a poder hacer map_Get_pixel o map_put_pixel. De hecho, se puede sin problemas:
SDL_RenderDrawPoint (http://wiki.libsdl.org/SDL_RenderDrawPoint?highlight=%28%5CbCategoryRender%5Cb%29%7C%28CategoryEnum%29%7C%28CategoryStruct%29)
SDL_RenderReadPixels (http://wiki.libsdl.org/SDL_RenderReadPixels?highlight=%28%5CbCategoryRender%5Cb%29%7C%28CategoryEnum%29%7C%28CategoryStruct%29)
Lo que estamos comentando es que eso, si se hace el renderer por hardware, va a ser una operación más costosa en términos de tiempo que ahora. Yo planteo que quizás esto no sea un problema tan grande dado que para la mayor parte de usos puede ser suficiente utilizar cajas de colisión rectangulares o elípticas. Incluso para mayor precisión se podrían utilizar múltiples cajas para un mismo proceso.
Pero creo que ir directamente a hacer todas las colisiones con un motor de físicas me parece exagerado. Habrá muchos juegos donde no interese tener físicas y tener el motor por detrás no haría más que perder ciclos de CPU y batería.
Dicho esto, creo que no es mala idea -en absoluto- integrar un motor de físicas en el Bennu oficial. Algo parecido a la mod_chipmunk pero bien integrado, con locales y tal (me vais a matar. Alguien hizo una capa de abstracción en Bennu que hacía justo esto ¿cómo se llamaba?).
la hizo prg y yo la simplifiqué con la physicsMotion todavía mas, el trabajo de prg es muy bueno, funciona realmente bien.
Quote from: Erkosone on August 19, 2013, 04:24:57 PM
la hizo prg y yo la simplifiqué con la physicsMotion todavía mas, el trabajo de prg es muy bueno, funciona realmente bien.
Gracias ;)
Pues algo así pero integrado directamente en BennuGD sería brutal.
si, fisicas es un tema que se necesita.
pero vayamos por partes, bennugd es modular, y la fisica ira en un modulo, asi que puede esperar.
de momento, creo que collisiones tipo box o circle seran las opciones para collision.
sin dudas la fisica se necesita, pero primero el render.
Totalmente de acuerdo con Splinter.
A veces los motores de fisica solamente complican las cosas :
http://www.learn-cocos2d.com/2013/08/physics-engine-platformer-terrible-idea/ (http://www.learn-cocos2d.com/2013/08/physics-engine-platformer-terrible-idea/)
Quote from: SplinterGU on August 19, 2013, 08:19:16 PM
si, fisicas es un tema que se necesita.
pero vayamos por partes, bennugd es modular, y la fisica ira en un modulo, asi que puede esperar.
de momento, creo que collisiones tipo box o circle seran las opciones para collision.
sin dudas la fisica se necesita, pero primero el render.
Completamente de acuerdo, Splinter.
¿Sería posible hacer que un cuerpo pudiera tener más de una caja de colisión?
Algo como lo que explican al final de este artículo, vamos:
http://www.genbetadev.com/programacion-de-videojuegos/teoria-de-colisiones-2d-conceptos-basicos
Bueno .. esta es una noticia que queria poner aparte .. pero ya que aqui se esta hablando un poco del futuro de bennu .. pos os pongo esto ... para futuros ports a consolas nuevas http://www.meristation.com/xbox-one/noticias/la-autopublicacion-en-xbox-one-sin-cuotas-sin-certificacion/45366/1892291 (http://www.meristation.com/xbox-one/noticias/la-autopublicacion-en-xbox-one-sin-cuotas-sin-certificacion/45366/1892291)
He puesto algo de información sobre todo este proceso en mi blog:
http://bennugd-mobile.blogspot.com.es/2013/08/wip-games-gpu-scaling-and-bennugd-2.html
la xbox one viene a ser la 720? si es asi, de momento, pues bennugd no vera la luz en la consola de mi parte, por temas de que no me mola que ms joda con mi privacidad.
joseba, descompacte el paquete, pero me da el siguiente error (o warning)
bzip2: (stdin): trailing garbage after EOF ignored
veo tambien que tu version es monolitica... no es la oficial.
lo vere.
gracias, confirmame si ese error lo ignoro o tienes que pasarme otra vez el paquete.
saludos.
Quote from: SplinterGU on August 20, 2013, 09:17:47 PM
joseba, descompacte el paquete, pero me da el siguiente error (o warning)
bzip2: (stdin): trailing garbage after EOF ignored
veo tambien que tu version es monolitica... no es la oficial.
lo vere.
gracias, confirmame si ese error lo ignoro o tienes que pasarme otra vez el paquete.
saludos.
El error lo puedes ignorar.
Y sobre la versión, es la mía sí, pero la parte interesante sobre adaptación a SDL 2 creo que funcionaría igual con la oficial. Eso sí, sólo incluye fuentes, no scripts de compilación.
Llevo tiempo intentando cambiar a la oficial, pero nunca encuentro la ocasión :)
veo que en realidad no quitaste las dirty, simplemente las quitaste en el dump de pantalla, pero el dump al mapa interno de bennugd (pantalla) se sigue haciendo, evidentemente te mal entendi.
como sea, voy a revisar y tomar lo que pueda de tu version, grandioso!
Quote from: SplinterGU on August 20, 2013, 09:55:36 PM
veo que en realidad no quitaste las dirty, simplemente las quitaste en el dump de pantalla, pero el dump al mapa interno de bennugd (pantalla) se sigue haciendo, evidentemente te mal entendi.
como sea, voy a revisar y tomar lo que pueda de tu version, grandioso!
Sí, bueno. Lo hice un poco corriendo.
Lo quité de la representación a pantalla, pero habrá que ver si en el código con texturas tiene un efecto sensible sobre el rendimiento.
Si a todo esto le pudiéramos añadir además del motor de física, una librería de red oficial (¿basada en SDL_net?) y soporte para 64 bits, sería la releche...¡ay, suspiro!
La PlayNET funciona realmente bien, con el extra de varios tipos de replicas es una librería de red realmente interesante.
Yo creo que para juegos no hace falta nada mas, con la playnet y curl tienes para hacer practicamente todo.
Quote from: Erkosone on August 21, 2013, 03:39:56 PM
La PlayNET funciona realmente bien, con el extra de varios tipos de replicas es una librería de red realmente interesante.
Yo creo que para juegos no hace falta nada mas, con la playnet y curl tienes para hacer practicamente todo.
Si .. la cosa es q esas librerias de red sean oficiales de bennuGD .. porque yo en linux tengo muchos problemas para usar algo de esto xD sobre todo cada vez q cambio de distribucion xDD ... Ahora estoy con Mint ... pero creo q me voy a pasar a Elementary OS xD
Vaya, siempre que me voy de vacaciones aparece un tema interesante o ¡GRANDIOSO! (en serio, necesitamos un meme de Splinter gritando esa palabra :D).
Llamadme anticuado, pero creo que sería mala idea romper con los modos de 8bits, o al menos, con las paletas. Más que nada por los diversos efectos gráficos que se pueden crear (duplicados de sprites con otros colores, efectos de iluminación modificando la paleta como atardeceres o luz de luna, roll_palette...). Además, siento tan mal grafista, que sólo uso un máximo de 8 colores por sprite (^^U), los 16 y 32 bits sólo los uso para los efectos de transparecias, bits aditivos y sustractivos, etc.
Tampoco creo que sea buena idea perder las funciones map_get_pixel o map_put_pixel: ya es con el buffer de sonido, que no existen, y las echo de menos. Siempre se van a necesitar funciones de acceso a los mapas, para modificarlos en tiempo real, o para generarlos. Que sean más lentos de lo que son ya... bastantes problemas estamos teniendo más de uno con las funciones PUT en las consolas portátiles.
Aparte de eso, el tener aceleración HW de serie, soporte 64bits (si se rompe con todo, sería un buen momento para añadirlo), y opcionalmente motor de físicas y compatibilidad con OpenGL o algún motor 3D, pues estaría genial.
Es más, no sé si sería factible, pero teniendo Bennu 1.0 RC xxx, tener un Bennu 2.0 para máquinas modernas y poder usar indistintamente uno u otro según lo que se necesite (los problemas que planteo atrás mas la compatibilidad con otras máquinas) sería lo suyo... siempre que se consiga arreglar el bug del blitter de la 1.0 y se pueda seguir actualizando ^^U
En fin, yo también doy mi apoyo al proyecto, y si supiese más sobre SDL y el código de Bennu, aportaría mi granito de arena :)
cuando saque tiempo...