Nuevo proyecto: NGT (Neopontec Gaming Toolkit) 0.1.0

[hectorblanco]

Hola a todos.
Lo comenté hace bastante tiempo, antes de salir la consola, que estaba intentando desarrollar algún tipo de API, encapsulado, llamadlo como querais, de SDL.
Pues bien, después de mucha vagancia, y mucho tiempo, por fin se encuentra en un estado presentable, y aquí os publico casi en primicia (la primicia ha sido pa mi web :P) el pack con el toolkit en C++, y algunos documentos.

La versión actual es la 0.1.0.
Las versiones se contaran de la forma x.y.z, donde 'x' seran versiones importantes, 'y' seran versiones intermedias, y 'z' indicará cambios menores.
'y' siendo par indicará una versión estable, mientras que si es numero impar indicará que se trata de una versión inestable de desarrollo.

Ahora pasemos a dar algunas explicaciones:

- ¿Qué es?:
Es un conjunto de archivos de código en C++, compuestos por clases, algunas funciones sueltas, definiciones y tipos de datos, que en eséncia sirven para facilitar tareas básicas de SDL como son su inicialización o la gestión y dibujado de superfícies y fuentes.
Ofrece funcionalidad multiplataforma. Es decir, un programa/juego desarrollado usando NGT de forma correcta puede funcionar en varios sistemas, y en algunos contando con funcionalidades adaptadas, como es el caso de la GP2X.

- ¿Qué ofrece para la GP2X?:
Por ahora, menos de lo que quisiera, pero en ésta primeriza versión, el toolkit ya gestiona la inicialización de SDL especialmente adaptado para la consola. Modificando un único atributo del toolkit al iniciarlo, éste cambia su modo de funcionamiento entre PC genérico y GP2X. Tambien gestiona la salida del juego para ir al menú principal de la consola.

- ¿Qué es necesario?:
Para compilar, se necesitan las siguientes librerias de SDL: SDL, SDL_image, SDL_mixer, y SDL_ttf. El toolkit las usa ampliamente, extendiendo en parte las funcionalidades de alguna de ellas.
Es un toolkit orientado a objetos, por lo que el proyecto deberá ser basado en C++.

- ¿Qué le depara el futuro?:
Espero que cosas buenas.
Entre las cosas pendientes a hacer estan las siguientes:
+ Mejorar la documentación y la presentación en general.
+ Mejorar el soporte para GP2X.
+ Añadir nuevas funcionalidades.
+ Espero que apoyo por parte de la scene para mejorarlo.
+ Y muchas más cosas.

Podéis descargar el pack desde sourceforge:
http://sourceforge.net/project/showfiles.php?group_id=78302&package_id=177848&release_id=389567

La documentación (referencia del API) está totalmente en inglés, puesto que la idea principal en su momento hace meses era la de distribuirlo entre varias comunidades sobre todo de habla inglesa, y seguirá siendo así, pero ocupando una parte muy muy importange gp32spain :).
Podéis preguntarme lo que querais sobre el toolkit. En breve tengo pensado escribir algún tutorial, que por supuesto publicaré tambien en español.


Podéis escribir los bugs que encontreis, aquí:
http://neopontec.com/en/mantis/

Y éste es el foro en mi web, por si quereis contribuir:
http://neopontec.com/en/forum/index.php

Saludos a todos, y espero buestra colaboración para intentar crear un toolkit en condiciones, sin intención de hacer la competéncia al minilib por supuesto :brindis: .

[hectorblanco]

Para intentar resumir un poco lo de arriba, porque veo que nadie opina al respecto:
Este toolkit sirve para programar juegos con SDL de forma más sencilla, y tiene soporte especifico para la consola, que intentaré mejorar y ampliar con el tiempo. Directamente se puede aprovechar el mismo código para funcionar en PC (windos, linux... etc) y GP2X solo con modificar un atributo.

Espero opiniones, sugeréncias, y sobre todo, colaboración para mejorar el toolkit.

Saludos. :)

[Uncanny]

Vaya, que curioso, un toolkit para SDL.

Yo si tengo algunas preguntas:

1º) Si la librerías SDL y sus funciones no son nada dificiles de usar, ¿en que sentido o cuanto más facilita la programación o el uso de esta librería?

2º) Cuando dices que tiene soporte especifico para la GP2X ¿quieres decir que limitas algo en particular o controlas ciertos parametros (ej: max resolución y bpp)?

3º) A riesgo de equivocarme ¿el añadir una capa superior de abstracción más no repercutirá negativamente, aunque sea minimamente, en el rendimiento de las aplicaciones?

4º) El hecho de usar unicamente C++ para los proyectos realizados con el toolkit ¿no crees que reducirá el campo o el abanico de usarios que prefieran no optar por la POO y usar solo C en lugar C++?

5º) Respecto a la documentación, ¿no crees que el hecho de que esté redactada unicamente ingles sea algo que haga que para los programadores que nunca han usado SDL o estén empezando a aprender a programar prefieran no optar por usar el toolkit cuando hay documentación y tutoriales en castellano de la API de SDL?

En fin, son cuestiones que me he planteado sin haber visto aun el toolkit, pero las dejo ahí ya que pides opiniones del toolkit :)

[Whitehat]

A mi entender esto es como si fuera una plataforma tipo Visual .NET o Mono, es decir
que te ayuda a la hora de programar bajo SDL, con la facilidad de que si esta todo correcto debe
de funcionar en las distintas plataformas, (tal y como hace .NET).

Corrigeme Hector si me equivoco ;)

A mi me parece una cosa excelente y de un currele tranquilo [wei5]
sin duda que lo usare ya que soy el mas vago del universo y si por mi fuera la programacion
seria siempre como lo hace Visual Studio (que conste que defiendo el picar codigo para la
optimizacion)

[hectorblanco]

1.
Las SDL no son nada difíciles de usar, ciertamente, pero para algunas cosas para hacer poca cosa tienes que escribir unas cuantas líneas de código, como por ejemplo es el caso del estor de sprites que he incluido, obra de Marius Andra.
Otro caso es por ejemplo cuando SDL intenta abrir un archivo de algo y no puede. Peta. Yo lo que he hecho es que verifique la existencia y la correcta carga de los ficheros. Si falla, muestra mensaje por consola, pero sigue funcionando.

2.
Más o menos. He automatizado el arranque de las diferentes librerias de SDL con los valores obligatorios de la consola, dejando los que no son obligatorios para que el programador los especifique como atributos de la clase NGT_Engine.
He hecho lo mismo para el cierra. Tu haces objeto_engine.finalize(), y el, dependiendo de la plataforma seleccionada, cerrará el juego, y en GP2X, te llevará al menú, sin que el programador se tenga que preocupar de ello.

3.
Es posible, pero la pérdida de rendimiento es casi inexistente, pues apenas se llevan a cabo acciones que vayan a consumir. Además que he tenido especial cuidado en evitar los 'memory leaks'.

4.
Tambien había pensado en ello. El toolkit lo había empezado en su momento en C puro y duro, pero vi que empezaba a enmarañarse un poco con funciones sueltas y pasos de parámetros a dichas funciones, así que preferí hacerlo en C++ para que fuera tan sencillo como crear un objeto, especificar sus atributos y usar sus funciones. Igualmente he puesto algunas funciones sueltas para el que quiera usarlas, aunque para compilar el conjunto se seguirá necesitando compilar bajo C++. No descarto hacer una versión especial del toolkit más adelante usando únicamente C, aunque ello impediria, o dificultaria implementar la gestión de GUI en la que estoy trabajando.

5.
Ha sido por tiempo, y por la audiencia a la que en un principio pensé hace varios meses. Si alguien colabora en el proyecto, o si encuentro suficiente tiempo publicaré las documentaciones en ambos idiomas.

Puedes echarle un ojo al demo que incluye el toolkit. El propio toolkit está en la carpeta 'base' del mismo.

Gracias por las preguntas, pues así puedo aclarar mejor las cosas.

[hectorblanco]

A mi entender esto es como si fuera una plataforma tipo Visual .NET o Mono, es decir
que te ayuda a la hora de programar bajo SDL, con la facilidad de que si esta todo correcto debe
de funcionar en las distintas plataformas, (tal y como hace .NET).

Corrigeme Hector si me equivoco ;)

A mi me parece una cosa excelente y de un currele tranquilo [wei5]
sin duda que lo usare ya que soy el mas vago del universo y si por mi fuera la programacion
seria siempre como lo hace Visual Studio (que conste que defiendo el picar codigo para la
optimizacion)

Pues por una parte se le parece y por otra no.
Se parece porque principalmente va por clases, en las cuales estableces una serie de atributos o propiedades.
Pero se diferencia en que he programado en C++, pero con la mentalidad de un programador de C. Quiere decir que he usad POO únicamente para la creación de clases. El resto de forma está basado en programación clásica de C.

Otra cosa a la que le doy importáncia, y que he medio-sacado de .NET o JAVA, es que cada clase imprime por pantalla las tareas principales que está ejecutando, para poder encontrar de forma más sencilla un fallo en caso de haberlo.

[Whitehat]

Mmmmm me parece qe ya entiendo algo mas, digamos que has creado
clases para tener las funciones que mas se usan en SDL, pero de una manera
de facil acceso y de gran utilidad (para los q no sepan POO, esto les sirve como un
copy paste de funciones que ya han usado). Ya que solo hay que llamarlas a traves
de las clases que tu has creado.

En lo de que hayas usao POO solo para eso estoy bastante de acuerdo y me gusta
que lo hayas hecho ya que mucha gente (me incluyo) no le gusta muxo el royo de
las OO y eso que una vez q se pillan son superfaciles.

Lo de que te haga un printf de los errores me parece muy correcto ya que sino luego te puedes comer mazo de lineas para ver donde esta el error (esto para
los nuevos les viene de fabula),

Respecto a lo de que no sea tan optimizado, me parece que si has montado el trasto como pienso, seguramente sirva para modularizar mucho mas el codigo,
por lo tanto no tiene porque perder optimizacion.

Me mola esto sera que me estoy volviendo cada dia mas friki :loco:

Ale me voy a estudiar un rato que me follaran el viernes

[Uncanny]

Gracias a ti por las aclaraciones, vIendo las respuestas que me has dado parece interesante la idea de este toolkit :brindis:

En realidad si la has programado pensando en C e incluyendo funciones, y solo has usado C++ para solventar ciertos problemas y por el uso de las clases, tampoco debe ser un obstaculo para que un programador de C use algunas características de la POO de C++, al menos personalmente no tengo problemas en usar un paradigma u otro, sea con C o con C++.

Si no te importa, unas cuantas preguntas más:

1º) Creo haber entendido que el enfoque de tu toolkit es para usarse en multiples sistemas, pero aun siendo así ¿va a estar más enfocado a su con uso la GP2X o solo es una parte con la misma importancia que el resto de soportes para otros sistemas?

2º) Ese gestor de sprites del que hablas, de Marius Andra (supongo que es el mismo de Cone3D Programming con los manificos tutoriales de "GFX with SDL"), a grosso modo, ¿como funciona o en que consiste?

3º) ¿Puedes adelantar que es eso de la gestión de GUI en la que estas trabajando ahora?

4º) Respecto a lo que tienes pendiente en el futuro para el toolkit como mejorar el soporte para GP2X (que se relaciona con la 1º pregunta) ¿que nuevas funcionalidades para esta te gustaría añadir o en que aspectos (gráficos, sonidos, control, etc) necesitarías más ayuda si alguien decide o tiene tiempo para colaborar en el toolkit y como podría colaborar si asi fuera?

5º) Relacionado con la 4º pregunta, pero buscando la optimización en la GP2X, en todos los aspectos ¿tienes previsto "solo" encapsular el uso de las funciones de la API de SDL y sus librerías auxiliares existentes o, si lo ves necesario, añadir nuevas funciones/metodos para suplir alguna carencia de estas o por optener algo más optimización en algun aspecto?

Respecto a esta ultima pregunta, por si no me he explicado bien, se refiere a que si buscas que el toolkit unicamente facilite la programación, pero sin añadir alguna funcionalidad o mejora que la librería SDL no tenga por si sola (cosa rara porque es muy completa y existen muchas librerías auxiliares, pero puede ser) sobre todo si se refiere a la GP2X (p.e: al estilo de paeryn que está mejorando e incluyendo extras enfocados a la GP2X, en unas SDL aceleradas por hardware).

P.D: En cuento termine de recompilarse mi toolchain + librerías (he desechado el anterior para hacerme uno algo más optimizado para la GP2X) pruebo con esa demo, aunque supongo que debería compilarse sin problemas en mi PC desde Linux, así que lo probaré igualmente en ambos :)

[ilarri]

me parece una gran idea, y puede ser una herramienta practica para los programadores en sdl, hacerles las cosas un poco mas comodas ^^....animo y continua avanzando, y no seas perrete, y sorprende a la gente con una version 0.2.1 de golpe! =)

[hectorblanco]

A Uncanny

1.
El toolkit tiene que ser en teoria platform-independent, por lo que no señadiran apenas funcionalidades exclusivas para la consola, pero sí que se haran todas las optimizaciones y apaños que se puedan para que vaya lo mejor posible. Las funcionalidades exclusivas podrian ser lo del medidor de bateria, comprobar la versión del firm, cosillas así, sin discriminar a los otros sistemas.

2.
Ese mismo es. En realidad es un poco 'extraño' el sistema de sprites. Estoy pensando en rehacerlo más adelante. La forma de funcionar es la siguiente. Se cargan en memoria los frames especificados en el archivo 'info' de la carpeta del sprite, y despues puedes mostrar solo un frame, reproducir la animación, detectar colisión entre sprites ...etc. En el demo que viene en el pack se ve como funciona. Para la versión estable 0.2 espero tener ya hecho algún tuto.

3.
Clases simples para dibujar botones, barras de progres, cosas así. No muy avanzadas ni complejas, pero funcionales. Tendré que pensar como hacerlo para dar soporte a la vez de navegación con ratón y teclado (o stick en las consolas).

4.
La primera parte se responde con la 1ª respuesta. Lo de la colaboración, pues es simple. Todo lo que alguien quiera aportar, revisaré si se puede implementar dentro del toolkit y que cumpla la filosofia de este. Por ejemplo cosas que me harian gracia son reescalados (espero que sin necesidad de usar la SDL_gfx), algún tipo de filtro de imagen. Se puede colaborar de muchas maneras: escribir documentación, aportar código, revisar código y programar con él en busca de bugs y posibles mejoras ...etc.

5.
La idea es ir añadiendo cada vez más funcionalidades básicas que requiera un programador para crear un juego de la forma más automatizada posible. Esto no es hacer un GameMaker, aviso para navegantes. Es facilitar la faena para que el programador no pierda el tiempo escribiendo muchas cosas que se pueden simplificar con este toolkit por ejemplo.
Algunas cosas que tenia pensadas era el crear clases abstractas básicas por ejemplo para gestionar players para juegos de rol, objetos y demás cosillas. pero esto ultimo quedaria como muy secundario por ahora. En principio lo de las SDL por hard, simplemente al compilar el juego, usando mi toolkit, pero con sus SDL, tendrias las funcionalidades que ofrezco, pero optimizadas por hard gracias a su port de la libreria básica, ya que el toolkit no hace otra cosa que llamar a funciones ya existentes de SDL, pero combinandolas para por ejemplo controlar errores.

Ufff.. espero haber solucionado tus dudas.
Hoy nos tendrian que dar el record a los posts más lardos :D

[Topochan]

o tengo las psicomonkey libs que son de un compi y algo mio, son clases abstractas para juegos(tipo sprite, tipo mapa, tipo gamstate, etc...). Poco a poco vamos añadiendo cosas como control de volumen y deteccion de colisiones por pixel(util para imagenes con alpha), es la que estoy para el proyecto pen-go panic (http://gp32spain.com/foros/showthread.php?t=27290) . Si te interesa algo o ayuda ya sabes :)

Edit tambien unas herramientas en python para generar los cpp y los .h automaticamente para la clase heredada.

[Uncanny]

Soy experto en escribir post largos xDD

Gracias por responder a mis preguntas, ya probé la demo, mañana intentaré mirar más detenidamente la doc referida a la API de tu toolkit aunque claro, como tu mismo dices aun solo está lo básico :)

[hectorblanco]

Soy experto en escribir post largos xDD

Gracias por responder a mis preguntas, ya probé la demo, mañana intentaré mirar más detenidamente la doc referida a la API de tu toolkit aunque claro, como tu mismo dices aun solo está lo básico :)

Sip.
Además, que mañana o pasado mañana pondré una nueva versión 'de apaños', con arreglos varios sobre todo de documentación y de salida de texto en el terminal.
Si lo vas mirando y tal te animo a usar el bugtracker. No veas lo que se agradece cuando se unifican en un mismo sitio los avisos de fallos, y sugerencias.

Para el desarrollo en español, se podria usar este foro, o en el foro de mi web, que lamentablemente espoco visitado, puedo abrir un subforo específico.

Ciao.