[Brico-Scene] UltraStar (Clon de SingStar)

1, 2, 3, 4
buf, lo estoy intentando compilar en ubuntu y de momento me ha pedido instalar las boost headers (www.boost.org) y en esas estoy. Que yo sepa, ademas de estas librerias usa SDL, Cairo, Alsa...
asi que vamos a necesitar portar bastantes cosas.
PD: A mi lo que mas me apetece hacer es o implementar el wiimote o investigar lo del micro, aunque con eso último no prometo nada
Bueno, parece que esto va arrancando, y me alegro.

Si estais de acuerdo tendríamos que crear una rama vendor para mantener ahí el código de terceros, para tener controlados los cambios en ese código. ¿Hay que agregar algún codigo más a parte del UltraStar NG? ¿libogc?. Yo me puedo engargar de la gestión de esta parte.

La estructura del repositorio sería:

/branches
/tags
/trunk
/vendor
/vendor/ultrastarng
/vendor/ultrastarng/current
/vendor/ultrastarng/0.2.1
/vendor/libogc
/vendor/libogc/current
/vendor/libogc/20080602

@Anacardio: Si te parece bien, dímelo y reorganizo el repositorio.

Por si alguno no tiene experiencia con el tema, la rama vendor se utiliza para actualizar el código de terceros de forma que los cambios que en este se produzcan afecten lo menos posible al código propio. Al principio parece un polo lioso, pero llega a ser tremendamente útil.

Para la rama trunk (la de desarrollo) no se por donde empezar, ¿quizás habría que hacer una copia del ultrastarng y sobre él ir modificando directamente?

@realbrucest: ¿Sigues adelante con la petición de espacio en sourceForge?. Si es así, creo que deberíamos limitar el uso del Assembla al subversion y al trac, para luego poder migrar a SF una vez que nos hubieran admitido el proyecto.
Si claro, reorganiza lo que quieras que se ve que tienes experiencia en eso
Venga, y yo solicito en cuanto pueda el espacio en sourceforge.

EDIT: ya está hecha la solicitud
Ok, ya está recolocado el ultrastar-ng original en la rama vendor. Tambíen lo he copiado a la rama trunk para que podais empezar a trabajar. La nueva ruta al repositorio es: http://svn.assembla.com/svn/ultrastarwii/trunk/.

Para ver el repositorio a través del Trac la dirección es http://trac.assembla.com/ultrastarwii/browser

EDITO: Respecto al libogc, ¿necesitamos libogc-20080602.tar.bz2 o libogc-src-20080602.tar.bz2 ? Ya veis que de esto de homebrew wii no tengo mucha idea XD

Por último, para los novatos con subversion: En la rama vendor NUNCA se hace ningún commit. Si saliese una versión nueva de UltraStar-NG o cualquier otra librería que tuviesemos en la rama vendor, por favor avisadme y ya me encargo yo de subirla y aplicar los cambios en la rama de desarrollo.
Oye que os parece usar el port de SDL que anuncian en este hilo:
hilo_sdl-para-wii_1058187
dice que los botones no están todos adaptados pero eso da un poco lo mismo porque para los botones basta con usar las funciones propias de libogc
Hola de nuevo. Ayer al final no pude hacer mucho por la tarde. A ver si esta tarde compilo el proyecto para ir echandole un vistazo. Ya os dije q tiempo libre no tengo mucho jeje
He empezado a pelearme con la parte del código dedicada a la carga y manipulación de archivos de audio y mirarme cómo va el tema de los archivos en las librerías del devkitpro.

Habrá que ver si todos los tipos y llamadas a funciones de las librerías boost no nos ralentizan demasiado. En este caso sí que habrá que pararse a identificar todas las que vayan saliendo y ponerse a escribir rutinas que nos den el apaño.
Las de SDL que me he ido encontrando: SDL_Surface, IMG_LoadJPG_RW, SDL_RWFromFile, zoomSurface, SDL_FreeSurface... habrá que mirarse si están cubiertas por la implementación para wii que encontró Anarcadio, aunque supongo que no debe haber problemas en este sentido, con referencia a los controles ahora no tengo abierto nada donde se usen pero creo haber visto que también tiran de SDL. Ergo, nos interesa bastante utilizar el wrapper.

De momento voy a andar haciendo pruebas con el stdio de mientras sigo tratando de aclararme con la lógica del código y a echarle también un vistazo a esto que lo mismo me ayuda a enterarme antes: http://miom.pytalhost.de/sdexplorer0.9src.zip
vale, la cosa se complica: para compilarse/ejecutarse en linux necesita xine o gstreamer (para el que no lo sepa son reproductores)
PD:Tambien he necesitado instalar la libreria libxml++ y además me dice que me falta libdausng.la
realbrucest escribió:He empezado a pelearme con la parte del código dedicada a la carga y manipulación de archivos de audio y mirarme cómo va el tema de los archivos en las librerías del devkitpro.

Habrá que ver si todos los tipos y llamadas a funciones de las librerías boost no nos ralentizan demasiado. En este caso sí que habrá que pararse a identificar todas las que vayan saliendo y ponerse a escribir rutinas que nos den el apaño.
Las de SDL que me he ido encontrando: SDL_Surface, IMG_LoadJPG_RW, SDL_RWFromFile, zoomSurface, SDL_FreeSurface... habrá que mirarse si están cubiertas por la implementación para wii que encontró Anarcadio, aunque supongo que no debe haber problemas en este sentido, con referencia a los controles ahora no tengo abierto nada donde se usen pero creo haber visto que también tiran de SDL. Ergo, nos interesa bastante utilizar el wrapper.

De momento voy a andar haciendo pruebas con el stdio de mientras sigo tratando de aclararme con la lógica del código y a echarle también un vistazo a esto que lo mismo me ayuda a enterarme antes: http://miom.pytalhost.de/sdexplorer0.9src.zip


Las SDL_Surface son los objetos dibujables en pantalla de la libreria SDL, luego están en la libreria, SDL_RWFromFile es para cargar ficheros para uso general, tambien está, SDL_FreeSurface es para borrar las SDL_Surface de memoria, tambien está.

IMG_Load pertenece a la libreria SDL_Image, disponible tambien para Wii, aunque cuando intento cargar ficheros JPG me dice que el formato no está soportado, quizas sea por el tipo de JPG que he probado o que habra que esperar a una proxima versión que lo soporte.

zoomSurface pertenece a la libreria SDL_Gfx, fue una de las primeras librerias que compile y funciona perfectamente.

Si encuentras mas instrucciones SDL postealas y te dire a que libreria pertenecen y si funcionan en Wii.

Tengo modificada la libreria para que soporte todos los botones del mando 1 y del mando 2 (incluidos nunchuck), mas adelante la seguire modificando para agregar los mandos 3 y 4 y el mando clasico en cada puerto.

Los botones se controlan con SDL_Event, te lo digo por si encuentras alguno que sepas que son para eso.
Alguien ha conseguido compilarlo porque yo llevo intentandolo desde ayer en mi ubuntu y no hay manera.
PD:Habría que crear un grupo que se dedique exclusivamente a la investigación con el micro porque pinta dificil la cosa
PD2:KriogeN cuelga la versión con todos los botones aunque tenga sólo 2 mando ya que de momento con uno solo mando para los ajustes y tal nos basta
PD3:Realbrucest, si has empezado con algún archivo vete subiendolo de forma periódica a /trunk y cuando lo hagas avisa; aunque yo miro cada rato con el CVS si ha cambiado algo
Ahí lo teneis

http://www.megaupload.com/es/?d=2S9OFDVK

He subido solo la libreria y el fichero SDL_Mouse.h que teneis que sustituir en la otra libreria.

En el .h he cambiado los defines para saber que botón se ha pulsado:

#define SDL_BUTTONJ1_A 1
#define SDL_BUTTONJ1_B 2
#define SDL_BUTTONJ1_HOME 3
#define SDL_BUTTONJ1_MINUS 4
#define SDL_BUTTONJ1_PLUS 5
#define SDL_BUTTONJ1_1 6
#define SDL_BUTTONJ1_2 7
#define SDL_BUTTONJ1_LEFT 8
#define SDL_BUTTONJ1_RIGHT 9
#define SDL_BUTTONJ1_UP 10
#define SDL_BUTTONJ1_DOWN 11
#define SDL_BUTTONJ1_Z 12
#define SDL_BUTTONJ1_C 13
#define SDL_BUTTONJ2_A 14
#define SDL_BUTTONJ2_B 15
#define SDL_BUTTONJ2_HOME 16
#define SDL_BUTTONJ2_MINUS 17
#define SDL_BUTTONJ2_PLUS 18
#define SDL_BUTTONJ2_1 19
#define SDL_BUTTONJ2_2 20
#define SDL_BUTTONJ2_LEFT 21
#define SDL_BUTTONJ2_RIGHT 22
#define SDL_BUTTONJ2_UP 23
#define SDL_BUTTONJ2_DOWN 24
#define SDL_BUTTONJ2_Z 25
#define SDL_BUTTONJ2_C 26

Se autoexplica para que sirve, si quereis cambiar los nombres solo teneis que crear nuevos defines que se correspondan con el número del botón que quereis cambiar.

Los botones de los mandos son de tipo de evento SDL_MOUSEBUTTONDOWN, aquí un ejemplo:

if (SDL_PollEvent(&event))
{
if (event.type == SDL_MOUSEBUTTONDOWN)
{
if (event.button.button == SDL_BUTTONJ1_HOME)
exit(0);
if (event.button.button == SDL_BUTTONJ1_1)
SDL_FreeSurface(carta);
}
}
ok gracias, me voy a poner a adaptar los botones.
Yo creo que lo que vamos a hacer va a ser lo siguiente:cada uno se dedica a una cosa menos a lo del micrófono, que lo dejamos para el final, para el momento en el que tengamos una version compilable para wii (aunque sin utilidad alguna ya que no tendrá micro XD) y entonces nos volcamos todos en lo del micro. O si lo preferís al revés, primero el micro; pero separandolo del resto igualmente
Pues acaban de anunciar un micrófono para Wii que vendrá con Animal Crossing. A ver si con esto se puede hacer rular jjejeje.
@Anarcadio, yo estoy contigo en lo de conseguir primero un "algo compilable para wii" (porque sin micro, como que de "juego" no se podrá calificar todavía). Una vez que se le empiece a ir viendo la forma eso nos animará más a ponernos a saco con lo de los micrófonos. Con lo de la adaptación del código, hasta este fin de semana (si no toca playa ;) ) seguramente avance muy poco a poco. De todos modos en cuanto empiece a cambiar código lo echo para el SVN.

@albertoi: gracias por el apunte, pero en realidad será el tercer juego que incluya micro tras el Boogie y el High School Musical. En lo que nos concierne a nosotros no debería existir diferencia al emplear uno u otro dando por supuesto que todos transmiten por usb y su funcionamiento se presupone el mismo.

Y con lo del micro me pregunto si las librerías de acceso a discos duros que se curró svpe nos podrán dar alguna pista. Echando mano de la ilusión del que no tiene ni idea me da por suponer que debe ser menos complejo que lo que se consiguió para operar con los medios de almacenamiento.

EDIT: como es una tonteria me limito a editar, pero acabo de ver que libogc tiene un mutex.h para los multithreads. Antes de verlo eso me tenía mosca puesto que en el código original, para usarlos tiran de librerías boost y habría que figurarse cómo estaban planteadas y que ofrecían. Además creo que para los multihilos es para lo único que se utilizan.
@kriogeN: He hecho una copia del port de SDL para Wii en la rama vendor de nuestro repositorio, y he creado una rama para reflejar tus cambios. Si quieres, puedes utilizar esa rama para seguir subiendo cambios a medida que los vayas teniendo.

Copia original del port de SDL:
http://svn.assembla.com/svn/ultrastarwii/vendor/libSDL-wii/current/

Rama con los cambios de kriogeN:
http://svn.assembla.com/svn/ultrastarwii/branches/libSDL-wii_kriogeN/

Como siempre, si sale alguna release nueva del port original, avisadme para actualizar la rama vendor.
Durante esta semana hago una versión que funcionen los 4 mandos (en realidad lo unico que tengo que hacer es copy&paste de lo que ya tengo y cambiar J2 por J3 y J4) y este finde a ver si puedo quedar con un amigo que tiene 2 mandos y pruebo si funciona (deberia funcionar, pero mas vale asegurar).

Ahora quiero ver si hago una modificación en la libreria para que usando el sistema de eventos de SDL puedas saber tambien la posición del puntero de los mandos 2, 3 y 4.
A ver, cosillas agradables que me he ido encontrando mirando lo que nos ofrece libogc...

- Que las mutex de las librerías boost parece que no van a ser un problema puesto que libogc también cuenta con su correspondiente adaptación.

- Que también existe un usb.c la mar de completo por lo que aparentemente no va a ser necesario tirar de bajo nivel para pelearse con la interpretación de los datos que llegan del micro. Ya no tengo tan claro que sea necesario dejar momentáneamente de lado este tema.

En resumidas cuentas, que no me esperaba que las herramientas de trabajo para wii estuviesen ya a este nivel. Muy grata sorpresa.

Y muchísimas gracias kriogeN por tu soporte con las SDL.

Este subforo es la caña [fies]
Que gran noticia, todas las librerías boost estan adaptadas?
Por otro lado mañana miraré las funciones de la librería de usb a ver como de dificil está lo del micro.
PD: Sigue estando el problema del xine/gstreamer
No sé si todas, es que las de los multithread se me estaban atravesando pensando en que habría que ponerse a escribirlas desde cero, me había obsesionado un poco con esto, si me he topado con más rutinas de boost no les he echado mucha cuenta, la verdad.

Lo del xine tiene todas las papeletas para quedarse para el final. De todos modos, en el juego los vídeos son opcionales.
La verdad los felicito por el trabajo que estan haciendo, si lo terminan le voy a sacar mucho jugo, hace poco compre el high school para tener el micro.
Me encantaria ayudarlos a programar pero la verdad no tengo ningun conosimiento de como se hace y la verdad si me pongo a aprender terminan ustedes antes que yo les sirva de algo.
Por ahora lo unico que puedo hacer y desearles suerte.

Lo que me interesaria sabe, cuando lea los archivos de musica, serian los mismos que si corriera el programa en la pc? osea el mismo formato?
Si lo haceis compatible con los micros USB del singstar de la ps2, os hago una estatua (joder, ultimamente me dejo media cartera en estatuas a los sceners de wii xD). Estais haciendo un gran trabajo, seguid asi.
tamandua escribió:Lo que me interesaria sabe, cuando lea los archivos de musica, serian los mismos que si corriera el programa en la pc? osea el mismo formato?

Que utilice los mismos archivos es lo que nos interesa y lo que se pretende. Cuando Anarcadio habla de que lo del xine va a estar difícil se refiere a las funciones de tratamiento de los vídeos, en cuanto al audio, otra vez gracias a Hermes y sus libs no deberiamos de atascarnos demasiado. Como los reproductores multimedia nativos (no sé si únicamente mplayer hoy por hoy) están aún dando sus primeros pasos, es posible que esto quede para el final. Aunque todo se andará.

Y tras otro vistazo a cómo anda google de documentación en lo referente al tratamiento de la señal cruda procedente de micros usb (los de singstar entran en la categoría ;)) he encontrado lo siguiente que hay que pararse a mirar, cosa que yo no he hecho.

Original post by cignox1
Hi, interesting idea, could worth a try. You may want to try FMOD, a free open source sound library that lets you record sounds from the microphone. I think that it already provides FFT (or other tools) for sound analisys. If not, and in case you need it, you can get FFTW.


Más enlaces que pueden aportar pistas:
"Lab 16 Digital Scope and Spectrum Analyzer using a USB link"
http://users.ece.utexas.edu/~valvano/EE ... /Lab16.pdf

Otra de las librerías que hay que sustituir es GStreamer

Las sndlib de hermes voy a tener que mirármelas bien antes de empezar a meter mano a las modificaciones, ahora estoy echando un ojo a los ejemplos que los ha adornado con GX bastente generosamente.

---------------------------------------------------------------------------

EDIT: buenas noticias, ya tenemos espacio propio en SourceForge

Copio y pego.



Your project registration for SourceForge.net has been approved.

Project Information:

Project Descriptive Name: UltraStar Wii
Project Unix Name: ultrastarwii
CVS Server: ultrastarwii.cvs.sourceforge.net
Shell Server: shell.sourceforge.net
Web Server: ultrastarwii.sourceforge.net

Project Administration:

The Project Admin page for your project may be accessed at https://sourceforge.net/project/admin/?group_id=234082 after logging-in.

DNS data for your project web site may take up to 24 hours to become active. Until DNS is active for your project, accessing your project web site will result in 404 errors. Once DNS is active, you will see an empty directory index on accessing the project web site, until you have placed content in the project web space (remember that project web space is provided solely for use in storing project-related information [1]).

Your access to the project shell, CVS servers (including your new CVS repository, which has already been initialized and is ready for your first import), and Subversion servers are typically available within four hours from the time when your project was approved. If after 6 hours your shell/CVS accounts still do not work, please submit a Support Request [2].

...

Welcome, and please enjoy the system! -- the SourceForge.net crew
Estoy tratando de mover el repositorio y el trac de assembla a SF, hay un par de problemas.

El primero es que no puedo hacer ningún commit a SF pero creo que eso es porque la cuenta es muy reciente. Por otro lado, se puede instalar el Trac en SF, pero por cuestiones de seguridad, SF no deja acceder desde el sitio donde estaría instalado el Trac, al servidor donde está el repositorio.

Como el Trac necesita que el repositorio al que está vinculado esté alojado en el mismo servidor, no podríamos utilizar la función de browser del Trac para ver el repositorio...

Hay un ticket abierto en SF de alguien que quiso instalar el Trac, y en teoría están trabajando en ello, pero no se sabe nada más. De todos modos SF ya tiene su propio sistema de gestión de tickets y su visor del repositorio, por lo que quizás el Trac no fuese necesario (Aunque yo, me encuentro más cómodo con esta herramienta) por ello mi duda es si debemos mover todo a SF o quedarnos en Assembla.

Pues eso, opinad!
No sé yo si sería muy sensato seguir el trabajo en assembla pero migrar el SVN a SourceForge cuando consigamos tener algo compilable. A lo que me refiero, nos marcamos un objetivo que sea el de clonar el UltrastarNG tal cual se encuentra ahora mismo, si el trabajo te resulta más cómodo con Trac y con ese servicio vamos más que aviados por mí seguimos con assembla aunque me gustaría que en el espacio en SF dejemos el proyecto colgado aunque eso vaya a ser más adelante y por nuestra parte podamos haberlo dado por concluido. Porque en lo que respecta al trabajo personal, lo mismo me da enviar los archivos a uno u otro sitio, si tú los vas a gestionar la decisión dependería más de tí.

Sintetizo. Continuamos con assembla, una vez que haya cobrado forma nos lo llevamos a SF más que nada para justificarnos y para que tenga mayor difusión.

Lo mismo es una estupidez pero bueno, no deja de ser una idea.
Estoy de acuerdo con realbrucest, seguimos con assembla hasta que estoy empiece a tomar forma.

No obstante os aviso que el repositorio de SF ya está funcionando correctamente. Ahora mismo tiene la misma información que el de assembla. Intentaré, en la medida de lo posible, ir subiendo a SF cualquier cambio que vayais enviando a assembla.

EDITO: @realbrucest: corrige el enlace en el primer post al repositorio de SF porque el que hay es al CVS, pero estamos usando SVN. La direccion es:
https://ultrastarwii.svn.sourceforge.net/svnroot/ultrastarwii
No sabia que existia este proyecto, como se entere mi novia me va a tener pendiente hasta que pueda cantar. Animos y si os hace falta ayuda me apunto.
@lololailo: okis, post principal corregido

@flubbers: teniendo presente que de momento y por lo que me consta hemos hecho poco más que empezar a organizarnos, investigar y mirarnos código hay cabida para cualquier nueva ayuda. Aparte de repasar código original e ir modificando para que tire con lo que nos ofrecen las librerías del devkitpro, hemos identificado estos frentes para tratarlos por separado:
- Reescritura de openGL a GX
- Adaptación para el wiimote
- Investigación del uso del micrófono
- La lectura de las canciones a través de la SD
- Adaptar un visualizador de vídeos MPG

Aún nos queda tela para erigirnos en los dioses de la scene para con las respectivas novias.
(Valiente churro de frase que me ha quedado, por favor que nadie me la saque de contexto que yo me entiendo XD )
Aqui uno que se apunta, mas que nada es para autoobligarme a hacer algo de programacion que si no lo dejo de lado y no aprendo xDD la verdad es que no se mucho, pero algo es algo^^ Eso si tendre que leerme como funcionan los CVS y SVN y cosas de estas porque no las he trabajado nunca ;) ya me direis que parte me toca investigar

Salu2 =D
Joder me estais poniendo los dientes largos, tanto que estoy por pillar los micros para wii de dealextreme ahora mismo XD
Animo gente
Para quienes no tengan claro como trabajar en un SVN, en el caso de que utilicen Windows pueden utilizar TortoiseSVN para trabajar con él sin apenas complicación.
Esto es sólo orientativo pero os facilitará el camino a los recién llegados.

Como primer paso, localizad TortoiseSVN y realizad la instalación por defecto: "Siguiente", "siguiente", "siguiente"... Una vez que haya finalizado os pedirá reiniciar el PC. Aceptad y acercaros al frigo a echar un vistazo al frigo o simplemente incorporaros de la silla para estirar piernas que nunca viene mal.

Imagen

Cuando hayamos regresado a Windows ya se habrá integrado el programa correctamente en el shell, lo que viene a ser que cuando utilicemos el botón derecho del ratón sobre una carpeta o directorio tendremos disponibles nuevas opciones para gestionar nuestro contenido local en vinculación con un espacio SVN.

Lo siguiente que habrá que hacer es una carpeta donde volcaremos el contenido del SVN quedando asociado a éste. Por tanto: se crea una carpeta y en el menú contextual que se muestra al pulsar el botón derecho seleccionamos "SVN Checkout".

Imagen

Tenemos que indicar http://svn.assembla.com/svn/ultrastarwii/trunk en la URL del repositorio. Le damos a "OK" y nos logeamos con los datos de la cuenta en assembla. Ahora esperamos a que se descargue el contenido del SVN.

Imagen
Que no os confunda la imagen, únicamente pretende mostrar el diálogo de login

Imagen

Ya podéis examinar el contenido de la carpeta que se corresponderá con lo que en el momento del "checkout" hubiese en el servido. Y a partir de ahí, a trastear con el código y con las opciones del tortoise.

Imagen


Saludos y gracias a todos los que os estáis interesando por el proyecto.

@Pho: que te olvidaba [tomaaa] , trabajar así con código ajeno resulta tedioso al principio. Curiosea los fuentes para hacerte una idea de cómo va y cuando ya veas algo donde creas que puedas meter mano, pues manos a la obra.


=======================================================================

EDIT:

Fuentes con formato

En el Ultrastar NG original se utilizan las librerías Pango fonts para dibujar texto en pantalla.

Pongo la declaración del PrintText para que le echéis un vistazo a todas las llamadas que se hacen a funciones de estas libs.

En /src/theme.cpp
cairo_surface_t *CTheme::PrintText(TThemeTxt *text) {
   PangoFontDescription *desc = pango_font_description_new();
   PangoLayout *layout = pango_cairo_create_layout(dc);
   pango_layout_set_alignment(layout, PANGO_ALIGN_CENTER );
   PangoRectangle rec;

   cairo_save(dc);

   pango_font_description_set_family(desc, text->fontfamily.c_str());
   pango_font_description_set_style (desc,PANGO_STYLE_NORMAL);
   pango_font_description_set_absolute_size (desc,text->fontsize * PANGO_SCALE);
   pango_layout_set_font_description (layout, desc);
   pango_layout_set_text (layout, text->text.c_str(), -1);
   pango_layout_get_pixel_extents (layout,NULL,&rec);
   text->extents.width = rec.width;
   text->extents.height = rec.height;
   text->extents.x_advance = rec.width+rec.x;
   text->extents.y_advance = rec.height+rec.y;
   pango_font_description_set_absolute_size (desc,text->fontsize * text->scale * PANGO_SCALE);
   pango_layout_set_font_description (layout, desc);
   pango_cairo_update_layout (dc, layout);
   cairo_scale(dc, width/text->svg_width, height/text->svg_height);
   cairo_move_to(dc,text->x - (rec.width-rec.width/text->scale)/2,text->y-text->fontsize * text->scale);
   pango_cairo_show_layout (dc, layout);
   pango_cairo_layout_path(dc,layout);
   if (text->fill_col.r != -1 && text->fill_col.g != -1 && text->fill_col.b != -1) {
      cairo_set_source_rgba(dc, text->fill_col.r, text->fill_col.g, text->fill_col.b, text->fill_col.a);
      if (text->stroke_col.r != -1 && text->stroke_col.g != -1 && text->stroke_col.b != -1) cairo_fill_preserve(dc);
      else cairo_fill(dc);
   }
   if (text->stroke_col.r != -1 && text->stroke_col.g != -1 && text->stroke_col.b != -1) {
      cairo_set_line_width(dc, text->stroke_width);
      cairo_set_source_rgba(dc, text->stroke_col.r, text->stroke_col.g, text->stroke_col.b, text->stroke_col.a);
      cairo_stroke(dc);
   }
   cairo_restore(dc);

   g_object_unref(layout);
   pango_font_description_free(desc);
   return surface;
}


Y ahora la pregunta: ¿hay alguna librería para wii para trabajar con texto con formato?

============================================================

EDIT 2:

Pasar de los gráficos SVG en favor de PNG

cairo_svg = new CairoSVG(sm->getThemePathFile("intro.svg"), width, height);

Otra cosa que tampoco pienso que necesitemos, al menos de momento, viene a ser todo el código relacionado con el formato SVG. Toda esa parte se puede reescribir para usar PNG, por ejemplo, en lugar de complicarnos la vida con gráficos vectoriales para los que tampoco parece que tengamos librerías que nos lo den hecho. Además, para los efectos de transición entre menús, que se llevan a cabo un ligero zoom con fundido antes de dar paso al nuevo, eso se puede hacer teniendo renderizado el menú como textura sobre polígonos planos, que sería el caso. Escalado y alpha; aparentemente simple.
Para trabajar con PNG ya existen buenas herramientas (es lo que tiene EOL, que es muy completito) y si se quisiera respetar el formato de los gráficos originales, para eso siempre habría tiempo ya una vez concluida la versión funcional nativa de wii. Tampoco va a suponer demasiado coñazo convertir de SVG a PNG a los que quieran utilizar los skins del original...
Bueno, he estado un tiempo ausentado de este hilo y es porque estaba intentando instalar las SDL para comenzar a adaptar los botones usando la SDL para wii pero no he conseguido que me funcionen bien (aunque por lo que he visto no soy el único) asi que no se que hacer.
Ahora para redimirme por estos días tan infructuosos XD voy a recopilar lo que sabemos sobre las librerías que usa el orginal y las que podemos usar

Original____________________________________________Reemplazo
SDL-------------------------------------------------------SDL-Wii (?)
Cairo------------------------------------------------------?????
Alsa-------------------------------------------------------?????
libxml------------------------------------------------------(me parece que libogc tiene una librería de xml)
boost------------------------------------------------------ mutex.h
Pango fonts------------------------------------------------?????

PD:Realbrucest, veo que has hecho cambios en el SVN, ahora miro de que van exactamente los cambios
Anarcadio, no esperes mucho con los cambios que tan sólo he andado eliminando todo lo que tuviese que ver con la posibilidad de altelnar entre pantalla completa y ventana. Más que nada para aclarar el código limpiándolo de cosas que a todas luces sobran.
La parte en la que se analizan y aplican los parámetros que se les pasan al programa al lanzarlo por línea de comandos también van fuera.

kriogeN es el que controla el tema de SDL, he ido siguiendo desde el main el programa de modo que si se llamaba a tal función veía si era ya implementable para nuestro caso, si las estructuras de datos contenían algun tipo con el que no contemos, etc, etc... Tratando de simplificar el código he llegado al primer punto muerto y que nos abriría bastantes puertas que es la necesidad de un parser que dándole un archivo SVG nos lo devuelva renderizado en una SDL_surface.
Googlearé un poco a ver qué encuentro.

Y para tu lista, lo mismo podemos recurrir al final a
OpenGL...........................................................gl2gx
(Han colgado una nueva versión que no es la que se probó en su momento hace escasos días)

PD: ¿a que queda chulo el iconito de mi firma? XD

EDIT:
algo así implementado para trabajar con ella en wii nos vendría de perlas para empezar a mostrar gráficos:
http://www.linuxmotors.com/SDL_svg/
me pongo a leer a ver cómo va la cosa
realbrucest escribió:Anarcadio, no esperes mucho con los cambios que tan sólo he andado eliminando todo lo que tuviese que ver con la posibilidad de altelnar entre pantalla completa y ventana. Más que nada para aclarar el código limpiándolo de cosas que a todas luces sobran.
La parte en la que se analizan y aplican los parámetros que se les pasan al programa al lanzarlo por línea de comandos también van fuera.

kriogeN es el que controla el tema de SDL, he ido siguiendo desde el main el programa de modo que si se llamaba a tal función veía si era ya implementable para nuestro caso, si las estructuras de datos contenían algun tipo con el que no contemos, etc, etc... Tratando de simplificar el código he llegado al primer punto muerto y que nos abriría bastantes puertas que es la necesidad de un parser que dándole un archivo SVG nos lo devuelva renderizado en una SDL_surface.
Googlearé un poco a ver qué encuentro.

Y para tu lista, lo mismo podemos recurrir al final a
OpenGL...........................................................gl2gx
(Han colgado una nueva versión que no es la que se probó en su momento hace escasos días)

PD: ¿a que queda chulo el iconito de mi firma? XD

EDIT:
algo así implementado para trabajar con ella en wii nos vendría de perlas para empezar a mostrar gráficos:
http://www.linuxmotors.com/SDL_svg/
me pongo a leer a ver cómo va la cosa


Esta tarde en cuanto tenga tiempo trato de compilar la SDL_svg y la subo.

EDIT: Resulta que no es tan sencillo, para poder compilar la SDL_SVG hace falta la FreeType2 y la LibXML

La LibXML no es la que ya portaron para Wii, es otra distinta.
Bueno en lo unico que se me ocurre que podría colaborar (ya que no hay que portar de pascal a c que es en lo que podría ser útil), es capturando el tráfico usb en el pc con usbmon por si esto puede servir para lidiar con los micros (ya colaboré en un proyecto para desarrollar unos drivers para linux de una cam).
Ahora eso si lo único que sé hacer es eso, luego como utilizar eso para manejar los micros en la wii ni idea :(
Si creeis que puedo ayudar mandadme un pm y me uno.

Un saludo y mucha suerte con el proyecto.
kriogeN escribió:EDIT: Resulta que no es tan sencillo, para poder compilar la SDL_SVG hace falta la FreeType2 y la LibXML

La LibXML no es la que ya portaron para Wii, es otra distinta.


Pues en vista de que va a ser complicado tirar por aquí si queremos respetar el formato svg de los gráficos, sugiero que nos pasemos definitivamente a los png.
La ventaja de los svg es que al ser vectoriales no hay reescalado de gráficos ya que la imagen se renderiza a la resolución que se le haya especificado. Sin embargo, para un juego en el que prácticamente todo viene a ser un interfaz de menús tampoco va a ser ningún crimen que los usuarios de zona NTSC no vayan a poder disfrutar de sus 528 pixels verticales.
PNG a 640*480 y nos quitamos de complicaciones.

Por tanto, si de aquí a un par de días nadie se pone a darle caña al formato svg, damos vía libre para que todas las referencias del código del svn a ese formato se empiecen a adaptar para que se trabaje con png.
Ya digo, visto lo visto trae mucha más cuenta ponerse ya a identificar todos los tipos y métodos que hacen uso de svg para empezar a ir reemplazándolos depués.

@Einy: nos vendría estupendamente la ayuda que comentas, a ver si me miro un poco por encima el tema de usb en wii y te comento para que cuando te pongaas tu trabajo cunda aún más.
Si alguien ya hubiese trasteado un poco con el usb.h o sabe cómo encaminar esta parte de la investigación, por favor, que lo comente por aquí.

Una vez más, gracias a todos por vuestro interés.

Para las navidades venideras tenemos karaoke para hacer el chorra durante las fiestas seguro.

===========================================

EDIT:

Imagen

Tema "lime" en formato original SVG

¿Ideas?, ¿sugerencias?, ¿opiniones? ...
640 * 480 en formato 4:3

¿y si el formato es 16:9?
realbrucest escribió:...
Para las navidades venideras tenemos karaoke para hacer el chorra durante las fiestas seguro.

===========================================


Ala... pues si que son optimistas y/o trabajadores, si sale este proyecto en medio año se habrá avanzado mucho y la verdad que hay 2 micros de wii por USB en una pagina de hong kong con envio gratuito (no puedo decirla porque supongo que es Spam, pero me imagino que todos saben cual es) por menos de 15€. Eso es barato no? Porque los de singstar de PS2 me tendria que comprar tambien el juego y no tengo PS2 asi que es un poco absurdo. Cuando he mirado pa pillar de segunda mano los venden bastante caros.

¡Como me he ido de offtopic! Si yo solo queria felicitar pero ya me da pereza borrar :D
Gran trabajo y a ver si pa Navidades me apaño algun microfono y lo pruebo con la familia que estos juegos en grupo tienen su gracia.
Yo ayudare en lo que pueda. Soy partidario del software libre y me gusta colaborar con el ;)

No tengo ni idea de Pascal y muy poco de C, aunque decir que me gustan los retos y aprendo rápido.

En todo lo relacionado al aspecto gráfico seguro que os puedo echar una mano, controlo el Gimp hasta con los ojos cerrados ^^

¡¡Y esperemos que el proyecto marche!! :D

PD: Creo que seria conveniente habilitar la opción de micrófonos por USB.
realbrucest escribió:Pues en vista de que va a ser complicado tirar por aquí si queremos respetar el formato svg de los gráficos, sugiero que nos pasemos definitivamente a los png. [...]

Me acabo de descargar el UltraStar v0.6.0 para PC, para intentar ayudar con el tema de los graficos y tal, y he visto que estos no son en formato SVG, sino en JPEG.
Me he descargado una version equivocada? O es algo nuevo en la nueva version? (v0.6.0)
Un saludo
Unai1989 escribió:Me acabo de descargar el UltraStar v0.6.0 para PC, para intentar ayudar con el tema de los graficos y tal, y he visto que estos no son en formato SVG, sino en JPEG.
Me he descargado una version equivocada? O es algo nuevo en la nueva version? (v0.6.0)
Un saludo


Bájate la versión que tenemos colgada utilizando cualquier programa para trabajar con nuestro SVN: el tortoise para Windows o cualquiera de los muchos que tenemos en linux, yo uso el SVN Workbench.

Actualmente se mantienen en desarrollo tres versions de Ultrastar para pc:
- El Ultrastar original.
- Ultrastar Deluxe, que persigue la estética y funciones del de PS3.
- Ultrastar NG, que se podría considerar como el intermedio entre ambos, más similar al de PS2

La principal razón para utilizar el NG como base ha sido que entre los tres es el único escrito en C++, necesario para trabajar para wii hoy por hoy. Los demás están siendo desarrollados en Delphi.

Si quieres, créate una cuenta en assembla y te agregamos al proyecto para que puedas utilizar el SVN. De ese modo todos trabajamos con los mismos archivos y estamos al tanto de qué modificaciones les vamos haciendos unos y otros.

Al menos en ultrastarNG, los temas son personalizables y vienen como imágenes independientes en formato SVG. Quizá la mejor opción sea ir adaptándolos haciendo uso de GRRLIB (que de no ser por pozas no me entero que también permite trabajar con texto "formateado").

-------------------

Y en otro orden de cosas, cito a marcan en un comentario que hizo en su foro en relación al reconocimiento de la señal de micros usb.

marcan escribió:parece que no están implementados los modos isócronos de USB y por lo tanto no se puede hacer streaming de audio/video (aunque eso es puramente un problema de drivers y puede que aparezca en alguna versión nueva). Si el nuevo micro es USB, supongo que lo harán (o veremos como usarlo), lo cual es interesante.


Con lo cual, ¿será conveniente esperar a que actualicen nuevamente para la salida del Animal Crossing?
Es que aqui estamos usando el Ultrastar NG =P
El que te has bajado, es de codigo libre? no lo creo pero si lo fuese ya tenemos lo sproblemas solucionados xD

EDIT: te me has adelantado xD No sabia que los otros eran libres pero en delphi, llegue cuando ya habiais escogido xD
de todos modos, hay cosas mejores que las GRRLIB... Rev. Engine por ej. xD y el tema del texto, que es para ti texto formateado? (es un coñazo hacer las fuentes con para GRRLIB (verdad pozas? xDD))

Salu2
@pho: "formateado" es el palabro que me he sacado de la manga para tratar de indicar que serían convenientes una librerías que nos permitan dibujar texto dejándonos establecer tipo de fuente, tamaño, color y tal...
Precisamente el marrón que lleva dándole quebraderos de cabeza a pozas desde hace un tiempo :S
Esque veras, yo con GRRLIB 2, para mostrar un texto mas grande, no tienes una funcion que lo agrande, sino que tenias que crear cada fuente de cada tamaño en un .h y asegurarte de que todo quedaba adecuado xD sino sale blanco donde iria el texto.

Salu2 =3
Cuenta creada, instalado Tortoise, descargado archivos.
Y ahora a trastear con los graficos ^^
Un saludo!
Ralbrucest......

Intentare sacar tiempo de donde pueda...ahora mucho trabajo. Pero me pondre al dia y a currar¡¡¡
pho escribió:Es que aqui estamos usando el Ultrastar NG =P
El que te has bajado, es de codigo libre? no lo creo pero si lo fuese ya tenemos lo sproblemas solucionados xD

EDIT: te me has adelantado xD No sabia que los otros eran libres pero en delphi, llegue cuando ya habiais escogido xD
de todos modos, hay cosas mejores que las GRRLIB... Rev. Engine por ej. xD y el tema del texto, que es para ti texto formateado? (es un coñazo hacer las fuentes con para GRRLIB (verdad pozas? xDD))

Salu2

Uy que si es un coñazo.... no lo sabes tu bien xD
Bueno yo solo puedo animar a los programadores que erstan con este proyecto, ni siquiera soy capaz de mostrar texto en GRRLIB xDDDDD
Pa'rriba :)

Llevo más de una semana que nada más que me da lugar a pillar el EEE PC y como que el cacharrillo no incita demasiado al trabajo intensivo.

Ando atento a los inicios del Charmilion (intentaré mandaros a una dibujanta que es canela fina y que vuelve de vacaciones este sábado ;) ), y con este inesperado parón, la falta de actividad durante el mismo, que ya me conozco los entresijos del código, que precisa la tira de librerías externas y, el incipiente revolution engine...

Que me parece que con ayuda del engine de technik va a ser mucho más liviano e interesante rediseñar el interfaz gráfico. Que ya que se lo ha currado qué menos que no seguir complicándonos la vida y sacarle partido a esa estupenda herramienta.

Por lo que a mí respecta, pienso pasar de cairo, sdl, etc... y (a regañadientes y de momento) de SVG para emplear en su defecto la carga de PNG que integra el engine.

Vamos, que lo he pensado bien y es que no utilizar el revolution engine para toda la interfaz gráfica me parece más que de poca vista, de poca vergüenza.

Y lo de siempre, que el SVN está ahí para que todo el que quiera, cuando quiera, colabore en la forma que pueda.
Y que de mientras no tengamos implementación de micros, de nada vale correr =P

Saludos y ojalá el motor de technik tenga en la scene de wii la incidencia que de verdad se merece.
realbrucest, acabo de leer tu mensaje y me alegra un montón que se empiece a usar el engine. Quería comentarte que en la versión 0.2 (en la que ya estoy trabajando) se da soporte para textos de forma bastante extendida, ademas de que se incrementa el soporte 2D incluyendo scrolls, puntero pre-configurado, botones y muchas cosas mas.

Cualquier duda que tengas sobre el Engine , posteala y te la resolveré encantado
154 respuestas
1, 2, 3, 4