Requerimientos:

Low-End:
1.5GhzP4 or equivalent
512MB Ram
Geforce4 Ti 4800 or Radeon 9500

Mid-Range:
2.4GhzP4 or equivalent
1GB RAM
Geforce5950 or Radeon 9800 Pro/XT

High_End: Aka Hardware that doesn't exist, but best guess anyway
3.4GhzP4 or AMD equivalent
2GB RAM
GeForce 6800 Ultra or Radeon X800 XT PE.  

 

No tiene sentido. TODO se hace en GPU así que no hay paralelismo.

¿Como que no hay paralelismo?

Mientras el GPU procesa un grupo de vértices y/o índices, tú le estás copiando otro grupo, allí es donde se produce el paralelismo.

Saludos.

 ¿Que ventajas puede traer el uso de cubemaps para la creación de skyboxes?

 Quería pedirles un consejo, estoy creando un sencillo juego de fútbol y me quedé pensado en como implementar dos aspectos:

1. Las texturas de los jugadores:

  a. ¿Deberían llevar ya el número? -> Esto acarrearía la carga de un número muy grande de texturas. (mayor tiempo de carga, mayor uso de memoria de video, menor tiempo de dibujado de frame).

  b. Otra opción es que cada jugador posea dos texturas: la camiseta (común a todo el equipo) y encima la textura del número -> Esto acarrearía un incremento del tiempo de dibujado del frame por deber aplicar dos texturas en lugar de una. (menor tiempo de carga, menor uso de memoria de video, mayor tiempo de dibujado de frame (tal vez imperceptible)).

¿Qué es mejor? Yo me inclinaría por la segunda opción.

2. La cancha: ¿Cómo dibujarla?
  a. Creo que conviene partirla en pequeños cuadrados (formados por dos tris) de un tamaño específico (por ejemplo: la cancha podría tener 8 x 12 cuadrados). De este modo se reutilizaría partes de texturas utilizando menos memoria y además se podría hacer uso de mipmaps para los cuadros de cancha lejanos a la cámara.

  b. La segundo y rudimentaria opción sería que fuese sólo un gran rectángulo texturado con una textura de al menos 512x512.

¿Qué me dicen ustedes?

 Estoy teniendo problemas en la creación de librerías estáticas con Visual C++. El problema en cuestión es que no se como exportar las clases que deseo se vean desde afuera (es decir, las clases que puedan ser instancias desde el programa que use la librería).

Haciendo DLLs es sencillo, sólo utilizo el clásico __declspec(dllexport) para exportar y el __declspec(dllimport) para importar pero esto no funciona para librerías estáticas.

También probé especificando un archivo .def pero no tengo clara la sintáxis para indicar que se exporte una clase (¿debo indicar método por método?).

En fin, quería saber si ustedes conocían algún modo sencillo de hacer esto. Recuerdo que alguna vez lo había hecho pero no recuerdo como  (nooo)  ¡hace tanto que no creo libs estáticas!

Gracias.

 ¿Alguien sabe si en plataformas de 64 bits los números enteros (de tipo fundamental int) en lenguaje C/C++ dejan de ser 4 bytes?

Recuerdo que el plataformas de 16 bits (época 286 para atrás) el int eran 2 bytes. Tengo claro que la especificación del lenguaje sólo asegura que:

sizeof(short) <= sizeof(int) <= sizeof(long)

Pero también he visto por ahí el agregado de int64 ¿es esto oficial o es un typedef?

Mi duda surge debido a que si se cambia los short de 2 a 4 bytes, los int de 4 a 8 y los long de 4 a 8. Tendría que modificar un montón de programas (especialmente aquellos que levantan estructuras de archivos).

 Muchísimas gracias a todos. Me han sacado una duda.  (ole)  

 No me queda claro para que se utilizan los pesos en la animación esqueletal. He animado modelos de Half-Life pero sin hacer uso de este tipo de información, o sea, cada vértice posee un hueso relacionado a él y aplico las transformaciones de estos huesos antes de procesar los vértices.

Entiendo que por medio de los pesos un vértice podría estar relacionado a más de un hueso y tener distintos niveles de influencia con cada uno de ellos ¿pero con que fin? ¿que efecto podría lograr? ¿porque el Half-Life no posee esta información y aún así todo se anima correctamente?

Desde ya cualquier información que tengan al respecto es bienvenida.

 ¿Alguien conoce algún tutorial donde explique como leer los mapas bsp de Half-Life?

He encontrado el formato de mapas bsp de Quake3 en http://www.gametutorials.com pero nada de Half-Life.

Cualquier información estaré agradecido.

 Porque no le echás una ojeada a los documentos de esta página

http://www.nma-fallout.com/article.php?id=1592

son la biblia del fallout, allí cuenta algunos detalles de implementación (entre otras cosas el sistema de combate). Puede ser una buena guía en que basarte.

También podrías conseguir las guías de AD&D.

 ROL: Arcanum  (ole)  

 C# es un lindo lenguaje, la pregunta es ¿está preparado para la creación de juegos AAA?

Yo creo que no. Aunque usualmente estas discusiones suelen ser muy provechosas y se reparten buenos argumentos de ambos lados.

Managed DirectX es sin dudas una interfaz mucho mas sencilla que (unmanaged) DirectX, es básicamente lo mismo, las clases se mapean casi uno a uno y los métodos cuando no son iguales son muy similares. Pero posee como positivo:

Nombres sencillos (que no incluyen la maldita versión con él)
Ej: en lugar de un "LPDIRECT3DDEVICE8" tenemos un sencillo "Device".

Propiedades en vez de métodos.
Ej: En lugar de deber hacer

pDevice->SetRenderState(D3DRS_ZENABLE, D3DZB_TRUE);

simplemente hacemos:

device.RenderState.ZBufferEnable = true;

Todo el código queda escrito de manera mucho mas limpia.

Para prototipar me parece muy conveniente. En una entrevista a Tom Miller y un colega de él, decían algo como que utilizando Managed DirectX se programa mucho más rápido, acortando tiempos de desarrollo (¡quien no quisiera hacer esto!) se le puede dedicar mas tiempo a aspectos de jugabilidad y a la fase creativa del proyecto.

Como ejemplo saban el juego "the Sims" que no es precisamente avanzando en cuanto a gráficos y sin embargo está en los top ten de lo mas vendido hace varios años. "the Sims" podría haber sido realizado perfectamente con C#/MDX y nadie se hubiese dado cuenta.

El problema aflora, según creo, cuando uno prentede sacar el 101% de jugo del CPU. El Doom3 no podría estar programado sobre MDX. Además Tom Miller dice que usando MDX se obtiene hasta un 98% de la performance de la misma aplicación hecha con C++/DX, lo cual creo que es MENTIRA, si realmente fuese así nadie estaría planteandose nada. Miller se aprovecha de la dificultad existente en la comparación objetiva entre una aplicación C#/MDX y otra C++/DX. Según mis conclusiones muy raramente podremos sobrepasar el 80% de la performance de C++ y usualmente nos quedamos en el 70%.

De todos modos, está claro que el desarrollo de la interfaz estuvo centralizado en la performance, por que bien saben ellos que es lo que mas se valora en estos casos.

En definitiva, no creo que sea compentencia a C++/MDX para desarrollos tipo Doom3 pero sí creo que es una opción para desarrolladores de otros tipos de juegos, donde se valore mucho el terminarlo en menos tiempo. Finalmente, es muy bueno que existan ambos métodos y que podamos elegir el que mas nos convenga.

 ¿Es Managed DirectX una reimplementación de DirectX para el framework .NET o acaso está construido sobre él?

¿Existe mucha diferencia de performance entre Managed DirectX y DirectX? Según lei, no debería existir mucha diferencia de performance (según Tom Miller (el tipo de MS que está atrás de todo esto), sólo el 6%). Pero en las demos probando con C++ y C# algunas diferencias son bastante considerables.

Me gustaría conocer su opinión al respecto. Muchas gracias.

 ok, reinstalé todo el SDK completo y anduvo.

El asunto es que antes en "C:\WINDOWS\Microsoft.NET\Managed DirectX" estaban todos los xml, pero por algún motivo no estaban las dlls. El paquete que antes había instalado era el "DX9.0b para C#", ahora con el completo funcionó.

Muchas gracias a todos.

 En la lista de referencias del proyecto aparecen con un icono de un signo de admiración las "Microsoft.DirectX" y "Microsoft.DirectX.Direct3D" por no ser encontradas seguramente.

Si voy al navegador de objetos, que me permite recorrer los namespaces, veo que "Microsoft" no posee nada en su interior (a diferencia de "System").

Cuando intento agregar una referencia, en la pestaña .NET no me aparece nada que diga "DirectX".  :(

Lo que estoy haciendo ahora es bajar todo el SDK 9.0b completo y el update summer 2003 que me sugirió BeRSeRKeR. Veremos si con esta reinstalación se soluciona la cuestión.

Lo que saco en claro, es que _debería_ funcionar y no se trata de algún un paso necesario de configuración que me haya salteado y que se deba hacer antes de usar DirectX con C# ¿no?

Muchas gracias a todos.