Avances, Diario de...

[SplinterGU]

claro no has pillado que ahora bennu se pueden meter dlls "normales" sin necesidad de crear un modulo externo.

[Drumpi]

Si, eso lo he pillado: ahora usar openGL tal cual, pero antes de ese cambio, tambien se podía usar openGl ¿o no? :P

[SplinterGU]

a ver, que se pueda no significaba que estaba hecho... hay un modulo experimental de Sandman, pero cuando yo dije "se puede" lo decia en sentido potencial... o sea, hay que hacer el modulo, pero se puede hacer de forma de meter luego la pieza y quitando el otro render facilmente...

alguno mas habia entendido, tambien, mal esto?

[DCelso]

Yo,:(:(, y sigo sin entenderlo. Lo leo y releo, pero no capto el mensaje.
A ver, cuando añadiste plugins a fenix, ya se podía enganchar con cualquier librería externa, simplemente programando un plugin para ello.
Aqui en bennu, has separado en módulos el core de fenix, siguiendo algun sistema parecido para enganchar con las dll de los modulos, pero no es el mismo sistema como con los plugins.
Antes había que crear en c o c++ una especie de wrapper para poder encapsular las librerías dinámicas a usar.

Nos estás diciendo que a partir de ahora no hace falta hacer eso y que directamente podemos enganchar de alguna forma nuestro código con las dlls dinámicas son solo tener sus "headers" mas no menos¿?.

[Drumpi]

Verás: Fenix usaba SDL para representar gráficos, así que cuando creabas una libreria (dll) con otro motor gráfico, al final, tenías que recurrir de nuevo a SDL para integrarlo.

Splinter, al separarlos en módulos, dejó de usar SDL, y para representar gráficos podías usar los módulos que ha hecho él (creo que van por software, ¿no?) o crear la tuya propia con openGL, DX o la que te diera la gana (es decir, podías hacer cosas como cambiar el angle, el size, trabajar con paletas y demás usando aceleracion hardware con.. directX, por ejemplo. O como han hecho con la bennu3D, que es otra librería gráfica, pero 3d)

El cambio actual permite que, sin crearte ninguna librería que usase las librerías gráficas, con símplemente el core, puedas hacer llamadas directamente a dichas librerías. Es decir, te quita una capa en medio que tenías que diseñar.
Antes: creabas una librería con la funcion dibuja_cuadrado, en la que se llamaba a SDL_draw_box.
Ahora: llamas directamente a SDL_draw_box.

[SplinterGU]

Yo,:(:(, y sigo sin entenderlo. Lo leo y releo, pero no capto el mensaje.
A ver, cuando añadiste plugins a fenix, ya se podía enganchar con cualquier librería externa, simplemente programando un plugin para ello.
Aqui en bennu, has separado en módulos el core de fenix, siguiendo algun sistema parecido para enganchar con las dll de los modulos, pero no es el mismo sistema como con los plugins.
Antes había que crear en c o c++ una especie de wrapper para poder encapsular las librerías dinámicas a usar.

Nos estás diciendo que a partir de ahora no hace falta hacer eso y que directamente podemos enganchar de alguna forma nuestro código con las dlls dinámicas son solo tener sus "headers" mas no menos¿?.

En Fenix no podias llamar a cualquier dll, solo a dlls fenix...

Verás: Fenix usaba SDL para representar gráficos, así que cuando creabas una libreria (dll) con otro motor gráfico, al final, tenías que recurrir de nuevo a SDL para integrarlo.

Splinter, al separarlos en módulos, dejó de usar SDL, y para representar gráficos podías usar los módulos que ha hecho él (creo que van por software, ¿no?) o crear la tuya propia con openGL, DX o la que te diera la gana (es decir, podías hacer cosas como cambiar el angle, el size, trabajar con paletas y demás usando aceleracion hardware con.. directX, por ejemplo. O como han hecho con la bennu3D, que es otra librería gráfica, pero 3d)

El cambio actual permite que, sin crearte ninguna librería que usase las librerías gráficas, con símplemente el core, puedas hacer llamadas directamente a dichas librerías. Es decir, te quita una capa en medio que tenías que diseñar.
Antes: creabas una librería con la funcion dibuja_cuadrado, en la que se llamaba a SDL_draw_box.
Ahora: llamas directamente a SDL_draw_box.

No es tan directo, pero bueno, no se necesita crear una dll para poder usarlo, o sea, los programadores que no tienen conocimiento de C podran hacer sus propias llamadas a dlls normales sin necesidad de depender de alguien que sepa C para que le arme una dll, incluso a uno que sepa C, para simplificarle trabajo.

Mas adelante el soporte podra ser mejor y mas intuitivo, por ahora hay que llamar a una serie de funciones.

Y ya tenia una version nueva, con bugs corregidos, pero bueno, tendre que hacer esas correcciones nuevamente cuando pueda dedicarle un tiempo a rearmar el entorno.

[blostec]

claro no has pillado que ahora bennu se pueden meter dlls "normales" sin necesidad de crear un modulo externo.

Simplemente genial!  :)

[DCelso]

Yo,:(:(, y sigo sin entenderlo. Lo leo y releo, pero no capto el mensaje.
A ver, cuando añadiste plugins a fenix, ya se podía enganchar con cualquier librería externa, simplemente programando un plugin para ello.
Aqui en bennu, has separado en módulos el core de fenix, siguiendo algun sistema parecido para enganchar con las dll de los modulos, pero no es el mismo sistema como con los plugins.
Antes había que crear en c o c++ una especie de wrapper para poder encapsular las librerías dinámicas a usar.

Nos estás diciendo que a partir de ahora no hace falta hacer eso y que directamente podemos enganchar de alguna forma nuestro código con las dlls dinámicas son solo tener sus "headers" mas no menos¿?.

En Fenix no podias llamar a cualquier dll, solo a dlls fenix...

Verás: Fenix usaba SDL para representar gráficos, así que cuando creabas una libreria (dll) con otro motor gráfico, al final, tenías que recurrir de nuevo a SDL para integrarlo.

Splinter, al separarlos en módulos, dejó de usar SDL, y para representar gráficos podías usar los módulos que ha hecho él (creo que van por software, ¿no?) o crear la tuya propia con openGL, DX o la que te diera la gana (es decir, podías hacer cosas como cambiar el angle, el size, trabajar con paletas y demás usando aceleracion hardware con.. directX, por ejemplo. O como han hecho con la bennu3D, que es otra librería gráfica, pero 3d)

El cambio actual permite que, sin crearte ninguna librería que usase las librerías gráficas, con símplemente el core, puedas hacer llamadas directamente a dichas librerías. Es decir, te quita una capa en medio que tenías que diseñar.
Antes: creabas una librería con la funcion dibuja_cuadrado, en la que se llamaba a SDL_draw_box.
Ahora: llamas directamente a SDL_draw_box.

No es tan directo, pero bueno, no se necesita crear una dll para poder usarlo, o sea, los programadores que no tienen conocimiento de C podran hacer sus propias llamadas a dlls normales sin necesidad de depender de alguien que sepa C para que le arme una dll, incluso a uno que sepa C, para simplificarle trabajo.

Mas adelante el soporte podra ser mejor y mas intuitivo, por ahora hay que llamar a una serie de funciones.

Y ya tenia una version nueva, con bugs corregidos, pero bueno, tendre que hacer esas correcciones nuevamente cuando pueda dedicarle un tiempo a rearmar el entorno.

A eso me refería yo, a eso mismo, no me expliqué bien, entonces la idea que tenía era la correcta, es que con tanto alboroto me pusisteis en duda.
Yo quise decir que en fenix se podía enganchar con cualquier dll, pero no directamente, sino a través de una "dll fenix" que hiciera de wrapper (envoltorio, encapsulador, puente) entre fenix y la dll. Esta había que programarla en C.
Y lo que comentas que tendrá bennu es una forma de conectar "directamente" con la dll externa conociendo sus funciones y estructuras lo que se denomina cabecera "header". Esto de directamente me refiero a través de código Bennu, independientemente de que tengas que usar alguna función adicional para activar la dll tipo "dllimport" o "LoadLibrary" de c.

[SplinterGU]

"tendrá", no... "tiene", es el "mod_ffi" que subi hace unas semanas con un sample...

[syous]

para cuando unas tcpsock o fsock para bennu  ???

[SplinterGU]

Debo anunciar gratamente que luego de muchisimos intentos y distros probadas, y tras tomarme una buena ducha fria y una pastillita para la presión he logrado compilar bennu en linux... donde otros fallaron la fuente fue la solucion... no me quedo otra opcion (gratamente) que instalar un debian puro, ahi todo fue fluido... y la verdad que va muy lindo... supongo que otras distro base podran ir tambien bien... pero bueno, ubuntu un fracaso, ultimas distros de otros linux que antes me funcionaban ahora son un desastre... no se que pasara en el mundo linux, pero bueno, la buena noticia es que el tema se soluciono...

[SplinterGU]

En el site hay nueva version binaria para linux, esto es lo ultimo que recupere del SVN, tiene todos los ultimos cambios informados, me faltan algunos que yo habia corregido y que ahora tengo que recordar.

La novedad es que ahora linux posee un instalador (hay que descomprimir el paquete principal, no lo que esta dentro de este), es precario, pero cumple su objetivo, se necesita tener permisos de root o superusuario para instalar el paquete, si haces "./install.sh help" muestra una ayuda, pero basicamente es:

./install.sh                instala el producto
./install.sh remove     desinstala el producto

ya no hay que hacer LD_LIBRARY_PATH, ni veran las dlls desperdigadas en el directorio del proyecto.
Para aquellos que no quieran usar el instalador, dentro del paquete hay un archivo bgd.pkg, que es un simple tgz con todos los archivos de bennu.

No se incluyen SDL, ogg, etc... esos hay que instalarlos con la herramienta para tal fin...

NOTA: Acabo de probar que el instalador solo funciona bien en linux 32, en 64 bits no se encuentran luego las dlls... en 64 bits sugiero el metodo manual.

[osk]

Hola! Está bueno!!
Una pregunta: el moddesc no está (ni el function-list.txt). ¿Es por alguna razón?
He visto el script...sólo por curiosidad, ¿por qué la comparación que haces es x$1="xhelp" en vez de $1="help" ? Por otro lado, no sé si sería buena idea dar la opción a la hora de instalar de poder elegir dónde: si no he visto mal, desempaqueta automáticamente en la carpeta donde estés...no sé.
Y una chorrada tocapelotas: ¿qué tal cambiar el nombre del script con algo como "setup" o similar? Lo digo porque un "install remove" es como un poco esquizofrénico...un "setup install" o un "setup remove" estaría más guay, no?

...Y finalmente, ¿por qué no hacer algo similar para Windows también? Hay multitud de programas generadores de instalación open source, no hace falta que os lo diga...por ejemplo http://nsis.sourceforge.net . En verdad yo casi que prefiero no usar instalador, pero reconozco que la mayoría de usuarios estándar lo agradecerán.

Ah, y lo de instalar todas las librerías en una subcarpeta dentro de /usr/lib...¿daría muchos problemas? Manía con el orden y eso...

[josebita]

Genial!, muchas gracias :)

[SplinterGU]

1) El moddesc ni el function list no estan incluidos por razones de publico conocimiento con mi instalacion previa de windows+grub...
2) el hecho de tener "x$1" = "xhelp" y no lo otro, es por el simple motivo de que sino cuando ejecutas sin argumentos el if dara un error de expresion unaria (logicamente)
3) no desempaqueta donde estas, lo hace en el directorio /usr
4) porque no estas "setupeando" nada, sino que estas instalando... setup es mas bien para "seteos", esto no es un seteo es una instalacion
5) preguntar el path ira en alguna proxima version, anuncie que esto es un poco precario y rapido, pero que cumple con su funcion
6) Windows ya tendra su instalador... (conozco el nsis, de hecho lo use varias veces, para armar o para "desarmar" y toquetear instaladores) por ahora el problema de la mayoria es linux... a pesar de que los que usan linux son los pocos... pero bueno... me uni al club...
7) /usr/lib, quizas deberia usar otro, por si se llega a pisar (por ahora no pasa) alguna libreria del sistema que no haya tenido en cuenta, pero eso no deberia pasar, y ademas todos los productos instalan sus libs en dicha carpeta... quizas la solucion sea cambiar los nombres de las libs internas por algo asi como libbgd* o bgdlib*, eso no afectaria en nada, ya que ningun usuario deberia usarlas...