About Wikiti

Reparador profesional de tostadoras de 5º grado.

Ejemplo de arquitectura software

Indagando un poco, he conseguido un diagrama de la arquitectura software usada por el proyecto, de una manera sencilla y clara:

Image

Advertisements

Finalista

Tercero en fase local y finalista en la fase nacional. Sencillamente, cumplí el objetivo deseado, llegar a la fase final, y darme a conocer fuera de mi facultad. Felicitar también al proyecto http://qdemos.wordpress.com/ por su segundo puesto y por llegar a la fase final, y a http://rsquaredproject.wordpress.com/ por el primer puesto en la fase local.

Image

Un saludo a los lectores, y si hay alguno, espero manteneros informado 🙂

Página en ZehnGames

Para aquellos que vengan de susodicha página, sean bienvenidos al blog, a la forja, al canal lista de reproducción de youtube, y cualquier otro lugar relacionado con el proyecto.

Para los que no, simplemente una manera de intentar dar el proyecto a conocer. A ver si surge un público, por mínimo que sea.

CComponent_Audio_Source

Una vez definido el gestor de sonido CSystem_Mixer, se pueden definir los componentes que van a representar fuentes de sonido dentro del juego. 

Image

 

Las principales características de un sonido son las siguientes:

  • Frecuencia
  • Volumen
  • Silenciado/No silenciado
  • Pista de música o no (no es sonido 3D, sino mono).
  • Pista tipo bucle o no (repetición continua).
  • Empezar o no a sonar nada más cargar la estancia.
  • Afección o no por el tiempo (modifica la frecuencia de manera interna dependiendo del tiempo)
  • Reproducir o no en todas partes.
  • Distancia máxima de reproducción (mínimo volumen por degradación).
  • Distancia mínima de reproducción (máximo volumen por degradación).

Las operaciones básicas para realizar con este componente son:

  • Cambiar el sonido (fuente, recurso).
  • Reproducir el sonido de manera estática (Play(), requiere bindear con Bind() el sonido antes de usarlo). Es más eficiente para casos en los que se usará el sonido varias veces, de manera continua. Nota: Un sonido que ha sido bindeado debe ser desbindeado (UnBind() de manera manual, ya que el recurso permanecerá ocupado hasta su liberación).
  • Reproducir el sonido una única vez (PlayOneShot(), no requiere bindear). Es más eficiente para casos en los que se usará el sonido pocas veces, de manera esporádica.
  • Reproducir en un determinado punto.
  • Pausar, parar, rebobinar, etc.
  • Bindear a un buffer del sistema CSystem_Mixer, y desbindear el buffer ocupado.

Para entender las solicitudes de buffer con Bind() y UnBind(), simplemente basta con pensar que un sonido no es más que una estructura de datos sencilla, sin gestión de sonido. Para que funcione, una entidad externa (CSystem_Mixer), debe ser capaz de proporcionar los medios necesarios para reproducir el sonido deseado. Para ello, proporciona una serie de buffers o “sources” para almacenar sonidos. Si se pide registrar un buffer con Bind(), el sistema guardará el sonido en el buffer para un uso cómodo y rápido, evitando esperas por el movimiento de sonido entre buffers. Así, es el usuario el que decide como gestionar el sonido, de manera que, manualmente, deba liberar los recursos que quiera (con UnBind()). No obstante, un sonido bindeado sólo se prodrá reproducir una vez cada vez, haciendo imposible reproducir un sonido varias veces (como disparos consecutivos).

Por otra parte, las acciones del tipo PlayOneShot() no requieren del uso de Bind(). Esto reside en que, de manera automática, se solicita un buffer temporal en el sistema CSystem_Mixer, y una vez acabado, se libera el recurso de manera automática. Por desgracia, este tipo de sonidos no se pueden modificar de manera dinámica, por lo que no se verán afectados por cambio de sonido, u otros elementos. Esto sí que permite repetir sonidos de manera continua (disparos, etc). Se recomienda usarlo para sonidos cortos.

Manual de usuario y CMake

Brevemente, diré que hemos empezado a realizar un pequeño manual de usuario para guardar todo el contenido relativa a la documentación general del proyecto. Además, más adelante, intentaremos generar documentación para el código con doxygen.

Finalmente, hace un rato he estado indagando (de manera frustrante, la verdad) con CMake, y creo que el proyecto ha sido puesto a punto para funcionar correctamente con cmake, incluyendo buscadores de dependencias (OpenGL, SDL2, Assimp, etc.).

Esperamos tener más tiempo para seguir trabajando en el proyecto, y poder aportar nuevas noticias al blog con calma.

Sin tiempo

Image

 

Simplemente, quería poner un mensaje de notificación para decir que tenemos muy poco tiempo para el proyecto gracias a la cantidad absurda de prácticas de este cuatrimestre.

Esperamos tener algo más de tiempo, por lo menos para documentar lo que tenemos hecho, y seguir implementando contenido.