BSP??? aargh! eso duele... el BSP, a no ser que vayas a hacer un clonico de Quake, no vale para absolutamente nada, ya que con las extensiones de hoy en dia para el vertex streaming, da igual el formato de objeto :sonriendo:
                               

                                Me gustaria saber si alguien conoce algoritmos de busqueda de caminos que no sean el RHR (la regla de la mano derecha), una autentica basura :sonriendo: y el A* (el mejor que he visto, pero muy complejo).

Gracias
                               

                                No, pero todo con tiempo...

Primero has de programar CORRECTAMENTE en C++ y luego podras afrontar la programacion grafica.

Es como suele decirse... 'antes de volar has de aprender como caminar' :sonriendo:

Si quieres, de todas formas, intentar algo en cuestion de graficos, en la pagina de Programmer's Heaven (www.programmersheaven.com) hay cosas de graficos en modo 13H (320x200) en DOS. Si quieres pasar directamente a OpenGL o DirectX, pues... tu mismo... :sonriendo:

Pero te aconsejo que empieces por lo mas bajo
                               

                                Cualquier escritor o guionista te podria ayudar, pero todo se basa en el concepto del storyboard. Este no es mas que un 'libro estilo comic', con viñetas que definen visualmente el concepto de la escena, mas notas a pie de pagina y descripciones para describir el efecto en cuestion.

Pero hay mas cosas. Como te he dicho, preguntale a alguien que escriba o haga guiones.
                               

                                Porque estoy creando un renderer propio y me gustaria ver como gestiona el RenderMan las conexiones de ordenadores multiples (estrella, crossbar, etc.).

Por eso necesitaba lo del Renderman, aparte de saber como estructuran los ficheros de exportacion (los famosos .rib)
                               

                                Gracias por los links, aunque lo de Renderman solo son plugins para hacer efectos :sonriendo:

Pero bueno, obtuve unos cuantos PDF muy interesantes. Gracias :sonriendo:
                               

                                Mas que XML, deberias probar con PHP, es mucho mejor, y muchisimo mas rapido.

Ademas, es gratuito y te lo puedes bajar tranquilamente de la pagina de phpnuke.org
                               

                                Gracias por el link. Me ha resultado bastante util para un pequeño truco :sonriendo:

Por cierto, el penultimo algoritmo es el que te interesa, ya que te permite procesar 1 pixel cada 3 ciclos, o 8 pixels en 24 ciclos. Bastante interesante.

A pesar de que me comentas que todos los registros MMX los tienes ocupados, utiliza la tecnica del multipass rendering, es decir, primero computa los triangulos y despues realiza la conversion, o al reves. Depende de como tengas implementada la pipeline de tu motor grafico.

En cualquier caso, echale un vistazo al tema del multithreading, te puede salvar el pellejo en mas de una ocasion y ademas tiene la ventaja de que en maquinas con procesador doble no corre, vuela.

saludos.
                               

                                No, el emparejamiento ES lo que te deja ejecutar el codigo de forma limpia y transparente. La primera regla del emparejamiento es que no se puede actualizar un mismo registro en las dos instrucciones, es decir:

mov eax,1
mov eax,2

esto NO empareja. la pipeline se colapsa hasta que se ejecutan las dos instrucciones UNA a UNA.

el segundo caso, que es el que yo he visto en tu codigo, es que si en una instruccion insertas un valor en un registro, no debes utilizar la informacion de ese registro en la siguiente instruccion, ya que la informacion AUN no esta actualizada. es decir,

mov eax,1
mov ebx,eax

esto, evidentemente, NO empareja. Pero ahora vayamos con el ejemplillo practico

[esta es una parte de tu codigo]

mov eax,color32
shr eax,3

AHI esta el fallo. tratas de desplazar los bits de EAX 3 posiciones hacia la derecha cuando AUN estas introduciendo la variable color32 en el registro :sonriendo:

Por cierto, a pesar de que esto se amolda muy bien al software, tambien se puede usar con el hardware, es decir, OpenGL (en mi caso, pero DX tambien) tienen sus buffers en direcciones de memoria fisicas Y accesibles.

Tambien se puede usar para acelerar la generacion de multitexturas (habilitandola en las tarjetas que no puedan por hardware y añadiendo mas a tarjetas que si lo soportan), etc. etc. :sonriendo:

y si ademas, lo haces con multithreading, pues imagina... la imagen de que me hablas pues de 2 segundos a menos de 1 (aunque esto ultimo no te lo puedo asegurar). lo que si te digo es que segun el manual de intel, puedes ejecutar un MOV en 0.5 ciclos de reloj, en lugar de 1 o 2 (depende del caso, de que las instrucciones esten alineadas, emparejadas... etc.). bienvenido al mundo de la optimizacion :sonriendo:

Un saludo.

_________________
Julio Meca
ALPHA SOFTWARE

[ Este Mensaje fue editado por: Emotion el 2002-03-13 12:26 ]                                

                                Estoy buscando documentacion sobre las tecnicas de iluminacion avanzadas como el Photon Mapping y el Lumigraph, esto es para infografia, ya que estoy creando un modelador de apoyo a mi motor de desarrollo de juegos, pero necesito que alguien me ilumine un poco al respecto (perdon por el chiste malo). Asimismo, me gustaria saber si algun usuario del foro tiene documentacion de Renderman, ya que necesito introducirme un poco en el.

Gracias y un saludo,
                               

                                Para fiero:

Ese codigo no esta mal, pero si se va a hacer pixel a pixel sera lentiiisimo, porque te estas saltando las reglas de emparejamiento de instrucciones, con lo que no aprovechas la capacidad que tienen los pentium para ejecutar 2 instrucciones en paralelo.

Por otro lado, puedes probar a hacer el codigo con instrucciones SIMD de 128bits, con lo que puedes empaquetar 4 pixels en 32bp al mismo tiempo y luego disponer de 8 pixels por registro. Bastante rapidito :sonriendo:

                               

                                Estoy buscando la manera de poder utilizar el decodificador de macrobloques (esencial para poder reproducir video en formato MPEG2) de la GeForce/Radeon sin tener que pasar por los tipicos filtros de DirectShow. Si alguien sabe como hacerlo, o bien a traves de OpenGL, o bien a traves de programacion a pelo, me gustaria que me lo hiciera saber. Tal vez me interesaria integrar a varias personas en mi proyecto AG3 (del cual expondre largo y tendido en la seccion de colaboraciones).

Gracias, y un saludo
                               

                                Si buscas algo REALMENTE bueno, debes buscarlo en ingles, ya que es la fuente principal de documentacion. Aun asi, porque no pruebas en 'la web del programador'? no recuerdo la direccion pero por lo que he oido esta bastante completita.
                               

                                Pues si, asi es. No se puede precisar el color de un objeto con mas de 24bits, pues ese es el numero maximo de colores que el ojo humano percibe, pero pasa igual que con los escaneres. Cuanta mas resolucion tengas para un solo componente mejor puedes muestrear un color en base a un determinado espectro de color, o incluso hacer conversiones entre escalas de color (menos la barbaridad que he llegado a escuchar por otros foros, como intentar convertir de infrarrojos a RGB)