• Martes 30 de Noviembre de 2021, 04:11

Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.


Mensajes - Ruben3d

Páginas: [1] 2 3 ... 30
1
C/C++ / Re: Reinicio automático del router
« en: Jueves 9 de Abril de 2009, 04:41 »
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

2
OpenGL / Re: Proyección Ojo-Ventana
« en: Jueves 9 de Abril de 2009, 04:30 »
Hola Raul,

Te puedes ahorrar complicaciones si no tienes claros los conceptos si evitas el uso de glLookAt. Si defines tu cámara con un punto P, y unos ángulos de orientación (yaw, pitch y roll) puedes emular su uso, de manera más sencilla, creando las matrices de transformación adecuadas para la geometría, de forma que todo lo que introduzcas se sitúe delante de tu cámara (que nunca se moverá del origen de coordenadas). Este sencillo tutorial te enseña cómo moverte por el interior de un pequeño mundo 3D de esta manera: http://nehe.gamedev.net/data/lessons/le ... ?lesson=10

Un saludo,

Rubén

3
OpenGL / Re: Formato de archivo
« en: Jueves 9 de Abril de 2009, 04:23 »
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

4
GNU/Linux / Re: Ejecutar una aplicación desde un nuevo hilo creado con fork
« en: Martes 25 de Noviembre de 2008, 12:43 »
Puedes mantener la comunicación por tuberías tras lanzar el proceso con exec. ¿Cómo crees que funciona la propia shell, cuando haces llamadas del tipo 'cat archivo | grep "hola"'? En ese caso concreto lo que se hace es redirigir stdin y stdout a tuberías que heredan los procesos creados con exec desde los fork.

Un saludo,

Rubén

5
GNU/Linux / Re: Ejecutar una aplicación desde un nuevo hilo creado con fork
« en: Domingo 23 de Noviembre de 2008, 17:34 »
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

6
CSS / SASS / LESS / Re: Maquetación 3 Columnas <div>
« en: Domingo 10 de Febrero de 2008, 21:17 »
Three Column Layouts

Aunque hace bastante tiempo de este post dejo este enlace como referencia.

Un saludo,

Ruben3d

7
Otros Sistemas Operativos / Re: Unix Solo Hay Uno
« en: Martes 28 de Noviembre de 2006, 23:05 »
Citar
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.

Citar
Por que hicieron el C para hacer el UNIX ?
Para tener una base de código fácilmente portable entre diferentes arquitecturas hardware.

Citar
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

8
Programación de Videojuegos / Re: Estamos Creando Un Proyecto
« en: Martes 12 de Septiembre de 2006, 18:33 »
Cita de: "paulados"
muchas gracias por tu resumen
Me alegra que te sirviera de ayuda.

Por cierto, Isirius, los signos de puntuación están soportados en el foro.

Un saludo,

Ruben3d

9
ASM (Ensamblador) / Re: Juego En Asm?
« en: Martes 12 de Septiembre de 2006, 18:06 »
Citar
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

10
OpenGL / Re: Con Qué Lenguaje Está Hecho El Opengl?
« en: Martes 12 de Septiembre de 2006, 18:00 »
OpenGL es una especificación, así que no está hecho en ningún lenguaje, sino en un procesador de textos :P Las implementaciones más comunes creo que están en C y ASM, como ya se ha mencionado (al menos MESA sí está así).

Un saludo,

Ruben3d

11
Programación de Videojuegos / Re: Estamos Creando Un Proyecto
« en: Lunes 28 de Agosto de 2006, 23:56 »
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

12
Programación de Videojuegos / Re: Como Se Dice
« en: Lunes 28 de Agosto de 2006, 22:21 »
Citar
Si alguien conoce las equivalencias en español, por favor eche una mano

Bueno, voy a intentarlo.

milestone

Hito

Gameplay

Complicado de traducir a un sólo término. Representa el estilo de juego, de qué manera se juega. Se deriva de él la jugabilidad.

Playtesting

También complicado. Fase del beta (y a veces alfa) testing encargada del balanceo del juego, para que salga equilibrado. ¿Podría traducirse como balanceo del juego?

Render

Aqui me referiré a la nomenclatura que ha usado Discreet (inicialmente Kinetix, subdivisión de Autodesk) para sus versiones de 3dsmax en español. Recuerdo que en MAX 2 lo traducían por representación/representar y en versiones posteriores lo he visto castellanizado como renderizar (o éso, o lo he soñado).

Umm, no parece que haya tenido mucho éxito mi intento, pero espero que haya arrojado algo de luz.

Un saludo,

Ruben3d

13
Programación de Videojuegos / Re: Busco Compañeros En Alcala De Henares
« en: Lunes 28 de Agosto de 2006, 22:10 »
Cita de: "phoenixdss"
Busco Compañeros En Alcala De Henares
Vivo ahí. Si quieres charlar o consejo sobre estos temas no dudes en escribirme.

Un saludo,

Ruben3d

14
OpenGL / Re: Curvas
« en: Domingo 2 de Julio de 2006, 15:46 »
Como no des más datos...

15
OpenGL / Re: Saber La Coordenada
« en: Domingo 2 de Julio de 2006, 15:45 »
Tienes un tutorial que versa sobre lo que preguntas aqui (picking):
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=32

Un saludo,

Ruben3d

16
Programación de Videojuegos / Re: Mejor Lenguaje Para Crear Videojuegos
« en: Domingo 2 de Julio de 2006, 15:42 »
Hola,

su- tiene razón. Elije el lenguaje en el que más cómodo te sientas. Con que tenga alguna buena librería gráfica te es suficiente.

Un saludo,

Ruben3d

17
Programación de Videojuegos / Re: Game Engine 3d Para Principiante
« en: Domingo 2 de Julio de 2006, 15:37 »
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

18
Programación de Videojuegos / Re: Problemas Con Libreria
« en: Domingo 2 de Julio de 2006, 15:09 »
Hola,

Según puedo observar el mensaje de error parece estar incompleto. Es probable que exista algún error en el empleo de plantillas con lo definido en el fichero de cabecera que incluyes (que incluye su contenido desde otros, que suelen estar en includes/bits/*).

No has de añadir el .h a las cabeceras de STL, pues es el método antiguo de hacerlo previo a los espacios de nombres. Algunos compiladores siguen manteniendolo por compatibilidad con código antiguo, de manera que

<!--xc1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>XCODE </td></tr><tr><td id='XCODE'><!--exc1-->#include <iostream.h> // Deprecated
<!--xc2--></td></tr></table><div class='postcolor'><!--exc2-->

equivale a

Código: Text
  1. #include &#60;iostream&#62;
  2. using namespace std;
  3.  
  4.  

Espero que te sirva de orientación.

Un saludo,

Ruben3d

19
Programación de Videojuegos / Re: Tema Para Artículo
« en: Domingo 2 de Julio de 2006, 15:03 »
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

20
OpenGL / Re: Concurrencia Con Opengl
« en: Miércoles 10 de Mayo de 2006, 21:12 »
Hola,

Creo que la solución que propone PENTEX es la mejor y más lógica. Todos los sistemas de dibujo concurrentes que conozco la emplean: encargar a cierto hilo las tareas de pintado, que irá procesando consecutivamente.

Un saludo,

Ruben3d

21
C/C++ / Re: Problema Con Polimorfismos Y Clases Abstractas
« en: Domingo 30 de Abril de 2006, 19:27 »
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:
Código: Text
  1.  string aRistra();
  2.  
  3.  
pero en el fichero de implementación has implementado:
Código: Text
  1. string ComponenteNumero::aRistra() const
  2.  
  3.  

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

Un saludo,

Ruben3d

22
C/C++ / Re: Color En Visual
« en: Jueves 13 de Abril de 2006, 20:10 »
El mandar ejercicios viejos de otros por pereza es una práctica que por desgracia es llevada a cabo con demasiada frecuencia entre algunos profesores. Lo único que consiguen es que pierdas el tiempo intentando hacer funcionar código que quedó obsoleto hace más de diez años y que a la hora de la verdad ya no te servirá para nada, pues nisiquiera emplea librerías que hayan evolucionado hasta hoy en día.

Espero que tengas suerte.

Un saludo,

Ruben3d

23
C/C++ / Re: Fopen Como Saber Ruta Relativa?
« en: Jueves 13 de Abril de 2006, 19:57 »
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

24
C/C++ / Re: Color En Visual
« en: Martes 11 de Abril de 2006, 00:54 »
Las funciones que se ofrecen son un tanto avanzadas y más bien recuerdan a cómo se pintan los gráficos y se lee la entrada en una aplicación gráfica. Una función que borre la pantalla como tal no la recuerdo, pero puedes eliminar los caracteres a mano del buffer, o hacer un scroll de la pantalla entera:
http://msdn.microsoft.com/library/default...._s_contents.asp

Un saludo,

Ruben3d

25
C/C++ / Re: Consulta Sobre El Nombre Del Ejecutable
« en: Lunes 10 de Abril de 2006, 01:21 »
Hola,

Recuerda los parámetros más habituales de la función main de una aplicación en C/C++:
Código: Text
  1. int main(int argc, char* argv[])
  2. {
  3.     // ...
  4.     // return 0;
  5. }
  6.  
  7.  
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

Páginas: [1] 2 3 ... 30