Reporte

Saludos a todo el mundo.

Una vez más me encuentro escribiendo sobre mis actividades realizadas en lo que va de mi anterior mensaje.

De manera general mis dos grandes actividades se han centrado en estudiar y desarrollar el patrón de modelo vista controlador en c++.

Básicamente para lograr implementar un software interactivo sobre la librería que e estado desarrollando, la cual es la parte de la lógica del susodicho patrón.

Como bien saben  para lograr una interfaz responsiva resulta necesario tener el programa en diferentes hilos de ejecución, con lo que aparece el tema de la concurrencia, y por el otro lado surge la difícil tarea de desarrollar un visor de visualización lo suficientemente rápido para tener practicas interactivas de relevancia biológica, es decir con un gran numero de elementos interactúantes en el espacio y el tiempo.

Por parte de la vista, e estado analizando diferentes librerías graficas con el fin de encontrar la mejor opción en cuanto a rendimiento y portabilidad.

Con respecto a la vista estas son las librerías que e comenzado a inspeccionar:

-OpenScenGrap: este es una librería de visualización científica, open source, que se ve bastante bien, utilizada por varias compañías grandes, aunque la documentación esta media chafa, es multiplataforma, y si aguanta arrays de veras grandes podría ser lo mas parecido a lo que necesitamos.

-Glut (openGl multiplataforma):

Glut es una librería que se encarga de efectuar los ajustes necesarios para la creación y manejo de ventanas, en diferentes sistemas operativos, utilizando el estándar openGL por desgracia no es open source, y en la parte de los controles interactivos de la imagen esta mas lento que una tortuga.

-Coin: es un software desarrollado por una compañía fresa para la visualización científica, el cual cuenta con una variante open source, por desgracia no parece documentado nada, así que apenas ando viendo que tal funcionan los ejemplos.

-VTK: es una librería de visualización de largos archivos de datos científicos, utilizada por varias universidades y creo que la NASA, se ve bastante bien, es open source, aunque por desgracia los manuales cuestan una lana, como 75 dólares, y me párese que no es tan buena para la animación de las imágenes en base a un flujo cambiante de datos, es mas para medicina y mapas (datos fijos) aunque una universidad tiene una variante de análisis de fluidos que se ve muy parecido a lo que me gustaría que hiciera la librería de autómatas. 

-DirectX:

DirectX es la prima dona de los video juegos, la verdad esta bastante bien hecha y es fácil de conseguir sus libros, y cuenta con una documentación bastante buena, lo malo es que es anti open source, y solo corre en Windows.

No queda claro que sea lo mejor o simplemente la mayoría de las maquinas del mundo tienen Windows y los vendedores de video juegos y de hardware se ven obligados y tentados a hacer drivers, hardware y juegos solo por ello.

Como sea ya se como hacer lo básico para hacer el automata en 2 dimensiones, y una vista demo aunque sea solo para ver si corre bien me resulta demasiado tentadora. (Tanto en openGL como en directX, existen arrays especificos para contener muchos elementos, lo cual creo aumenta mucho el desempeño de las librerias, aunque todavía me falta un poco para llegar a dominar sus respectivas especificaciones).

Con respecto a la concurrencia esta son las librerías que e empezado a inspeccionar:

-ZThread, en cuanto a diseño orientado a objetos esta me parece es la mejor planeada, y supuestamente funciona en Windows, y Linux, y a pesar de lograr compilarla, al correr los ejemplos de pensando en c++ como que los threads se pierden el espacio virtual, pero no se destruyen, así que algo raro pasa, y eso que los ejemplos y el capitulo del libro los ayudo a hacer el autor de la librería, claro todo funciona perfecto en Linux.

-MFC, están son las tétricas fundation class de Microsoft, y me temo que están súper raras y feísimas desde mi particular punto de vista, al menos en c++, ya que en c# se ven mucho mas bonitas, los threads aquí se dividen en worker threads, y user-interfaze threads, pero para c++ están mas feos que nada, cero orientación a objetos, en los worker threads funcionan solamente para funciones, como en c, es decir creas un thread para que ejecute una sola función, esta horrible, y aunque encontré unos wrapers para tener objetos threads, son freeware así que no me gusta nada, el interés surgía por la honda de hacer un interfaz de video juego de verdad con directX, pero están tan feos que ya no lo se bien.(aunque acabo de conseguir un articulillo de cómo hacer los wrapers para crear objetos threads, si ello funciona, creo que probare un patrón windowsero).

-Boost es una organización de miembros  del C++ Standards Committee Library Working Group para desarrollar nuevas librerías para c++ tiene aproximadamente 2000 miembros, dentro de boost se encuentran un montón de librerías útiles, open source claro, la de los threads, es la que intento utilizar para montar el patrón, a ver si pega con la vista en directX, aunque e de mencionar que también se hacer lo mismo con openGL en base a glut.

Además de contar con los threads, boost cuenta con la tan buscada librería de graficas, la cual cuenta con un chorro de algoritmos de teoría de graficas (los clásicos del camino mas corto entre nodos y así) para analizar y crear graficas especificas, el problemas es que crean un contenedor de tamaño variable (mucho mas lento que un array) para cada nodo de la grafica, lo que yo trate de evitar al máximo, para evitar tener miles de contenedores a la hora de crear una automata celular.

Como sea a la hora de los agentes me parece que va a venir como anillo al dedo, ya que los agentes van a estar cambiando de posición y el tener un contenedor dinamico para cada uno de los nodos no parece nada descabellado.

Y además me parece que la estructura de interacción de los agentes también se puede ver como una grafica.

Ya se vera como resulta, con suerte y me da tiempo de hacer un pequeño modelo con las dos variantes, una con boost y otra sin la librería para la parte de la lógica, y si no se da diferencia significativa en los tiempos, pues utilizar boost por la gran cantidad de algoritmos con los que ya se cuentan.

Hasta ahora todo a funcionado muy bien en windos y en Linux se habla mucho mas a favor de boost que posfix (o algo así), para ser utilizado por las clases bases de c++, ya que el comité anda buscando librerías para añadir por fin el multiproceso en c++ estándar. Por desgracia para jugar ping pong con dos threads hasta ahora solo e podido mandar los mensajes modificando variables estáticas, lo cual no me gusta tanto por que complicaría la posible creación (como me gusta soñar) de varias vistas y modelos para un mismo “juego” así que veremos como va la cosa.

Suerte a todos.

P.D. si se interesan por desarrollar algo en alguna de la librerías de las que hablo mándeme un mail y yo les digo que honda, donde conseguir el software ejem.. original y los respectivos libros que estoy siguiendo. Si se interesan en desarrollar en windos (claro), aunque en Linux, el c++ se ve que se da de maravilla, y todo menos directX es multiplataforma en lo desarrollado hasta ahora.

<  El Reporte de la Semana - Ouroboros o Algo Asi | Reporte Ouroboros  >