|
|
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 ... 25 26 [27] 28 29 30
651
« en: Viernes 19 de Marzo de 2004, 22:10 »
El gimp lo he probado y es bastante bueno aunque aun esta lejos de llegar a la calidad de paint shop pro o photoshop (en mi opinion).
Deberías probar Gimp 2. Tiene bastantes opciones que no existen en Photoshop. Un saludo. Ruben3d
652
« en: Jueves 18 de Marzo de 2004, 13:35 »
Hola.
Lo que tienes que hacer es, en primer lugar, ir leyendo los n números. Una vez los tengas todos en un array, lo vas recorriendo y si está el elemento en el intervalo lo imprimes.
No debería costarte hacer esto, prácticamente es pasar lo que he dicho a código tal cual.
653
« en: Miércoles 17 de Marzo de 2004, 16:38 »
Sigraph (¿me quedó bien escrito?)
Casi, es "Siggraph". Un saludo. Ruben3d
654
« en: Miércoles 17 de Marzo de 2004, 14:59 »
Hola a todos. Estoy de acuerdo con los que han dicho que a los videojuegos aún les queda mucho por evolucionar. Actualmente no califico ninguno de los juegos que hay en el mercado como reales. Pueden tener un mayor o menor grado de realismo, pero no les puedo llamar reales. Yo creo que la evolución de los videojuegos en el ámbito gráfico va a detenerse cuando se llegue a imágenes que no se distinga si se trata de una fotografía o un vídeo o un juego (porque no puede ser más real que lo real). De momento esto sólo lo he visto en escenas generadas por 3dsmax, maya, o sw de este tipo (a horas de render por cuadro). Está claro que el hardware actual y el inmediatamente venidero no va a permitir esto. Por otro lado también se ha mencionado el tiempo de desarrollo de los juegos. Efectivamente, cada vez es más largo, pero esto no puede seguir así, pues hay que tener en cuenta los costes de desarrollo y las unidades que se esperan vender, para saber si el proyecto será viable. Actualmente, los equipos de los juegos que más tiempo llevan en desarrollo (Doom 3, HalfLife 2), no esperan recibir todos los ingresos de las ventas: también esperan vender licencias del motor a terceros, que desarrollarán juegos de muy buena calidad en tiempos máximos de 2 años (en el caso de Doom 3, se va a hacer Quake 4 con su motor). Pienso que llegará el día (no cercano) en el que apenas se desarrollen nuevos motores y se utilicen sólo los ya existentes, centrando el desarrollo en los modelos, mapas, argumento, etc., por lo que los desarrolladores serán grupos de artitas, no programadores, y ésta es la parte que fluye rápido (no hay que depurar las texturas  ), por lo que el tiempo de desarrollo no se disparará. Bueno, hay más aspectos que aún queda por mejorar de los juegos (la física, animación...) pero más o menos creo que con esto se entiende mi punto de vista. Un saludo. Ruben3d
655
« en: Miércoles 17 de Marzo de 2004, 14:21 »
Hola a todos.
He estado intentando encontrar información sobre cómo usar Triple Buffering con OpenGL bajo Windows y no he encontrado nada. En MSDN he visto la función wglSwapLayerBuffers, pero no me queda muy claro si es la adecuada para el triple buffering o es su finalidad (no lo menciona por ningún lado, además es engorrosa de utilizar).
¿Alguien sabe cómo hacer Triple Buffering con OpenGL bajo Windows?
Muchas gracias a todos.
Ruben3d
656
« en: Martes 16 de Marzo de 2004, 14:59 »
Hola.
Sé cómo hacerlo si estás trabajando con Unix (o Linux). Así que si así es dimelo y te posteo cómo se hace.
Un saludo.
Ruben3d
657
« en: Martes 16 de Marzo de 2004, 14:40 »
Bueno, me gustaría añadir:
- The Gimp: Excelente programa de edición fotográfica, equivalente a Photoshop, pero gratuito (licencia GNU).
- Blender 3D: Programa para modelado 3D (no especialmente orientado a juegos). También bajo licencia GNU.
Un saludo.
Ruben3d
659
« en: Sábado 6 de Marzo de 2004, 00:24 »
Hola.
Lo que pides se implementa de manera diferente estés en Windows o estés en Unix. ¿Qué sistema operativo estás utilizando?
Un saludo.
Ruben3d
660
« en: Viernes 5 de Marzo de 2004, 16:04 »
Hola a todos.
Me he instalado la última versión de GIMP y he estado probando su funcionamiento. Ha mejorado bastante desde las versiones 1.x, pero he encontrado un problema: ¿Cómo pinto directamente en el canal alfa de una imagen? Sé que se ha de poder hacer (en Photoshop es muy sencillo, no hay más que seleccionar el canal y pintar), sin embaro soy incapaz de encontrarlo. La única manera en la que lo he conseguido hacer es creando una máscara a la capa que hace de fondo y pintando en ella, de manera que el canal alfa se actualiza sólo. ¿No hay alguna manera de evitarse esto y pintar directamente en el canal alfa?
Un saludo.
Ruben3d
661
« en: Viernes 5 de Marzo de 2004, 15:46 »
Hola.
La función que mencionas es opendir(), pero es específica de sistemas basados en unix.
Un saludo.
Ruben3d Estemmm... No
Estemmm... Sí Es compatible con POSIX y Win
Si mal no recuerdo, la compatibilidad con POSIX de sistemas win32 no es completa. Sólo tiene implementadas algunas funciones, principalmente de manejo de ficheros. La función opendir() y demás declaradas en dirent.h fueron implementadas en 4.3 BSD para facilitar el acceso a la información de cada directorio. Después también la adoptaron en UNIX System V, ya que facilitaba la portabilidad del código. Así, acabó en todos los Unix. Ahora bien, si programas en Windows NO tienes esas funciones (a no ser que coja alguien y le haga un wrapper al API, pero eso lo hace cualquiera, quiero decir, no es oficial). Se puede comprobar probando opendir en el compilador de Microsoft. No lo reconocerá. Tampoco está en MSDN (y si una función del sistema no está en MSDN es que no existe). La única referencia a opendir en MSDN está en la página de guía de migración de código de Unix a Win32, donde explica cómo sustituir la versión de UNIX por las funciones de microsoft (de esa página ha salido el código posteado más arriba). Un saludo. Ruben3d
662
« en: Viernes 5 de Marzo de 2004, 14:00 »
Hola.
Te hago una observación, ya que he visto la función termina. Si cambias el primer parámetro de FindFirstFile puedes seleccionar la extensión de los archivos que busca.
Un saludo.
Ruben3d
663
« en: Jueves 4 de Marzo de 2004, 17:41 »
Hola.
La función que mencionas es opendir(), pero es específica de sistemas basados en unix.
Un saludo.
Ruben3d
665
« en: Martes 2 de Marzo de 2004, 13:20 »
Muchas gracias.
Un saludo.
Ruben3d
666
« en: Lunes 1 de Marzo de 2004, 18:39 »
Hola. Te pego un pograma sacado de MSDN, cuya misión es listar todo el contenido de un directorio, entrando recursivamente en los subdirectorios. No creo que tengas que modificarlo mucho para adaptarlo a tus necesidades. #include <windows.h> #include <stdio.h> void ScanDir(char *dirname, int indent) { BOOL fFinished; HANDLE hList; TCHAR szDir[MAX_PATH+1]; TCHAR szSubDir[MAX_PATH+1]; WIN32_FIND_DATA FileData; // Get the proper directory path sprintf(szDir, "%s\\*", dirname); // Get the first file hList = FindFirstFile(szDir, &FileData); if (hList == INVALID_HANDLE_VALUE) { printf("No files found\n\n"); } else { // Traverse through the directory structure fFinished = FALSE; while (!fFinished) { // Check the object is a directory or not if (FileData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) { if ((strcmp(FileData.cFileName, ".") != 0) && (strcmp(FileData.cFileName, "..") != 0)) { printf("%*s%s\\\n", indent, "", FileData.cFileName); // Get the full path for sub directory sprintf(szSubDir, "%s\\%s", dirname, FileData.cFileName); ScanDir(szSubDir, indent + 4); } } else printf("%*s%s\n", indent, "", FileData.cFileName); if (!FindNextFile(hList, &FileData)) { if (GetLastError() == ERROR_NO_MORE_FILES) { fFinished = TRUE; } } } } FindClose(hList); } void main(int argc, char *argv[]) { char *pszInputPath; char pwd[2] = "."; if (argc < 2) { printf("Argument not supplied - using current directory.\n"); pszInputPath = pwd; } else { pszInputPath = argv[1]; printf("Input Path: %s\n\n", pszInputPath); } ScanDir(pszInputPath, 0); printf("\ndone.\n"); }
Un saludo. Ruben3d
667
« en: Lunes 1 de Marzo de 2004, 18:32 »
Hola. Me he fijado en que cuando uso la tag CODE para insertar código el único beneficio que obtengo es tener fuente de paso fijo y se me come todas las tabulaciones, dejando el código sin tabular y de más difícil comprensión. ¿No se podría arreglar esto? Además, si no es pedir mucho, también podría colorear sintaxis, al estilo de los foros de GameDev.net  . Un saludo. Ruben3d
668
« en: Lunes 1 de Marzo de 2004, 18:23 »
Hola a todos.
Me he instalado el Dev-pas (la versión 1.9.2 con FreePascal) y no consigo establecer el directorio de trabajo de los proyectos. Siempre es el directorio de instalación del entorno y no consigo cambiarlo, aunque cree el proyecto en otro directorio. ¿Alguien podría indicarme cómo cambiarlo? También me vale poder averiguar en qué directorio está el ejecutable desde el código.
Un saludo.
Ruben3d
669
« en: Domingo 29 de Febrero de 2004, 21:26 »
Hola. He hecho dos pequeñas funciones en C++ con ensamblador. Se comportan igual, dividiendo f1 entre f2 y retornando el resultado. El código es éste: inline float ASM_Test(const float f1, const float f2) { float f3; __asm { fld f1 fld f2 fdivp st(1),st fstp f3 } return f3; } inline float ASM_Test2(const float f1, const float f2) { float f3; __asm { fld f1 fdiv f2 fst f3 } return f3; }
La única diferencia es que la primera deja la pila como estaba y la segunda no lo hace, aunque son menos instrucciones. ¿Es necesario dejar la pila como estaba? Un saludo. Ruben3d
670
« en: Domingo 29 de Febrero de 2004, 20:48 »
Hola. En el stencil buffer no se guarda qué parte está a la sombra de la manera normal, con una imagen en escala de grises. Mientras se está ejecutando el algoritmo se usa como si fuera un acumulador, sumando 1 si se da cierta condición y restando 1 si de da cierta otra en cada píxel concreto. De esta manera, cuando el algoritmo ha terminado, si el valor de la celda de cada píxel es diferente de cero quiere decir que está a la sombra y si es igual a cero quiere decir que está iluminado. Así, es como si la máscara fuera de un bit de profundidad de color, por lo que sólo hay dos estados: iluminado y a la sombra. Por ello no se puede hacer lo que me dices. Se me olvidó decir que en Doom 3 se hace una pasada por cada luz, para que los lugares en donde se proyecten dos o más sombras estén más oscuros. ¿Esto generaría aún más sobrecarga al generar la niebla? También se me olvidó decir que Doom 3 usa OpenGL, aunque mencioné un ejemplo de DirectX para que se viera el efecto. En esta dirección está bastante bien explicado cómo funciona el algoritmo: The Theory of Stencil Shadow VolumesUn saludo. Ruben3d
671
« en: Sábado 28 de Febrero de 2004, 17:18 »
Hola a todos. Estaba navegando por internet, viendo información sobre Doom 3, cuando vi un screenshot del juego que me llamó increiblemente la atención. Sorprendentemente no fue uno lleno de efectos y explosiones, ni geometría increiblemente detallada, ni cosas de este estilo. Fue uno relativamente simple, con unos monstruillos que parecen cabezas con patas, y niebla. Hasta aqui todo normal, pero lo sorprendente es que combinaba stencil shadow volumes con niebla!  El algoritmo que genera las sombras obtiene como salida, por decirlo de manera simple, una máscara que indica qué partes de la imagen en pantalla están a la sombra de una luz (el lugar donde esto se guarda es el stencil buffer). Teniendo esto, lo que se hace es oscurecer en la imagen final las partes que el stencil buffer indica que están a la sombra. De esta manera no se sabe a qué distancia están las sombras en el espacio, pero sí se sabe qué parte de la imagen final está a la sombra. Por ello, en todas las demos que combinan este tipo de sombras con niebla se puede ver cómo cuando la sombra se aleja dentro de la niebla no se ve afectada por ésta y permanece completamente negra (se puede ver esto en el ejemplo ShadowVolume para Direct3D, en el SDK de DirectX). Sin embargo, en el screenshot que vi esto no sucede. Hay niebla y las sombras que hay lejos se ven afectadas por ésta. Así, llega mi pregunta: ¿Cómo hace Doom 3 para combinar stencil shadow volumes y niebla? Lo único que se me ocurre es hacer una última pasada, después de pintar las sombras, generando a mano la niebla a partir de los valores que haya en el z-buffer, pero me da la sensación de que esto será muy ineficiente. ¿Hay algún método que no conozca? ¿Se trata de alguna extensión de las nuevas tarjetas? ¿Se optimizaría con un FragmentProgram? Uff, sobredosis de preguntas  . Espero que alguien me pueda responder a esto. Un saludo. Ruben3d PD: Adjunto la imagen, claro. No me deja usar el tag IMG  http://common.ziffdavisinternet.com/util_g...&i=50697,00.jpgy el link a la web donde está: http://www.computergaming.com/slideshow_vi...00&po=36,00.asp
672
« en: Sábado 28 de Febrero de 2004, 16:23 »
con el c++ de Builder
Prueba a postear esta pregunta en el foro de C++ Builder. Un saludo. Ruben3d
673
« en: Sábado 28 de Febrero de 2004, 13:33 »
Sorry , ya dije q no se si estaría libre de errores y q me basaba en una "idea" que tuve en Java...
 Siento haber parecido un poco brusco. No lo pretendía. Un saludo. Ruben3d
674
« en: Sábado 28 de Febrero de 2004, 13:12 »
class A { private: A instancia=null; A(); public: static A getInstancia(); }; A A::getInstancia() { if(instancia == null) return new A(); else return instancia; }
Francamente, me gustaría saber si alguno de vosotros ha compilado ese fragmento de código, porque según veo ha de dar errores de todo tipo por todas partes. Además, si consiguieras hacer eso funcionar generarías una nueva instancia en cada llamada a getInstancia(). Una forma correcta de hacer eso (que se llama singleton) y bastante probada es hacer esto: // En el fichero .h class A { public: // Métodos que hagan falta // ... ~A() { /* código destructor */} // Retorna la única instancia de la clase static A *Instancia() {return &m_A;}; private: static A m_A; A() { /* código constructor */ }; // El constructor de copias tambien debe // ser privado A(const A &); // Otros miembros privados // ... }; // En el fichero .cpp // Para dar presencia física a la variable // estática A A::m_a; // Implementar aqui el resto de métodos de la clase
De esta forma, para acceder a la instancia se podría hacer esto en el código: A::Instancia()->método1(); o también A *pA = A::Instancia(); pA->método1(); pA->método2();
Hay que tener en cuenta que no hay que liberar los punteros, ya que apuntan a m_A, que será automáticamente liberado cuando sea llamado el destructor de la clase. Esto tiene el problema del orden de inicialización si se llaman entre sí varias clases de este tipo en los constructores, pero se puede arreglar moviendo m_A al interior de Instancia() en forma de variable estática, por lo que será inicializado en la primera llamada a Instancia(). Creo que no he cometido ningún error en el código. Si no es así que alguien me lo diga. Espero que esto te haya servido de ayuda. Un saludo. Ruben3D
675
« en: Miércoles 25 de Febrero de 2004, 20:20 »
Hola. Parece que el cálculo del coste en el caso medio de la ordenación por Shell no es tarea sencilla. Aqui te dejo un estracto de un libro: Se cree que el tiempo de ejecución del caso promedio de la ordenación de Shell, usando incrementos de Hibbard, es O(n^(5/2)), con base en simulaciones, pero nadie ha podido demostrarlo. Pratt demostró que la cota O(n^(3/2)) se aplica a un amplio conjunto de secuencias de incrementos.
Del caso promedio no tengo más, sólo del caso peor. Prueba a buscar por Pratt y Shell Sort en google. Un saludo. Ruben3d
Páginas: 1 ... 25 26 [27] 28 29 30
|
|
|
Mostrar Mensajes
