bueno las .dll se pueden usar en win... no en c... se entiende no?....                                

                                Pues yo diria que Java, detro de los videojuegos solo es interesante cuando quieras hacerlos correr en paginas web, si programas para una plataforma concreta nunca tendras la velocidad que con otros... pero claro , tu hablas de los no freneticos, cambiara un programador de lenguaje por que si? si sabe C o C++ , pues lo hara en eso...realmente , dentro , de los juegos, solo veo que pueda tirar cuando hagas cosas para correr en web,pero todo y eso no lo tengo muy claro, entan saliendo "jueguecitos" en flash, me he fijado que Java esta siendo un poco "apartada" para cosas "cronquetitas" , yo tambien le di a java , un pequeño cliente de irc, no tiene un codigo bueno, mas que nada por que lo hice para aprender el lenguaje y algo del trabajo de sockets, pero ahora mismo no tocaria java para casi nada, solo , como ya te e dicho ,para juegos que corran en web, todo y eso se lo veo cada dia mas dificil.

No me arriesgaria a decir como acabara java, tiene muchas posibilidades como lenguaje, pero solo eso como lenguaje.... por otro lado en c puedes usar las .dll, no es lo mismo que las clases dinamicas que se pueden cargar desde java... pero menos da una piedra.... me has metido el dedo en el ojo con lo que has dicho de los scripts , precisamente estaba haciendo un mini interprete.... pero no lo niego java tiene mas posibilidades que mi bichejo.

Saludos.                                

                                Si ,si ordenas las faces tendras que transformar a mano.

Me siento culpable por decir que es mas rapido hacer las transformaciones y llamar a drawindexprimitive().... en un principio es asi... pero no siempre si se trata de pocos objetos pero con muchos vertices se hace si se trata de unos cuantos objetos y no demasiadas caras , entonces transforma "a mana", he leido que tendras bichejos de unas 2000 faces???? pues nada se hace "a mano", son pocas, y bla bla bla...

Chao.                                

                                Pues si,BeRSeRKeR!  tines que meter los poligonos opacos de decorado , y de objetos "independientes" , y dejar para el final los poligonos con transparencias , tanto los del decorado como los de los objetos "independientes".

No , no es una locura transformar los vertices uno a uno, se pierde eficiencia, es mejor que lo haga DirectX por si la aceleradora lo acelera, pero no es extraño hacerlo "a mano", de todas formas no entiendo por que dices que no puedes usar el SetTransfor().... puedes hacer un DrawIndexPrimitive() o DrawPrimitive() , cambiar la matriz por la que se transforma y haccer otro, es mas, si utilizas modelos con partes solidas, es mas efeciente esto que no transformar "a mano".

Respecto a las colisiones, todo y que las e tocado, no e profundizado en el tema, pero te dire que en un engine antiguo con el que trastee me hice unas funciones para detectar colisiones perfectas, como es logico todo tiraba muy lento , no hace falta discutir que lo mejor es usar (bounding (box || sphere)), y si necesitas mas precision usar lo que te cuento y si existe colision seguir con las de detencion perfectas.

Espero que te sirva de ayuda!

Saludos.                                

                                Por cierto se me olvida decir ... que el metodo que he comentado no es para dibujar poli a poli, sino todos los polis de golpe del nodo "visible"....                                

                                Jostras! pos no me lo sabia eso , estas seguro?? En documnetacion de la web de nvidia te sueltan que uses un mismo vertexbuffer para almacenar los vertices de barios objetos para no tener que ir cambiando mas buffers de los necesarios, pero me dejas en fuera de juego, realmente no se si sera asi....Entonces habria que tener un vertexbuffer para cada nodo del octree, que no parece lo mas agradable, pero que segurisimo corre mas que ir pintando poligono a poligono, de todas formas despues de la primero que te he comantado , no creo que sea asi....

En fin... si alguien nos puede sacar de dudas??

Saludos.                                

                                Me gustaria seguir con el tema de los vertexbuffer...:

Los metodos que hemos comantado parecen no ser del todo perfectos, yo creo que tiene una sencilla solucion, deveriamos de tener un vertexbuffer con todos los vertices de la "estancia"(por llamarla de una forma :ojo:), y luego tener un indexbuffer con los poligonos de esta , pero , ordenados segun el nodo del octree al que pertenecen, osea , p.ej.:Los 50 primeros poligons corresponden al primer nodo los 45 siguientes al segundo, y asi con todos , asi , cuando tengamos que dibujar los poligonos de un nodo "visible" del octree bastaria con el DrawIndexPrimitive() al que se le pasarion los valores de los poligonos correspondientes al nodo "que se ve".

Respecto a cortar o no cortar, podemos cortar por lo sano... podemos duplicar ese poligono y dibujarlo dos veces(ya se que no os gusta!) o podemos crear nodos "especiales",donde se pongan los poligonos que pasan por varios nodos (los mismos para todos los poligonos! si no , otro nodo, "especial") y pasarles el DrawIndexPrimitive() correspondiente si uno de esos nodos "asociados a ellos" es "visibles".

Espero no complicarlo mas.

Saludos.                                

                                Pues lo de los cilindros parece bastante logico,si tenemos un juego de por ejemplo, futbol podriamos poner un circulo (NO UNA ESFERA) alrededor del personaje , y nos bastaria para que otro personaje no entrara "dentro de el", en un juego como Quake los personajes te pueden venir de arriba, asi que tambien se tendria que controlar en este caso la altura, un metodo facil y rapido.

Saludos.                                

                                Ahora se aclaran las cosas, si Dracula tienes razon, pudiendo hacer BFC por hardware, no hay por que hacerlo por soft, es mas , hacerlo por soft es mas lento que por hard.

Otra cosa es que por soft implementemos los octrees y demas algoritmos para ahorrar polis, pero es ya otro tema.

BFC por soft pudiendo usar hard? ni con una pistola apuntando a mi cabeza!

Saludos, y disculpas por mi post , creo que lo lie mas :lengua:.

Chao!.                                

                                Igual peko de tonto... pero despues de leer el 3 msg de Dracula de este post... tengo la impresion de que no ganas velocidad por que dibujas esas caras que no tienes que dibujar por que otras caras usan sus mismos vertices?? y lo dejo en interrogacion por que realmente no se entiende muy bien lo que decias, pero no sera eso??

Cambiando de tema la eliminacion de las caras en 2d....... o tampoco os he entendido o.... es perfectamente factible, de echo se hacia hace tiempo ,pero no salia bien... por que no lo aplicaban bien..... o me e echo un lio al leeros(DIOS ESPERO QUE NO SEA ESO!).

Saludos.                                

                                Pues eso , e estado en la Web de http://www.gdmag.com, y despues de ver la ficha de la suscrivcion... hay que ser profesional del mundillo, o nop??

Gracias.                                

                                Y que tal Blender? puedes salvar en ASC, y si existe un formato facil de cargar es ese, salvando solo modelos claro, animaciones y demas no podras salvarlos en ASC.

Chao                                

                                Supongo que te refieres a los D3DPOOL_*.... no?

Pues si es asi te explico:

Existen 4(en realidad 3):

D3DPOOL_DEFAULT ->La api eligira la memoria que mas le venga en gana para hacer lo indicas.
D3DPOOL_MANAGED ->Se eligira la memoria que le sea accesible al dispositivo(DMA?)
D3DPOOL_SYSTEMMEM ->Se elige la memoria RAM de la PCera en cuestion
D3DPOOL_FORCE_DWORD ->Una guarrerida de DirectX, texturalmente de la documentacion del SDK de Dx"Forces this enumeration to compile to 32 bits in size. This value is not used"

Dependiendo de lo que hagas te convendra uno u otro, por ejemplo ,LOCKeando y UNLOCKEDeando accederas mas rapidamente si esta en SYSTEMMEM,y no te puedo decir mucho mas.....pero si te enteras de mas lo cuentas!

Chao.