SoloCodigo

Hola jomeron,

Desde C has de evitar a toda costa el uso de la función system porque es un grave problema de seguridad (es fácil escalar privilegios en función de los permisos del ejecutable). Para hacer lo que deseas has de, si no encuentras una librería que lo haga por ti, abrir un socket y transmitir los datos tú mismo. Una sesión telnet no es más que un socket abierto que redirige a la máquina remota todo lo que le llegue por stdin y envía a stdout todo lo que reciba. De esta forma no tienes más que enviar los datos necesarios y esperar las respuestas adecuadas para realizar las operaciones a través del socket.

Por otro lado, es posible que el router tenga instalado un agente SNMP. Si así es, consulta las MIBs que implementa y si hay alguna opción para gestionar el rearranque empleando esta funcionalidad, que sería lo más correcto.

Recibe un cordial saludo,

Rubén

Hola Pinush,

Yo, en tu situación, te recomendaría el formato para modelos md3. Es el empleado por Quake 3, mejor que el md2, y aún así relativamente sencillo de emplear. Respecto al formato de mapas emplea también el de Quake 3, pues no es complejo (deberás leer sobre los árboles BSP) y, lo más importante, tienes infinidad de artículos y ejemplos sobre él, además de todo tipo de mapas listos para usar y editores para crear los tuyos propios.

Cuando hayas acabado por completo ese juego puedes comenzar a fijarte en formatos más avanzados, como los de Doom 3, o crear los tuyos propios.

Un cordial saludo,

Rubén

Hola,

En teoría la razón de ser de la memoria compartida es la de comunicación entre procesos y no deberías tener ningún problema, ya que los identificadores se heredan entre procesos de la misma jerarquía. De todas formas eso que dices yo lo implementaría empleando tuberías para pasar datos entre el backend y el gui con un sencillo protocolo binario, que te va a ser más fácil de depurar y el código te va a quedar más organizado.

Un saludo,

Rubén Moreno

Es cierto que los comandos son cripticos para que sea dificil de entender ?

Hasta donde yo sé, son crípticos para que sean rápidos de teclear.

Por que hicieron el C para hacer el UNIX ?

Para tener una base de código fácilmente portable entre diferentes arquitecturas hardware.

Tenia sentido en la epoca de las mainframes (una maquina grande..muchas pequeñas) pero ahora ?

¿Por qué no? Otro sistema operativo más donde elegir. No está especialmente orientado a ese tipo de entornos.

Un saludo,

Ruben3d

algun otro juego programado en asm

Todos los desarrollados por Chris Sawyer (Transport Tycoon, RollerCoaster Tycoon, Locomotion) están implementados en un 95% en ensamblador (hombre paciente y habilidoso).

Un saludo,

Ruben3d

Hola a todos,

La verdad es que me alegra ver que la gente tenga iniciativa y ganas de emprender un proyecto común. Me gustaría poder contribuir desde un punto de vista más bien activo pero, francamente, estoy más bien limitado de tiempo. Aún así, intentaré contribuir con mi humilde opinión y experiencia.

Como ya han mencionado muchos otros antes que yo el llevar a término una empresa de semejante envergadura no es tarea fácil y muchos son los escollos que pueden aparecer en el camino que impidan que el barco llegue a puerto. Es por éllo que sugeriría dedicar un tiempo inicialmente a intentar preveer algunos de estos escollos para poder, dado el caso, salvarlos hábilmente. Ésto no nos preparará para todas las posibles eventualidades, pues siempre hay un abanico de posibles problemas no predecibles, pero al menos ayudará a reducir su número.

Pero, ¿qué problemas pueden surgir que podamos predecir? Tal vez al principio no sea fácil identificarlos, pero tras la experiencia de varios proyectos, o bien el haber seguido el desarrollo de otros, se puede estar en posición para tener una visión más amplia de a qué nos podríamos tener que enfrentar.

No voy a extenderme más, y vamos a ver qué nos encontramos.

El primer problema que puede aparecer es el de no definir qué se quiere hacer en primer lugar, o bien definirlo de manera demasiado ambiciosa o amplia, de manera que se obtienen una infinidad de frentes de desarrollo que dan lugar a una gran cantidad de trabajo invertido sin llegar a tener nada que mostrar y que, probablemente, haya que desechar en función de cómo se desarrollen las cosas. Para evitarlo hay que invertir un tiempo inicial, más o menos largo, en definir con bastante detalle lo que se va a hacer. Qué se quiere. Cuando esté definido el qué, ya se pensará, en primer lugar, en la viabilidad de su ejecución y, si está dentro de los márgenes realistas, en el cómo. He visto ya bastantes respuestas que discuten la conveniencia de utilizar unas herramientas sobre otras, en diveross campos, pero todavía no he visto una visión clara de lo que se quiere llevar a cabo.

Uno de los primeros problemas que surgen también en los inicios, que suele manifestarse sin ser detectado durante la mayor parte de la duración del proyecto, hasta su final trágico, es la pérdida del rumbo. Suele aparecer cuando no se tiene claro a dónde se quiere ir o, más bien, no se sabe cómo llegar (no porque no se definiera en primer lugar, sino porque hay dificultades para medir la distancia al objetivo y la desviación). El objetivo a alcanzar suele estar en movimiento, y cada vez más alejado, pues siempre se le añaden nuevos y vistosos requisitos. ¿Cómo prevenir ésto? Mediante la imposición de hitos intermedios bien definidos. Si en la versión 0.3 han de estar las características A, B y C no se ha de empezar a implementar la característica D de la 0.4 hasta que no se hayan acabado, probado y validado, además de haber liberado la versión 0.3. Ésto es muy útil, pues se va contando con versiones intermedias estables más o menos funcionales que permiten ver el progreso, de manera que el propio equipo se sienta motivado al verlo (éste es un punto que trataré más adelante).

También está el problema de la falta de coordinación y organización. En muchas ocasiones se puede tender a un modelo 'todos echan una mano en todas partes' y no se organiza correctamente el trabajo. Es vital definir bien desde un principio el papel que cada miembro del grupo de desarrollo juega, y que haya una o más personas dedicadas exclusivamente a gestión y coordinación para minimizar al máximo las pérdidas de tiempo por comunicación de los desarrolladores (ya sean analistas, programadores, grafistas, compositores, etc). En caso de no seguir este mínimo de organización es muy probable que el equipo completo acabe enfrascado en discusiones monumentales sobre el diseño, nuevas características y cambios de rumbo que no llevan a ningún lado y lo único que se obtenga como resultado sea que los miembros acaben quemados.

Se puede hablar también de un problema menor: la estimación de tiempo optimista. Es muy común encontrar diálogos del tipo "¿Un sistema para gestionar dinámicamente bajo demanda todos los recursos? En una semana lo tengo". No he conseguido aún alcanzar a ver el porqué de esta tendencia, pero los desarrolladores de este tipo de proyectos suelen confiar mucho en sus capacidades: son demasiado optimistas, no son capaces de realizar estimaciones realistas. Consejo: Como norma general, cuando preguntéis por una estimación de tiempo, tomad la respuesta, multiplicadla por dos y sumadle dos semanas. Tal vez lo consiga tener en ese nuevo marco de tiempo recién calculado, pero irá muy justo.

Existen muchos más posibles problemas, pero ya sólo me pararé a advertir de uno más, el más peligroso y común, ya mencionado anteriormente: el desinterés. Más del 80% de las personas que inicialmente emprendieron el proyecto conjuntamente desaparecerán, algunos de éllos como tragados por la tierra. Y ésto es una realidad, y hay que tenerlo en cuenta desde el principio. Se ha de buscar un modelo de desarrollo poco centralizado en torno a personas concretas, en el que las tareas más importantes no dependan de un sólo desarrollador cuya marcha implicara dejar a la deriva el proyecto, o bien documentar más o menos exhaustivamente todo lo desarrollado. Frases como "Se fue y era el único que sabía cómo funcionaba nuestro motor 3D" no son nada deseables. De aqui se extrae que es importante tener un equipo bien balanceado, para evitar situaciones al estilo "Era el único programador, el resto hacíamos mapas y gráficos, pero desapareció y nos quedamos sin nada". Es por todo ésto que hay que mantener un interés alto en el proyecto, y qué mejor para mantenerlo que empezar a poder mostrar progresos que funcionen correctamente, para lo cual ayudan los puntos anteriores.

A lo largo de esta réplica en la discusión he querido contribuir a este joven proyecto de la mejor manera que se me ha ocurrido: intentando dar soluciones a los problemas más comunes que es probable que aparezcan. Es cierto que se podría hablar largo y tendido sobre todo ésto, pero creo que con una leve reflexión sobre estos puntos no es difícil ver problemas derivados de éstos.

Para cualquier cosa que necesitéis estaré por aqui, espero (si mi vida me deja tiempo).

Un saludo,

Ruben3d

Busco Compañeros En Alcala De Henares

Vivo ahí. Si quieres charlar o consejo sobre estos temas no dudes en escribirme.

Un saludo,

Ruben3d

Tienes un tutorial que versa sobre lo que preguntas aqui (picking):
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=32

Un saludo,

Ruben3d

Hola,

Te puedo hablar de mi opinión indirecta sobre estas librerías, pues no las he llegado a emplear, aunque sigo de cerca su desarrollo.

Crystal Space es la más antigua. Tiene ya bastantes años desde que se empezó a desarrollar. La verdad es que no veo que sea para principiantes. Inicialmente tenía tan sólo un renderer por software y no se tardó en añadirle uno por hardware basado en OpenGL. Tras unos años se empezó el trabajo en un nuevo renderer por hardware con capacidad para sombras dinámicas, dot3 bump mapping, y demás tecnologías gráficas de moda en estos tiempos gracias a los motores de Doom 3 y Source. Sin embargo el API no es claro. Pasa como con el API de Windows: se lleva heredando desde hace muchos ñaos y tanto cambio interno ha hecho que sea un pequeño infierno. Actualmente están en proceso de limpieza.

Por otro lado Irrlicht tiene un API más limpio y de diseño más moderno. Aún se mantiene su antigo renderer por software pero éso no resta legibilidad al resto del API. La verdad es que no lo conozco tan a fondo pero no tiene mala pinta. Al menos tienen librería de widgets gráficos, que resuelve parte de tus necesidades.

Para ser sinceros yo emplearía Ogre 3D. El API tiene un excelente diseño orientado a objetos y es fácil de manejar. Además es bastante estable y maduro y ya existen numerosos proyectos comerciales que lo emplean.

Espero que ésto te haya servido un poco de guía.

Un saludo,

Ruben3d

Hola,

La verdad es que nunca llegué a acabar el artículo completo por falta de tiempo, así que sólo tuve en un estado presentable las primeras partes de introducción básica. Desde luego, los quaterniones son un tema más avanzado con respecto a lo anterior y hubiera ido justo al final (de hecho no encontré interés en el tema por parte de la gente).

Si aún no has encontrado información útil al respecto dimelo y trataré de hacerte aqui algunas anotaciones simples que vayan exactamente al grano (con un poco de ayuda por tu parte: ¿el concepto de números complejos e hyper-complejos lo conoces ya? ¿conoces ya qué es y cómo se opera con un quaternión y sólo te falta saber cómo aplicarlo a tus necesidades? Es por ajustarme al máximo a tus necesidades).

Un saludo,

Ruben3d

Hola,

El error del enlazador significa que no has definido la implementación de una función declarada en el fichero de cabecera. En tu caso has declarado:
pero en el fichero de implementación has implementado:

Fíjate en el const del método. En verdad estás implementando un método diferente al que has declarado.

Un saludo,

Ruben3d

Hola,

La ruta relativa al abrir un archivo es relativa al directorio de trabajo de la aplicación (que ya han posteado cómo obtener), no al directorio en el que se encuentra el binario que se está ejecutando. Lo que has de hacer es obtener el directorio en el que se encuentra el binario y concatenarlo con tu ruta relativa para no tener problemas derivados de tu directorio de trabajo en el momento de la ejecución.

Un saludo,

Ruben3d

Hola,

Recuerda los parámetros más habituales de la función main de una aplicación en C/C++:
argc es el número de elementos del vector de cadenas argv. En este vector se almacena en la primera posición (0) el nombre del ejecutable y en el resto sus posibles parámetros, así que el valor de argc será como mínimo 1.

Un saludo,

Ruben3d