Bien, pues hace no mucho hubo un post sobre colisiones por hardware, y yo propues una técnica, que era utilizando Querys de oclusión.
Aprovechando que estoy preparando el motor para publicarlo, decidí probar esta técnica. La gran ventaja que tiene es que las colisiones son por hardware, por lo que las rotaciones y escaladosse contemplan sin problemas.
Vereis un sprite de un color más claro, y un motón pegando botes. Cuando el claro toca a otro, este se pone oscuro. Podeis activar / desactivar con la c el sistema de colisiones, y así vereis el coste en velocidad.
Ese enlaceEspero que os guste. A mi me parece muy chulo y una buena técnica. (ole)
Olé! Jajaja.
Yo aún no he tenido tiempo de implementarlo. Cuando acabe con los scrolls me pondré y ahora que ya lo tienes hecho y todo... ¿podías pasarme el código fuente? De esa parte solo claro.
Voy a probarlo, ciao!
EDITADO: Ains :( Como no tengo PS me va tan lento que no puedo apreciarlo, lástima.
Escribiré un artículo sobre el tema, explicando cómo funciona. :D
No es por fastidiar pero cuando lo ejecuto me salta un mensaje de error grave de Windows y se me cierra :(
Te pongo una parte del log ke me ha llamado la atencion por estar resaltado en rojo:
Citar(...)
---------SHADERS---------
Nº de constantes en el vertex shader:96
NO SOPORTA PIXEL SHADER 2.0
NO SOPORTA PIXEL SHADER 1.4
SI SOPORTA PIXEL SHADER 1.1. 8 constantes, 4 coordenadas de textura, 2 temporales
NO Soporta Querys de Oclusión
(...)
No creo ke venga por lo de los Querys de Oclusion no soportados, por ke eso se supone ke lo controla tu motor y no iniciaria el programa, no?
Salu2...
Si no soporta Querys NO funcionará. Pero como bien dices, el motor debería controlarlo.
¿Qué tarjeta tienes?
buenas, a mi si que me va bien, solo
que si cambio de tamaño la ventana
me da un error grave de windows...
y al final del log me sale:
INICIO CXVideo::Resize3DEnvironment
Device->Reset() D3DERR_INVALIDCALL
Saludos
Cierto, el motor no controla los lost device y sale del sistema. Tengo que arreglar esto....
Haddd dijo:CitarSi no soporta Querys NO funcionará. Pero como bien dices, el motor debería controlarlo.
¿Qué tarjeta tienes?
3D Blaster GeForce3 Titanium 200 64mb
Salu2...
¡Que fuerte, la GForce 3 no soporta Querys de oclusión y sólo Pixel Shader 1.1! :huh:
Pues lo siento, espero que las Querys de oclusión sean un standard, igual que los pixel shaders 2.0
Haddd dijo:Citar¡Que fuerte, la GForce 3 no soporta Querys de oclusión y sólo Pixel Shader 1.1!
Pues lo siento, espero que las Querys de oclusión sean un standard, igual que los pixel shaders 2.0
Ya weno, y segun tu motor mi tarjeta no soporta el modo a pantalla completa (uoh) :lol:
Salu2...
P.D.: Espero no equivocarme, pero he leido ke no soporto FullScreen, te posteo el inicio del log para ke lo veas tu mismo:
CitarHaddd v1.0 (Feb 1 2004 19:44:36)
INICIO CXVideo::CXVideo
FIN CXVideo::CXVideo
Nº de adaptadores:1
No soporta FullScreen
No soporta FullScreen
TARJETAS Y SUS DEVICES
Tarjeta:0 3D Blaster GeForce3 Ti 200
Device:0 HAL Behavior: HW MIX SOFT NºFormatos:2
Modo:0 Modo Ventana posible 00000016 X8R8G8B8 DEPTH STENCIL 00000050 D16 0000004d D24X8 0000004b D24S8 00000047 D32
Modo:1 Modo Ventana NO posible 00000017 R5G6B5 DEPTH STENCIL 00000050 D16 0000004d D24X8 0000004b D24S8 00000047 D32
Device:1 REF Behavior: NO SOPORTA T&L NºFormatos:2
ESTE DEVICE NO CUMPLE LAS EXIGENCIAS MINIMAS DEL MOTOR
Modo:0 Modo Ventana NO posible 00000016 X8R8G8B8No soporta FullScreen
Modo:1 Modo Ventana NO posible 00000017 R5G6B5No soporta FullScreen
INICIO CXVideo_Inicializacion::CrearVentana
FIN CXVideo_Inicializacion::CrearVentana
INICIO SeleccionarDepthStencil
Depth Bits=16 Stencil Bits=0 D16
FIN SeleccionarDepthStencil
CXVideo_Inicializacion::InicializarDevice
Behavior seleccionado:D3DCREATE_HARDWARE_VERTEXPROCESSING
CXVideo_Inicializacion::InicializarDevice
INICIO Características del Device
Versión de SDX:31. De D3D:0900
Versión del Adaptador:2185
Memoria de vídeo disponible:108 MB (110592 KB)
HAL (hw vp): 3D Blaster GeForce3 Ti 200 (740x560x8) (D16S0)
Escritorio: Ancho=1024 Alto=768
FullScreenGamma OK
CanCalibrateGamma NO DISPONIBLE
Alpha en modo Flip/Discard OK
Nº Máximo de Streams para Vertex Buffers=16. Tamaño máximo en bytes(Stride)=256
Nº Máximo de indexbuffer=x000fffff.
Nº de RenderTarget simultáneos:1
---------TEXTURAS---------
Utilizando formato por defecto para las texturas A8R8G8B8
Las texturas NO necesitan ser potencias de 2
Máx Anchura x Altura: 4096 x 4096
Nº máximo de texturas simultáneas:4
Soporta compresión DXT1
Soporta compresión DXT2
Soporta compresión DXT3
Soporta compresión DXT4
Soporta compresión DXT5
Soporta Texturas volumétricas
---------SHADERS---------
Nº de constantes en el vertex shader:96
NO SOPORTA PIXEL SHADER 2.0
NO SOPORTA PIXEL SHADER 1.4
SI SOPORTA PIXEL SHADER 1.1. 8 constantes, 4 coordenadas de textura, 2 temporales
NO Soporta Querys de Oclusión
FIN Características del Device
(...)
El ejemplo usa una resolución de 740x560, supongo que es normal que la tarjeta no soporte fullscreen.
Lo que me extraña es que el modo REF no soporte los requerimientos mínimos. ¿Tienes instaladas las DX 9.0b de desarrollo?
jpastor dijo:CitarEl ejemplo usa una resolución de 740x560, supongo que es normal que la tarjeta no soporte fullscreen.
Cierto, ahi puede estar la razon, no habia caido :P
Haddd dijo:CitarLo que me extraña es que el modo REF no soporte los requerimientos mínimos. ¿Tienes instaladas las DX 9.0b de desarrollo?
Tengo instaladas las Runtime (no SDK) version 9.1.
Salu2...
Sip, en ese ejemplo el frame buffer es 740x560, ¿no es así? Pero eso es casi seguro por los márgenes de la ventana (la lína azul, los bordes grises, etc). Me dí cuenta de ese detalle hace poco: que el frame buffer no tenía porqué ser del tamaño que he creado la ventana, lógicamente este es menor. Sinembargo si la hubiera creado en pantalla completa, al no tener bordes la ventana pues el frame buffer ya sería de 800x600 y te debería ir perfectamente.
Es mejor tener encuenta esto y crear la ventana (en modo ventana solo claro) un poco mayor según convenga para que el frame buffer siempre tenga valores como: 320x240, 800x600, 320x600... etc.
En aplicaciones 3d no se nota mucho, pero en aplicaciones 2d en modo ventana, como es tu caso, el fondo y todo lo demás se difuminará un poco si no tienes eso en cuenta. Creo que ya te lo puse en otro post, que si en tus ejemplos probabas con un fondo pixelado, luego en ejecución se notaba difuminado... eso es algo a evitar.
Más aún, si por error haces un SetViewPort a 800x600 al tener el frame buffer a 740x560 las consecuencias pueden ser inesperadas. En ese error caí yo y por eso un ejemplo mío daba como resultado en algunas tarjetas un montón de colorines en vez de lo que tenía que salir (ver post de "probarlo a ver si funciona").
Un saludo!
PD: Es una lástima que los querys no sean más genéricos. ¿Se te ocurre otro método, auque sea más lento, pero que amplie la gama de tarjetas que puedan realizarlo? Bueno, y que no sea el que ya discutimos sobre lockear a cada frame la textura.
Lo de la resolución y viewport no tiene nada que ver. Lo que ocurre es que EX3 tiene un rasterizador REF que debe ser una versión antigua y por eso aparecen estas cosas raras.
De toda la vida he podido tener un backbuffer en modo ventana, que para eso existe ese modo. B)
Lo que en realidad debe hacer el driver es utilizar el backbuffer del escritorio, que SIEMPRE es a pantalla completa, y utiliza un ViewPort del tamaño de la ventana.
Respecto a lo de no usar Querys de oclusión, pues no se me ocurre nada. Pero creo que son bastante compatibles ya. Es como hacer un motor sin pixel shaders porque hay gente que no tiene. Bueno, ya sabemos que hay gente que no los tiene, pero en el tiempo en el que un proyecto con el motor salga a la luz, ya será totalmente extendido. Ya sé que parece eso de, ¡que se $$%% los que no lo tienen !, pero no es así, es que el código es tremendamente más fácil de mantener, y yo tengo muuy poco tiempo.
Lo duro sería si hubiera puesto shaders 3.0 por defecto, eh? :blink:
Bueno, nadie me comenta nada del framerate. ¿os baja mucho con/sin colision?
CitarLo que en realidad debe hacer el driver es utilizar el backbuffer del escritorio, que SIEMPRE es a pantalla completa, y utiliza un ViewPort del tamaño de la ventana.
¿Con eso quieres decir que si tengo el escritorio a 1024x768 mi backbuffer en modo ventana tendrá esa resolución?
Si haces
m_Video->D3D()->GetAdapterDisplayMode(m_Adapter, &m_Mode);
Si estás en modo escritorio, las variables m_Mode.Width,m_Mode.Height te devuelven el tamaño del escritorio
Si estás en full screen, te devuelve el tamaño del full screen
Pero pichón, eso no es el tamaño del frame buffer. Eso, como tu dices, es el tamaño del escritorio (y claro, en modo pantalla completa la aplicación lo cambia).
El tamaño del frame buffer se halla con esto:
D3DSURFACE_DESC m_d3dsdBackBuffer;
LPDIRECT3DSURFACE9 pBackBuffer;
mInfo.mDevice->GetBackBuffer( 0, 0, D3DBACKBUFFER_TYPE_MONO, &pBackBuffer );
pBackBuffer->GetDesc ( &m_d3dsdBackBuffer );
pBackBuffer->Release();
Debug->DataInt (m_d3dsdBackBuffer.Width, 1);
Debug->DataInt (m_d3dsdBackBuffer.Height, 1);
Y si miras ahí verás que tienes un frame buffer de 740x560 ;)
Prueba a crear la ventana 60 pixeles mas ancha y 40 mas alta y entonces el frame buffer pasará a 800x600
¿Pero qué más da que el frame buffer tenga un tamaño "estándar" que no?. En modo ventana es indiferente.
Con respecto al frame rate, la verdad es que no se aprecia diferencia alguna entre tener las colisiones activadas y no tenerlas.
Saludos.
Cita de: "BeRSeRKeR"¿Pero qué más da que el frame buffer tenga un tamaño "estándar" que no?. En modo ventana es indiferente.
Ok, he releído el post y ya sé a cuento de qué venia esto...Olvidad lo que he dicho :D
Saludos.
Citar¿Pero qué más da que el frame buffer tenga un tamaño "estándar" que no?. En modo ventana es indiferente.
Lo he dicho por dos motivos (que ya lo puse en el otro post) uno aduciendo que ese podía ser la causa por la que el debug de Hadd decía que no funcionaría en modo pantalla completa con la tarjeta de [EXT].
Y otro por el "blurring" que sufren las imágenes y otra serie de "artifacts". Puedo ponerte un ejemplo, con una imagen, una sobre un framebuffer de tamaño standard y otra sobre uno de tamaño arbitrario. En la segunda la imagen se verá ligeramente difuminada con ciertos errores debido a que la escala (aunque en ambas hagas el ajuste -0.5f, -0-5f para el ajuste del texel).
Eso solo se nota en aplicaciones 2d.
Si lo piensas es lógico. Es normal que si tienes un fondo, por ejemplo para un juego, de 800x600, el framebuffer deba tener ese tamaño para que este fondo no se reescale y salga totalmente nítido como la imagen orinigal ;)
PD: Hadd, ¿entonces vas a poner un artículo acerca del método y tal? Que sea pronto :D
EDITADO: Ups, contesté antes de ver lo de "olvidad lo que he dicho..."