Pues parece que va en función del peso. Hace poco hice unos cuantos pedidos de libros para la empresa y esto fué lo que me cobraron (lo pongo de ejemplo):

2 libros: Items:                  $ 83.98   Shipping & Handling:    $ 16.97    ------ Total Before Tax:       $ 100.95   Estimated Tax:          $ 0.00    ------ Purchase Total:         $ 100.95   3 libros: Items:                  $ 164.89   Shipping & Handling:    $ 14.97    ------ Total Before Tax:       $ 179.86   Estimated Tax:          $ 0.00    ------ Purchase Total:         $ 179.86   1 libro: Items:                  $ 34.96   Shipping & Handling:    $ 11.98    ------ Total Before Tax:       $ 46.94   Estimated Tax:          $ 0.00    ------ Purchase Total:         $ 46.94

todos eran libros de programación 3D, o sea, de los gordos, por eso digo que creo que es por peso.

un saludo

[ Este Mensaje fue editado por: fiero el 2002-04-03 12:22 ]                                

                                Yo pienso que no se pierde nada usando la función Blt. En realidad es la única forma de renderizar algo cuando no se está en modo pantalla completa. La copia de surfaces se realiza por hardware desde las antiguas S3 Virge, Revolution 3D, etc. y no digamos en las nuevas tarjetas, por lo tanto el consumo de tiempo no es apreciable...(se nota, pero no hay mas remedio)

La función Present() de DirectX 8 no es mas que la función Flip() de las anteriores versiones, cuando se está en pantalla completa, y la función Blt cuando se está en modo ventana, por tanto siempre se realizan copias de surfaces. Por lo que tengo entendido sobre el funcionamiento de las aceleradoras, siempre renderizan en un área rectangular, y luego es la función de copia de surfaces la que se encarga de recortar los trozos que no se ven (fuera de pantalla o debajo de otras ventanas...), por tanto la copia es inevitable...

por favor, decidme si he dicho alguna burrada muy gorda :riendo:

un saludo                                

                                hola Emotion
pues si, estoy por aqui, pero ahora me dejas fuera de combate, no recuerdo haber posteado nada sobre un problema con las SIMD, será otro colega... de todas formas, gracias por la explicación porque yo utilizo muchos vectores de estructuras, y mejor que estén alineados,.... nunca te acostarás.....

un saludo                                

                                Hola otra vez,
bueno, yo en realidad utilizo la surface solo como memoria auxiliar, ya que renderizo por software con una función propia de relleno de polígonos. Utilizo doble buffer porque así el sistema se encarga de ver si hay una ventana encima del visor, etc... además la copia de superficies se hace por hardware y en pantalla completa utilizo Flip() que es mas rápido...

Oye una pregunta, eso de renderizar directamente te refieres a no usar surfaces para doble o triple buffering?... y si es así, ¿no se producen parpadeos entre imágenes?

un saludo                                

                                Hola,
Yo utilizo DirectX y MFC. Me he hecho una clase que la llamo Visor que se encarga de gestionar todas las superficies de visualización. A la hora de inicializar un objeto de esa clase, le paso un handle HWND de la ventana en la que quiero que se incruste y listo. Internamente, la clase utiliza ese handle para redimensionar las superficies de DirectX, por medio de la función  GetClientRect(HWND hWnd,LPRECT lpRect); de la API de Windows, y funciones por el estilo.

Utilizo el editor de recursos de VC para poner los controles y luego hago que cualquier control sea un visor 3D.

Ahora estoy haciendo un editor 3D y he añadido una propiedad más, la de poder cambiar el handle de la ventana de salida. Así puedo tener varias vistas simultaneas de la misma escena, cambio la cámara, cambio el handle de la ventana y renderizo...

En realidad no entiendo por qué decis que DirectX es dificil para multi-vistas (no sé si te leí a ti Drácula en un post sobre este tema). Para hacer un Flip() de las superficies de visualización en DirectX, solo se necesita saber las coordenadas de pantalla de la superficie frontal,

hRes=m_pSuperficieFrontal->Blt(lpRectanguloDestino,m_pSuperficiePosterior,NULL,DDBLT_ASYNC|DDBLT_WAIT,NULL);

...y estas coordenadas las puedes sacar de donde quieras, de un rectangulo, de un botón, del frame de una ventana hija en una aplicación MDI.... o sea, cualquier objeto CWnd vale, cualquier rectangulo puede ser un visor 3D...

si te interesa algo de código en particular para clarificar ya sabes...

un saludo
                               

                                Hola a todos
mi humilde opinión personal es que aquí se falla en la visión global de proyecto empresarial (joer, como suena eso :riendo:), es decir, que un juego no tiene por qué costar 2 años, que no hay que ver lo que va a costar hacer el juego, sino que hay que tener la visión de crear una empresa que haga juegos y punto ( no se si me explico). ¿Cuanto tiempo les va a costar a Blizzard hacer el Warcraft III? ¿5 años? , y seguro que ganan mucho dinero. La cuestión es que Blizzard, por ejemplo, es una gran empresa con un motón de programadores, que llevan varios proyectos a la vez y me imagino que con una financiación astronómica. O sea una "FABRICA" de juegos en toda regla. Y eso aquí, es muuuuuuy dificil. Llegar a crear una empresa como esa, aquí en España.....complicado....

un saludo                                

                                hola NeLo
Pues yo ahora no me dedico a los videojuegos, pero estoy haciendo un motor 3D por software ( ya implementaré el hardware más adelante, primero quiero aprender bien los entresijos), para en un futuro dedicarme a ello.

Por lo que veo, la mayoria estamos "preparandonos", quizás los veteranos no se molesten mucho en entrar por aquí......

un saludo

PD: ah, se me olvidaba, estudios FPII de electrónica y media carrera de Ingenieria Electrónica de la que solo aprobé las asignaturas informáticas. En esto desde el Amstrad CPC464 y como no, autodidacta

[ Este Mensaje fue editado por: fiero el 2002-03-22 21:02 ]                                

[Z]

                                Por los pocos conocimientos de 3D que tengo yo diria que si programas con una API como DirectX el ZBuffer es por hardware y solo por hardware, ya que la GPU se encarga de realizar los cálculos de ZBuffer al renderizar los polígonos. Aunque seguramente sepan más los expertos....
Pues junto a la pregunta de Javier añado una duda mia. Estoy haciendo un motor software y para pasar los valores Z, de cada vértice, a valores de 16 bits, multiplico el float por una constante, mas o menos a ojo, y si el resultado es mayor de 16 bits pues lo dejo en 7FFF. Creo que no es una forma muy "pofesional" de hacerlo, hay una forma mejor?

un saludo                                

                                Totalmente deacuerdo con esto último BerSerKer, tengo amigos con grandes ordenadores que se aburren con todo. Los únicos que nos fijamos en los efectos es un amigo mapeador y yo, pero solo por la cuestión técnica, no porque mejoren los otros aspectos del juego. Aunque como programadores siempre queremos conseguir lo más, antes con las 2D, el sprite más rápido, ahora el render más rápido...

Por cierto, este fin de semana me he pasado un juego que tenía atragantado desde que salió, nunca me lo habia conseguido terminar y al fín lo logré... menudo enganche...horas y horas como hacia tiempo que no me enganchaba.... y vaya gráficos.... el juego en cuestión se llama "Dune"

un saludo
                               

                                jeje, buen plan Astat, totalmente deacuerdo contigo. Al final puede que no hagais nada, pero se aprende mucho. En mi caso hice algo así, lo único que yo solo , que es mas aburrido y acabas loco..... y mi carrera se fué al traste... solo programaba...

un saludo                                

                                Hola Astat, ¿puedes decir el nombre de algún programilla de esos que dices? el que más te guste, .... yo no sabia ni que existian...

un saludo                                

                                hombre.... no los desconectan, ten en cuenta que flash en un activex y mira donde ha llegado, todo el mundo ve paginas en flash, por tanto lo tienen activo. Además es dificil colar un activex, ya que pregunta si estas conforme con la instalación y puedes ver si está correctamente firmado. A veces en las paginas de cracks o porno te intentan colar uno sin firmar, de dudosa procedencia, pero dices que no y ya está, si no se ejecuta no hay problema de seguridad.
Veo yo mas peligroso el java, que se ejecuta siempre sin preguntar nada y no requiere de firma de código, aunque tambien se puede firmar. No digo que sea peligroso, pero si alguien te quiere meter un código que te maree el raton por ejemplo(sin entrar en cosas mas dañinas) te lo puede meter mas facilmente por medio de una applet de java...

bueno, todo tiene sus mas y sus menos, definitivamente java es lo mejor por compatibilidad, pero no en cuanto a optimización de código, ya que no puedes meter ensamblador de la plataforma directamente, sino que te lo traduce mas o menos optimizado. Será cuestion de probar a ver...

un saludo                                

                                vaya, veo que estamos en linea...
Muchas gracias por tu explicación, es lo que me imaginaba, lo de emplear el mismo registro en sucesivas instrucciones, tienes toda la razón.
El caso es que acabo de recordar porqué no utilizo MMX en este caso. Una de las razones es que tengo todos los registros mmx ocupados con el mapeo de los triángulos, no en todos los casos, pero por ejemplo, en el mapeo con filtro bilinear los uso todos para las operaciones de interpolación de colores (y a dios pongo por testigo de que no sobra ni uno). O sea que necesitaba un código rápido y que utilizase los mínimos registros posibles, en este caso solo EAX y EDX.
Otra de las razones que hay, en el caso de tener los registros MMX libres, es que el número de operaciones mmx y normales a realizar es más del doble, para solo convertir 2 pixels de 32 bits cada uno. La cosa está en que no hay que desplazar el mismo número de bits todos los bytes RGB, sino que el byte G hay que desplazarlo 2 bits y los R B tres bits, por lo que la ejecución de los 8 bytes de los 2 colores en paralelo se complica una barbaridad.
Por eso, es mejor pixel a pixel, aunque haya que desperdiciar la utilización del pipeline.

Yo cuando empecé con esto de las MMX, me miré en la página de intel lo de la conversión de colores. Ellos utilizan un montón de código MMX, para convertir 4 pixels de golpe, pero tengo comprobado que es igual de rápido de mi manera, y más versatil, ya que pixel a pixel es utilizable en cualquier lado del programa. O sea, que lo que se gana de velocidad de ejecución, se pierde por tener que emplear un güevo de instrucciones más...

Os pongo la dirección de lo de MMX de intel, es interesante... http://cedar.intel.com/cgi-bin/ids.dll/con...e=IDS_EDITORIAL

Gracias por la explicación Emotion
un saludo

[ Este Mensaje fue editado por: fiero el 2002-03-13 12:58 ]

[ Este Mensaje fue editado por: fiero el 2002-03-13 13:08 ]                                

                                bueno, el problema es que la mayor parte del ActiveX está en ensamblador, optimizando mucho el código y utilizando instrucciones MMX, por eso, aunque utilice código nativo de java, nunca llegará a correr tanto como el ocx.
Con java podria ejecutarse en mac y linux, lo cual es una gran ventaja, pero por ahora prefiero hacerlo para el gran público. No olvidemos que el 80% de los usuarios de internet se conectan con w98 o sucedáneos, aunque no nos guste (si no es el 80% poco mas arriba o abajo).
Gracias por tu respuesta

un saludo                                

                                Hola Emotion
jeje, buena respuesta, vaya nivel...
pues ahora mismo no recuerdo porqué no utilizo MMX, porque estoy haciendo un motor software y la verdad que tiro mucho de mmx. Pero para el tema de las conversiones no me acuerdo porqué lo hago pixel a pixel, si me acuerdo lo posteo....
En realidad no es tan lento, cargo imágenes de hasta 4000x4000 pixeles y al cambiar el escritorio de windows de 32 a 16 bits solo tarda un par de segundos en convertir toda la imagen( en un k6 200MHz)
Las instrucciones de 128 bits no me gustan un pelo, ya que no son compatibles en Intel y AMD, perfiero utilizar las mmx de 64 bits que si son compatibles
...y para saber un poco mas, porqué rompo las reglas de emparejamiento? ¿es porque utilizo el mismo registro en sucesivas instrucciones y por eso no puede ejecutar 2 a la vez?, bueno eso de ejecutar dos instrucciones a la vez no entiendo mucho, pero lo de aprovechar el pipeline del procesador creo que no tendrá problemas para ejecutar ese código, ya que es totalmente lineal y transparente...

un saludo