Looverlib 1.0

[Sacrifai]

 Hombre zwitter hay que ser muy bruto para meter tanto frame un archivo solo. Sin embargo, si puedes dividirlo, por ejemplo, andando-derecha. El motivo de usar este metodo supongo que ya lo conocerás. Más archivos pequeños = más espacio en disco duro y para colmo tarda "bastante" más en encontrarlo (algo muy relativo ya que hablamos de milisegundos o hasta menos) . Aunque no lo parezca, tarda menos en coger los bits que nesesitas de una imagen grande  :)  .

[CoLSoN2]

 Loover, estaba pensando en usar tu librería para la versión Windows de mi engine, ya que hay más usuarios con buenos drivers para DX7 que para OGL, pero leyendo el thread me he dado cuenta de que usas DX9 !! ¿cuál es tu excusa para usar DX9 en vez de 7?, porque no creo que sea por el HLSL XD

[Loover]

 :P

Si te comprometes a usarla te la paso a D3D7.

De todos modos, la razón de que esté en D3D9 es por si la gente de stratos que tiene motores (siendo la mayoría de estos bajo D3D9) se anima a usarla junto con su parte 3D.

Lo que debo hacer es separar el sistema de render en un plugin. De tal manera que pueda cargar diferentes renders, D3d7, D3d8.1, D3d9, Ogl, ¿Software? Etc

[_Grey]

 Por cierto, no se recupera cuando sales a windows (Alt+Tab) y regresas a la aplicacion.

Quiza sea una parte de las complejas, pero hasta entonces podrias hacer cosas como tratar las texturas como "D3DPOOL_MANAGED" o "D3DPOOL_SYSTEMMEM" y solo tendras que recuperar el Device y poco mas (hablo de memoria...).

En cualquier caso creo que deberia ser la libreria quien lo haga.

Saludos.

[Loover]

 Cierto _Grey, lo del alt tab es un problema que me mosquea. Estuve leyendo el post de EX3 (creo que era) preguntando por eso y tal pero creo que no se encontró una solución en ese hilo.

Alguien sabe como puedo solucionar eso?

[_Grey]

 El otro dia leyendo un libro.....

Puedes prevenirlo. Puedes desactivar el ALT+TAB y ALT+ESC con el parametro SPI_SETSWITCHTASKDISABLE de la funcion de sistema SystemParametersInfo(), ni siquiera lo he probado, pero la puedes encontrar en la documentacion.

Pero si lo quieres hacer bien es mas complejo, algunos objetos de DirectX lo requeriran otros no, y algunos puedes "adaptarlos" para que no sea necesario, como lo dicho para las texturas en el anterioro msg.
Tengo que reconocer que mi "parche" para solucionar esto a dado algun problemilla, pero es mas bien por dejarlo para el final y no hacerlo para todos... pero mas o menos es algo asi:

Lo que has de hacer es liberar los objetos que lo necesitan (A golpe de Release(), es como lo hago) y luego lo creas de nuevo, cargando los ficheros otra vez, como al inicio.

Puede combertirse en algo complejo adaptar el codigo ya creado, de todas formas como no usas vertexbuffers (Las quitaste al final, nop?) Puedes crear las texturas para que no necesiten ser "recargadas", el dispositivo lo liberas y lo creas otra vez. Basicamente es eso, en la documentacion encontraras mas info, el trabajo de verdad es adaptar las estructuras u objetos para que sepan que recurso han de cargar otra vez.
Si acaso para empezar has lo minimo dejando las texturas como "D3DPOOL_MANAGED" o "D3DPOOL_SYSTEMMEM" igual es suficiente, pero quiza el rendimiento baja con ese tipo de texturas, es cuestion de hacerlo.

Por cierto eso de HLSL...... sinceramente pensaba que usabas Dx9 para poder usar pixel shaders y hacer efectos vistosos. Hace algun tiempo alguien puso el link de un motor 2D que los usaba y quedaba muy ..... "visual", pero lo mejor seria poder renderizar la imagen en una textura y despues pasarle el filtro con el pixel shader, aqui las posibilidades serian muy grandes...  incluso sin pixel shaders, si los objetos de figuras geometricas de tu motor soportara la posibilidad de texturar los poligonos.Esto ultimo casi me extraña que no este , o por lo menos no lo e visto por ningun lado.

Saludos.

[Haddd]

 Una versión de mi motor que puse aquí utilizaba pixel shaders para 2D. Quizás te refieras a esa versión. :D

Por cierto, ¿no hay comentario sobre la explicación de las colisiones perpixel que he puesto antes?  

[Loover]

 

incluso sin pixel shaders, si los objetos de figuras geometricas de tu motor soportara la posibilidad de texturar los poligonos

Lo puedo poner como una primitiva más, buena idea.

Pero no, no pienso usar Pixel Shaders. Por lo menos no de momento, ni siquiera a medio plazo. Lo siguiente que voy a hacer es separar el render en un plugin. Luego portarla a D3D8, luego a OGL. Eso así por lo pronto. E ir metiendo a la par algunas funciones simplonas como esas de colisiones que ya tengo, o la de relleno de polígonos en la sección primitivas, objetc picking, etc.

Una vez portada a OGL el siguiente paso sería que funcionara en Linux.

A la misma vez iré añadiendo herramientas. Un editor de tiles, un empaquetador de recursos, etc.

Y todo esto cuando tenga tiempo y no esté con otras cosas. Pero no voy a dejarla abandonada.

No quiero usar Pixel Shaders porque el único ambiente en el que podría tener cierto éxito mi libreria es en el del shareware. Y los requisitos de los ordenadores de los compradores de ese tipo de juegos son muy bajos. Nada de Pixel Shaders.

En serio que me gustaría mucho que la gente se animara a usarla. Me gustaría abrir un foro de la libreria pero no sé que sistema de foros elegir. ¿No podriais hacerme un hueco en la sección proyectos, jiji? Que cara tengo.

POSTDATA:
Hadd en su tiempo ya te dije que el algoritmo para detección de colisión por pixel estaba bastante bien. Faltaría que lo completaras con vectores resultantes, area afectada, etc.

De todos modos, me parece demasiado dependiente del Hardware ese sistema. Oclussion Querys no lo tienen todas las tarjetas. ¿Existe lo mismo en OGL?

[_Grey]

 Si no te interesan los pixel shaders, y piensas en bajar una version de Direct3D, piensa en la 7. Los posibles usuarios te lo agradeceran si piensas en el shareware, y si añades las texturas a las figuras geometricas y lo combinas con la posibilidad de "renderizar" la imagen a una textura se pueden conseguir efectos mas que buenos sin pixel shaders solo a base de poligonos.

Pero si piensas en Linux casi mejor portarla a OGL, tu veras.

Saludos.

[Loover]

 D3d7, D3d8, D3d9, Ogl, software? Los tengo todos en el punto de mira una vez que separe el render en un plugin. Al iniciar la clase render, bastará con escoger uno u otro y punto. Es solo programar bien la base. Lo bueno de que sea una libreria 2d, es que se puede atisbar un "final" en el que quede algo realmente decente. Con el 3d está todo tan abierto y siempre saliendo más y más cosas que da así como apuro ponerse como otro motor 3d más. Pero claro esa es mi opinión, y ni muchos es la realidad de muchos de vosotros. Basta con ver el genial motor Hadd.

[_Grey]

 Es que no le veo mucha utilidad bajar de la 9 a la 8, pero si lo que te interesa es mantener los requisitos "bajos" y crees que puede ser interesante para produciones share, la 7 es ideal, se van a OGL o a la 8 por que es mas facil, lo cual podria hacer mas interesante la libreria (No te garantizo que nadie la use, segun la promociones).

Pero claro, si piensas en Linux OGL estara entre tu objetivo mas principal. La version de software, simplemente pasaria de ella, es irse a un hard demasiado bajo, quiero decir si quieres poder hacer todo tipo de efectos, transparencias ,rotaciones zooms, y demas.... si necesitas por soft seguramente no habra maquina.

Saludos.