En caso de ser muy lenta puedes usar una tabla de 16 bytes para invertir el nibble alto y nibble bajo (o una de 256, pero siendo un z80 256 bytes para eso es un lujo dificilmente justificable...)

Pues en los viejos juegos del Spectrum nos permitíamos esos lujos. ;)

Jojo con lo de que Praetorians es "Total War se va a Roma" me has dejado loco. :) Como curiosidad histórica, la principal fuente de inspiración para el concepto de Praetorians fue el vetusto "Warhammer: Shadow of the Hornet Rat", allá por el 1997. La saga de "Age Of Empires" y las mejoras de interfaz de Starcraft, Total Annihilation, etc. hicieron el resto. Del Total War lo unico que nos produjo curiosidad era ver cómo habían resuelto ellos el tema de las luchas entre unidades de las tropas en tiempo real, pero el resto no tiene nada que ver. :)

la verdad que incluso 100MB me parece mucho (calculando que tienes según dices unos 20.000.000 de objetos y tal).

5 bytes por objeto no parece mucho, teniendo en cuenta que la zona de memoria de cada objeto tiene que incluir información de gestión de memoria, de garbage collection, y sus propios datos. ;)

Pongamos un ejemplo, tienes unas montañas a 10 km, y un mapa a 20 cm de la cara (que es la cámara)
[...]
No veo otra solución que modificar la proyección específicamente antes de renderizar cada uno de ellos

Creo que el Quake 1 modificaba la matriz para pintar el arma; esto es bastante habitual en los FPS, pero muy concreto y fácil de separar. Los problemas pueden venir si tienes objetos a 10 km, 1 km, 100m, 1m, 10cm, etc. El suelo que ves (y que forma las montañas al fondo) está esparcido por todas esas distancias, de forma contínua. ¿Dónde pones el corte?

Los primeros juegos que mostraban grandes extensiones de mundo con aceleración 3D hacían diabluras de este estilo con la matriz de proyección (el Project IGI en particular, pedazo de motor que se curraron), pero hay que tener siempre presente que no es una solución genérica que "simplemente funciona", hay que poner los cortes y separar los elementos de la escena con mucho cuidadito.

Igual en los sources de la OpenGLUT, donde lo del GameMode.

Te repito que sin dudar de tu palabra, me cuesta creerlo, primero se anda después se corre, primero fue el alphatest, después el alphablend. Lástima que no tengamos las Specs.

La memoria me falla respecto a algunas de las lindezas de la S3 Virge. En cualquier caso, solo la mencioné como ejemplo de que las cosas a veces no son tan sencillas y ortogonales como nos gustaría o nos parecería lógico. La Virge a día de hoy es irrelevante.

Respecto a la discusión, lo mejor es conocer ambas técnicas, saber cuándo usar una u otra, los problemas que puede dar cada una en diferentes situaciones, y las posibles soluciones o hacks disponibles. Sería más util para todos si cada uno dedica esfuerzos a aportar información en lugar de desacreditar la que aportan los demás. En esa línea, otro dato interesante: en la mayoría de las tarjetas anteriores a las ATI 1x00 y NVidia 7x00, el alphatesting no recibe los beneficios del Full Screen Antialiasing. Si quereis ver lo que sucede, probad el King Kong de Ubisoft, que usa alphatesting para las grandes masas de vegetación, y comparad los resultados con FSAA en una 6600 y una 7800... no hay color. En la 6600 el baile de pixeles es un horror. :P

b) OpenGL, nunca ha especificado que estas opciones son dependientes del hardware
[...]
d) Que es más complicado desde el punto de vista técnico ? implementar un Alpha Test o un Alpha Blending ? Cual de las dos técnicas es más rápido de computar ?

Puedes creerme, yo sí he tenido en mis manos las especificaciones de la Virge bit a bit y registro a registro. Y sobre todo, he trabajado con ella.

Ya han explicado que la especificación de OpenGL exige un fallback software que, aunque funcional, probablemente no de el rendimiento exigido. Alpha Test en general es más rápido de ejecutar que un blend, pero alpha test en software será más lento que blend por hardware. :P Como dice zuper, el test genera bordes "duros" que pueden quedar muy feos, pero el blending tiene su propio conjunto de problemas: ordenación y multipass son los más clásicos. El tercer problema clásico (y el que más quebraderos de cabeza me dio en su momento) es el hecho de que con blending, los texel transparentes también escriben en el ZBuffer.

Hoy en día lo del ZBuffer se suele resolver activando blending Y testing a la vez, aunque suelen quedar unas babas un poco feas alrededor del gráfico. Lo de la ordenación se puede abordar o bien exigiendo una PowerVR (juas), o usando algún truco sucio como el de Tom Forsyth de hacer una pasada con alpha y otra con blending sin escribir la Z. Esto último no funciona bien en todos los casos, pero cuando lo hace parece de verdad.

Si encuentras algún hardware que SI soporte Alpha Blending y NO soporte Alpha Test, dejaré de escribir en estos foros para siempre...

¿Quieres uno? La S3 Virge. Aaaaadiooosss! ;)

De hecho, los drivers D3D de la S3 Virge *emulaban* Alpha Testing activando en su lugar Alpha Blending, lo que nos dio no pocos quebraderos de cabeza, porque los pixels transparentes por Alpha Testing no escriben en el ZBuffer, pero los transparentes por Blending si. Hablamos de 1997... en el 98 ya era infrecuente que juegos comerciales se molestasen en soportar la Virge. O sea que no es lo que se dice muy relevante.

A día de hoy se asume que el Alpha Testing existe y funciona realmente como debe, porque es muy útil y se usa en practicamente todos los motores gráficos.

-¿que diferencias hay entre c++/cli y managed c++?

-Algo que no entiendo muy bien es, si vas a desarrollar en .net ¿porque habiendo lenguajes tipo c# o vb.net la gente querria usar c++/cli o managed c++?

Mejor un hilo nuevo para eso, que ya se nos ha ido bastante la olla en éste.

La ventaja principal de los lenguajes de script es que resultan fáciles y rápidos de modificar, incluso puedes montartelo para recargarlos dinámicamente sin tener que cerrar el juego, y suelen ser más amigables a errores de runtime que código nativo.

Las principales desventajas son, que tienes que saber dos lenguajes en vez de uno (excepto si el script lo escriben diseñadores que no saben por ejemplo C++), son más lentos que el código nativo, los depuradores suelen estar menos currados que el Visual Studio, y que hay que mantener los enlaces entre el script y el código nativo de tu juego.

Como todo, hay que evaluar las ventajas e inconvenientes. Pero una gran mayoría de juegos hoy en día utilizan lenguajes de script en mayor o menor medida, o sea que en general no son mala idea. ;)

Si va a usar herramientas de microsoft en un sistema operativo de microsoft lo mas logico es usar sus apis.
[...]
¿No era totalmente libre como el csharp? Sigo sin ver la importancia de que varien algunas cosas del C++ tradicional al fin y al cabo es un lenguaje mas para facilitar y acelerar la programacion.

Por supuesto C++/CLR tiene sus aplicaciones y su sitio dentro del panorama. Un articulillo interesante para leer es http://www.research.att.com/~bs/bs_faq.html#CppCLI y los links que incluye. Solamente digo que si alguien tiene un problema con los streams de C++, resolverlo pasandose a C++/CLR es matar moscas a cañonazos.  Si .NET como plataforma y C++/CLR son el mejor entorno para tu aplicación, genial. Como solución a un malentendido con la libreria o una instalación errónea del compilador (sea lo que sea el problema original) de McBain, pues como que no me valen. Igual se podría haber pasado a Haskell, que tiene otras ventajas (y otros inconvenientes). ;)

Un detalle interesante es recordar que, aunque tu aplicación concreta sea para Windows, hay mucho código que podrías reutilizar posteriormente; si tu código usa un lenguaje y features estándares y portables, eso que habrás ganado.

Otra vez que no te entiendo, el .net deja trabajar con streams. http://msdn2.microsoft.com/en-us/library/system.io.stream.aspx

Creo que esos no eran los streams a los que se referia con #include <fstream>

Edit: Boh, el vicio que tengo de escribir C++/CLR cuando el nombre oficial es C++/CLI.

No entiendo tu post, ¿que tiene de malo el C++/CLR?

Aparte de considerarlo personalmente como una aberración (aunque pueda resultar tremendamente util en ciertos casos), el hecho es que no es C++ sino un dialecto de C++, propietario de Microsoft, e intimamente ligado con la plataforma y el runtime .NET. Recomendar semejante salto por la ¿conveniencia? de los ficheros de .NET frente a las streams es, digamoslo asi, un poco atrevido. :)

Sin nada que ver con el fstream, ¿no te es mejor comenzar a usar las clases para controlar archivos que vienen en el api del .net?

Lo de los ficheros no es nada comparado con usar las Forms de .NET en vez de Win32 para las ventanas. :) Pero eso implica pasarse de C++ a C++/CLR, que no es una decision a tomar a la ligera.

 No es para colocar websites, pero Amazon S3 podria volverse muy popular para hosting de ficheros; leed lo que cuenta Greg Costykian en http://www.costik.com/weblog/2006_05_01_bl...857563367387545 y comentarios.

 

Ya tengo mis ideas generales (linea de tiempo, acciones que se ejecutan en esa linea de tiempo, etc)
[...]
creo para un Api de cutscenes no es suficiente con tener una timeline que va ejecutando comandos.

Esto..... yo diría que el articulo que indica ethernet se parece bastante a tus ideas generales. ;)

En una cutscene tipicamente vas a tener uno o más objetos (cámara, mallas 3D, efectos visuales, particulas, etc), a los que vas a asociar diferentes propiedades (animación, transformación, sonido, parámetros de materiales, etc) a lo largo del tiempo. Esas propiedades pueden editarse y exportarse desde el modelador 3D junto con las mallas y tal (típico en escenas 3D de demos), o pueden venir de una librería generada de manera separada a la exportación. De modo que la respuesta es "depende de qué quieras hacer en tu cutscene". Para cutscenes tochas es habitual que se use una mezcla de ambas: colocar en el escenario objetos exportados de diferentes formas, y aplicarles diferentes propiedades a lo largo del tiempo (comandos en la timeline) o dejar que usen las que traen consigo desde el modelador 3D.

Esta presentación de la gente del God of War te puede dar alguna idea sobre el uso de animaciones y cinemáticas, y en general es muy interesante:

https://www.cmpevents.com/sessions/GD/S2409i1.ppt