Hola!

Perdon si despierto el tema después de tanto tiempo...

Solo me considero un aficionado, y depués de un parón largo que he pasado, quiero ponerme al día con Unity... Compré un libro al que no le he dedicado tiempo principalmente por no tener un espacio adecuado ni los recursos para ponerme a ello... Actualmente no tengo ningún proyecto en marcha ni estoy ligado en ningún equipo...

Soy de barcelona pero no vivo en el centro, se me hace incomodo si tengo que desplazarme cargado del material a diario... Mi intención es dedicarle algunas horas a la semana en horario de tardes y sacar algunos resultados del libro para poder crear algún portafolio,...

No sé si encajo en vuestros requisitos así que antés de escribiros directamente queria dejaros estos comentarios...

Os agradezco que pudierais orientarme un poco

Saludos

 Hola a todos!

Queria comentar algunos de mis avances en la programación de juegos y del motor que he estado haciendo en los últimos años (Hacia tiempo que no entraba y he visto que mis antiguos posts han desaparecido!!):

 - Hace algunos años pude completar una primera "demo" del juego que tenía en mente, un "remake" en 3D del juego Uridium, que lo presenté como proyecto del Master de videojuegos de la UPF.
    - Durante un año trabajé en hacer la demo y el "motor" de juego con las siguientes especificaciones
      - Windows/Directx9,
      - Importación/Exportador de mallas/"diseño de niveles" desde 3dsStudio.
      - Sistema de colisiones basado en Opcode, con un sistema personalizado para poder "caminar" sobre mallas en 3D (para hacer una idea, como el Mario Galaxy o el F-Zero de la N64,)...
      - Algo de integración con Scripting usando Lua, para la generación dinámica de música basada en eventos (aunque no estoy seguro de si todavía tengo ese código o lo perdí :()

   - Por desgracia, nunca he podido llegar a formar un pequeño equipo para llevar adelante el proyecto... No me gusta considerarme un "programador solitario", pero posiblemente puedo llegar a ser bastante terco y creo que como todo el mundo, me siento estimulado persiguiendo mis propios objetivos, supongo que con mi experiencia actual si que he llegado a entender que para llegar a "mi juego", hay que analizarlo con suficiente cabeza para copiar lo que necesitas de los "otros" juegos y finalmente poner tu parte...
   Finalmente, decidí volver a comenzar el proyecto,... Aunque estaba satisfecho con los resultados, supongo que estaba bastante confuso, me faltaba completar las colisiones, la IA, ... Pero cayó en mis manos una copia de libro "Game Coding Complete", con el código fuente completo del motor para Windows y un "didáctico" juego de ejemplo que pensé que podría integrar bien con mi trabajo anterior (iluso de mí), las especificaciones:
      - Windows/Directx9/10
      - Arquitectura basada en MVC y otros patrones de diseño aplicados a juegos,
      - Grafo de Escena
      - Física bullet
      - Integración con a extensión LuaPlus (se puede debuggar de manera remota)
      - Código de IA
      - ... y MUCHISIMO MAS
      * Además yo he añadido:
      - Importación/Exportador de mallas/"diseño de niveles" (incluyendo la exportación del nivel como un octree)  desde Blender en formato propio binario.
      - Adaptación del algoritmo de "caminar sobre malla" al sistema de física...
      - Lógica de juego basada en el patrón máquina de Estados
      - Capacidad para scriptar aspectos del motor de juegos y el comportamiento de los actores de juego desde Lua.
      - ... y mas aspectos que seguramente me dejaré en el tintero
   
   Por el momento, estoy limitando todo el motor al primer minijuego que quiero usar como presentación: Atrapar una bola que se lanza hacia el jugador...
   
   Creo que me faltaría poco para poder liberar una "release", y todavía estoy muy enfrascado en la programación, pero estaré encantando de escuchar opiniones, sugerencias y demás...




   Saludos

@B^)>
   
P.S: No puedo subir imágenes, actualizaré el post cuando lo haga

Gracias por la sugerencia,

:.. Ahora mismo, llevo el motor bastante "avanzado", muy posiblemente si empezara el proyecto desde cero me habría puesto a ello a la hora de sacar un primer prototipo rapidamente, pero ahora mismo mi vena de programador ya no me permite tirar todo el código que tengo hecho  :'( así que solo estoy utilizando Blender para diseñar el nivel y exportar datos... en fin... Encontré un ejemplo de octrees que su autor decía que lo podía integrar bastante bien con el Game Engine de Blender y la verdad que prometía...

En definitiva, al final voy a combinar varias técnicas a ver que tal puede salir... Seguiré comentando ideas de juego que vayan saliendo

Saludos,

@B^)>

Pues no se bien que decirte... ^_^'

La respuesta rápida sería que he hecho unas "pequeñas" adaptaciones del sistema de colisiones de Bullet para poder detectar exactamente el triangulo donde se encuentra el jugador y aunque se que Blender lleva el Bullet integrado no se hasta que punto puedo programarlo/scriptarlo para que haga lo mismo... Eso sin contar que del Game Engine de Blender ni "flowers", aunque podria aprender rápido...

Sin embargo, estoy de acuerdo contigo en que tendría que prototipar el juego rapidamente, pero no tengo ni idea de como hacerlo!  :grrr: Tardé un año en programar la "demo" que comenté al inicio del post y con todo eso no llegué ni a comenzar la programación de los enemigos  :shit: y ahora mismo ando igual de liado para intentar que todo lo que he escrito tenga alguna lógica,...

Sería mas rápido que le pudieras echar un vistazo a la "demo", pero voy a intentar hacer una idea de lo que necesito y a partir de aquí acepto cualquier sugerencia:

- Genero de juego: Shoot'em-up o "matamarcianos" en perspectiva tridimensional, los juegos de referencia podrian ser: "Tempest"(Jeff Minter por si suena) o "Torus trooper" del Kenta Cho, o bien, Wipeout/F-Zero disparando :) ...

  - Por lo poco que se de programar juegos, entiendo que necesito crear un "nivel", como si fuera una pista/carretera donde vas de un punto A a un punto B, y se me ocurre que debo separar la pista en secciones, de manera que en cada sección active los posibles enemigos que atacaran al jugador ... ¿Cual sería la mejor manera/mas rapida de dividir la pista? La manera mas sencilla que he usado, ha sido a partir de algún programa de modelado, secciono la pista como me parece y creo una lista de secciones, de manera que a medida que el jugador avance sobre la pista y entre/salga de cada sección se activan las IA's de cada sección... BSP/Portales ya serían palabras mayores, cierto?
  - ...
 
Estoy absolutamente en blanco  :(
 

   Pensandolo mejor, que tal si el grupo físico solo define las referencias a objetos y en el motor me encargo de montarlo? Estudiandolo por casos:
   -Nivel: Las referencias a los sectores deberían estar antes de empezar a montar el nivel o después? O procesarlo antes y después para hacer comprobaciones antés de cargar los sectores y acabar de montar la estructura después de tener los sectores?
   - Sector de colisión: Debería comprobar que los sectores no se pueden solapar entre ellos. Las dimensiones no deberían sobrepasar las establecidas por el nivel, también hay que añadirlas a la lista de visibilidad? Deben contener el índice de sector del
   nivel?
   - Sector de nivel:Las mismas que para colisión?
   - Puntos de spawn: Ahora caigo! Desde donde arranca el jugador y los enemigos? Defino uno para cada sector? comprobar a que sector existente está asociado...
   - Nave: Los parametros de velocidad los cogería del nivel,...
   - Proyectiles: No creo que influya en el orden
   - Enemigos: No creo que influya en el orden
   - Partículas: Tampoco!!
   
   Segun todo esto, mantendría este orden para cargar los elementos, y tendré en cuenta que el nivel es lo primero y lo último que inicio   
   
   Ahora, dedicándome a los parametros espécificos:
   
   + Nivel:Todo lo que se me ocurre poner sobre variables de nivel que creo que pueda necesitar y no he puesto en otros actores:
      * Tamaño máximo del nivel, o bien reaprovecho los valores de la caja contenedora?
      * Número de Cuadrantes de colisión (hay límites?)
      * Número de Cuadrantes visuales (hay límites?)
      * Escala/Unidad mínima de movimiento (tamaño mínimo de un triangulo?)
      * Sistema de referencia del nivel (RH,LH? XYZ, XZY?)
      * Velocidad máxima de actores en el nivel
      * Velocidad lateral máxima de actores en el nivel
      * Skybox? referencia a los gráficos para pintar los fondos?
   + Camara: Parámetros típicos de camara:      
      * fov
      * aspect
      * near
      * far
      * Tipos de camaras? De juego, que enfoquen a un enemigo, que enfoquen puntos interesantes, pensar en un posible blend de camáras?
      * La posición ya ha sido definida, sin embargo estos datos podrían ser relativos al tipo de cámara que utilizamos
      * Relativo a padre otra vez: Definir la cámara de manera que siempre esté enfocando al jugador?      
   + Sector físico
      * índice de nivel, bitmap de sectores adyacentes?
   + Sector Visual
      * idem que arriba
   * Puntos spawn
      * Velocidad de salida del spawn?
   + Nave:
      * Ratios de disparo? Parametros físicos de masa/material?
   + Proyectiles:
      * Textura para el billboard, entraría dentro de la información de recurso... Parametros físicos de masa/material?
   + Enemigos
      Parametros físicos de masa/material?   
   + Particulas:
      Solo visuales o añado también propiedades físicas?

Buf! Después de tanto escribir, me han entrado muchas ganas de programar! Voy a ponerme a ello

@B^)>

Buenas,

Pues me lanzo al ruedo de los diseñadores para oir sugerencias sobre esta propuesta de diseño de niveles... He visto pocas ideas desarroladas por aquí, así que "patente en trámite" como díria Homer ;), aunque voy a ir muy rápido, intentaré explicar lo mas claramente posible todos los conceptos:

Antes de empezar, breve introducción, aunque también he dejado un post en la sección de Principiantes...

U3d: Un matamarcianos en 3D insipirado en el genero clásico totalmente olvidado hoy día, pero con un novedoso 3D... Se puede descargar un demo "injugable" para pillar la idea
   http://uthreed.sourceforge.net/
   
Ideas que servirian para aclarar el concepto:
  - "Wipeout matamarcianos"
  - "U.N. Squadron en 3D" ó "Uridium 3D"
  - "Un Starfox aun mas 3D!"
  - "i don't understand jack shit about this game... it's unplayable "
 
El guion, me lo saco de la manga ahora mismo: "Atención Red Wings! Atacad y destruid la nave nodriza"... Con este guión, Tiembla Molyneux!!

En cuanto al aspecto técnico del juego que tengo en desarrollo ahora mismo, y para no programadores, el funcionamiento del motor es el siguiente:

  - Una vez el programa se inicia, se lee un fichero de scripting Lua con la definición de elementos del nivel/Actores de juego, cada actor genera una señal/evento en el motor que produce la creación de este actor en los sistemas de lógica y opcionalmente en la física, gráfica y eventos del juego, aquí es donde me entra la primera duda: Hago que cada actor puede generar y responder a eventos del motor/juego(p.ej "ataco si el enemigo está cerca", o "no me pinto si la camara no me ve") o bien, lo programo dentro de la misma lógica de juego? ...
 
  - La programación en scripting con Lua en esta caso, es muy potente para el diseñador y un autentico dolor de muelas para el programador, pero básicamte lo que tengo escrito arriba es cierto y aunque todavía está incompleto... Quiero decir que el diseñador podría llamar a funciones internas del juego tranquilamente para modificar el color de un personaje o pasar el juego de ventana a pantalla completa, pero como programdor tendría que tener en cuenta que esa llamada no petará todo el motor gráfico (pasará seguramente)...
 
   Antés de seguir, simplificaré algunos conceptos de programación, relacionando el sistema de lógica con la librería LUA, el sistema físico con la libreria BulletPhysics y el sistema gráfico con DirectX+Grafo de escena...
 
  Pues ahora pasemos al tema del diseño del nivel: Supongo que lo voy a escribir a continuación estaría a medio cámino entre el guión de SpaceBalls y una clase de tecnología de 3o de ESO (o P-3 soy demasiado viejo para enterarme), ajustense los cinturones...
 
  Los actores de juego que se me ocurren serían los siguientes:
   * Nivel, Cuadrante de colisiones de nivel, Cuadrante visual de nivel, Cámara, Nave, Proyectiles, enemigo/s, particulas.
   * Además también tengo pensado dos conceptos importantes: Los Grupos lógicos de elementos(Por ejemplo el nivel agrupa sectores) y la Jerarquización (pej "la nave tiene una relación padre-hijo con la camara")
   
   El método de trabajo que yo utilizo además de lapiz y papel, es usar Blender como si se tratara de un editor de juegos 3D, me dedico a ir poniendo "cubos" en la escena y empiezo a ponerle nombres absurdos a cada uno y a añadir la información que se me ocurra en las properties, una vez hecho esto a partir de un script de Python exporto toda esa información al fichero de exportación en Lua y ya puedo probarlo en el juego. La principal ventaja que persigo es no modificar el código fuente para ir haciendo pruebas de nivel, chulo? Ójala fuera tan fácil... Con el Blender tambien puedo poner una cámara en cualquier parte y hacer un render rápido para ver si las dimensiones de los objetos se aproximan a lo que quiero ver,...
     
  Describiendo mas detalladamente los elementos, pienso que siempre debe haber información común y específica de cada Actor:
   - Común:
   * Tipo de actor
   * Nombre
   * Matriz/Posición del actor
   * Color (no lo he hecho pero si que recuerdo ver en algún juego el blending de colores para diferenciar a los jugadores/IA's/etc...)
   * Tamaño de la caja contenedora (Bounding Box)
   * Relativo a Padre?
   * Grupo lógico al que pertenece
   * Sistema gráfico: Indicar un tipo de forma básica (cubo, esfera) o una referencia a un módelo 3D
   * Sistema Físico: En este caso Bullet obliga como mínimo a definir dos bytes(8 bits):
   ** Flag de colision(un número del 1 al 256 en multiplos de 2, 1,2,4,8....256) y
   ** Mascara de colision para explicar como colisiona cada actor con el resto de actores físico (cualquier valor entre 1 y 256), 0 indicará que no hay colisión posible. Este es el sistema mas sencillo/primitvo que ofrece Bullet aunque otras posibilidades incluye código mas complejo (mejor no pensar en ello todavía)
   En Bullet se pueden definir objetos rígidos con y sin dinámica (respuesta a una colisión) y "fantasmas" (detectan una colisión sin afectar al objeto colisionante, que seguramente debo utilizar para activar señales al sistema de lógica)   
   ** Grupo físico: Sin llegar a tener un sistema de animación de personajes, Bullet permite que dos a más objetos físicos estén relacionados a través de una "interfaz de acciones", el ejemplo mas claro sería decir que si pusiera un vehiculo-coche, Bullet podría entenderlo como un cubo/chasis y cuatro donuts/ruedas unidos por ciertas reglas físicas y manejados a través de conceptos como volante,dirección, freno, etc... Los elementos físicos responden independientemte pero ¿milagrosamente? funcionan de manera conjunta...  :o
   Es decir, posiblemente para cada elemento del grupo, definiría la forma física y los flags de colisión, aunque pensandolo bien, estos elementos también debería indicarlos en el sistema gráfico... Me estoy mordiendo la cola... :(

Me iré a comer y después seguiré comiendo la olla... :)_

@B^)>

Ahora que ya he empezado no voy a parar...

En cuanto al motor gráfico, el aspecto mas "potente" es la serialización de mallas: Utilizo mi propio sistema de exportación de mallas indexadas (sin stripificar) para las naves y los niveles. Sin llegar al nivel del MD3 o formatos parecidos, basicamente exporto estructuras de datos de tipo vertex Buffer, sobre un fichero binario que entran directamente a los buffer de la memoria gráfica, tengo definidos dos formatos, k3d para modelos sueltos y k3s para un nivel completo basandome en un sistema de Portal-Rendering, ahora mismo el exportador está programado en Python para exportar desde Blender, aunque en el Master lo programé sobre el MaxScript del 3DSMax...

Explicaría otras cosas como la cache de recursos, la definición del nivel por scripts de lua o el módelo MVC que he aprendido del GameCoding, pero abriré un nuevo en la sección de diseño para comentar otra dudas...

Saludos,

Gracias por los comentarios,

Igual no lo he explicado bien, tengo muy claro que lo que enseño es el prototipo inacabado que hice hace cuatro años y decidí tirar todo el código y volver a empezar, cuesta mucho de apreciar el valor de la programación, teniendo en cuenta varios aspectos:

- El motor del juego estaba hecho desde cero, me basé en un tutorial de flipcode llamado "Enginuity" al que dediqué tres o cuatro meses, tiempo que debería haber aprovechado en aprender mas técnicas de 3D para la parte gráfica... Como mínimo a hacer transparencias entre otras cosas...
- La idea de "atacar una nave nodriza" a mi tambien me encanta, si teneis la oportunidad de jugar al Uridium 2 de Amiga se ve mas claramente la idea en 2D, claro... Pero en 3D es muchisimo mas complicado, supongo que los únicos juegos de donde sale la influencia sería el Wipeout o el F-Zero de GameCube donde las pistas de carreras son autenticas montañas rusas, pero sobre todo y eso es lo que mas me importa es que la cámara no determina la posición del jugador y por tanto el punto de referencia para entender donde está la derecha o izquierda... Hace poco me comentaron que el sistema de cámara funciona igual que el del Mario Galaxy, y me hacía gracia pensar que lo había desarrollado tres años antes!
Vsualmente, es imposible de explicar todo el trabajo que hay detrás para que la nave se mueva, en un juego típico en 3D lo normal es calcular una altura fija sobre el terreno en el eje de las alturas y quedarse tan pancho,... Sin embargo, cuando uno de los profesores del Master me creó un sistema de colisiones con terrenos basado en triangulos arbitrarios me metí en un lio de proporciones inimaginables... Si se piensa en ello, no es tan sencillo como pueda parecer ya que para poder moverte sobre un plano de cualquier orientación, no sirve de nada detectar donde está el arriba y el abajo, tienes que tener en cuenta todos los triangulos del terreno y sus orientaciones y todavía es peor para conseguir cambiar de un triangulo a otro, hay que detectar exactamente las aristas de salida y entrada entre triangulos y aun peor es que tienes que conocer la libreria de colisiones al dedillo para poder integrar esta idea, me he pasado otro medio año consiguiendo reprogramar este sistema dentro de las físicas de Bullet.
El segundo problema que hay detrás de esto es que una vez funcionando, la camara no se puede colocar hasta que la nave esté fijada correctamente a un triangulo, si esto falla, no hay nave ni camara! Además hay que "parchear" la camara en la medida de lo posible para que relativamente la nave siempre quede en la posición inferior de la pantalla pero al mismo tiempo te permita ver un rango del nivel hacia el que avanzas y por el que deben venir los enemigos...
Y aun mucho después de esto, hay que tener en cuenta que el modelado de las pistas ha de ser consistente, con que un solo triangulo no esté bien orientado o se borre sin querer o el paso de un grupo de triangulos a otro falle, todo el sistema se descompone... En definitiva, una autentica locura...

Creo que he superado el límite de carácteres...

Hola,

Buscando por mis "documentaciones", me parece entenderlo como un fichero INI típico de windows, también pone que podrias usar la función GetPrivateProfileInt de la API de windows, si no estas en windows tienes que parsearlo por tu cuenta :

No se si estos ejemplos te funcionarian...

Código (cpp) [Seleccionar] Expand


bool folder = ::GetPrivateProfileInt(_T("Main"), _T("Folder"), false, "fich.ini") ? true : false;
bool fullscreen = ::GetPrivateProfileInt(_T("Config"), _T("Fullscreen"), false, "fich.ini") ? true : false;


En mi versión del SDK de windows esta función llama a GetPrivateProfileIntW o GetPrivateProfileIntA según si el proyecto usa UNICODE o no...

Saludos,

@B^)>

Salam alekum! mira que saludo mas original...

Me llamo Sergio y soy de Barcelona, llevo algún tiempo registrado aunque creo que es la primera vez que escribo, así que saludos a todos y felicidades por esta maravillos comunidad de Strateros...

Supongo que me podría incluir dentro del grupo de principiantes aunque tengo cierta edad  y experiencia: Soy ingeniero en informática y también he estudiado un Master de Videojuegos,... Mi objetivo es trabajar como programador de videojuegos y por supuesto pretendo desarrollar un proyecto como carta de presentación, aunque estoy llegando a un punto límite... Me considero un "programador aventurero" con una idea en la cabeza y los recursos mas económicos posibles para ponerlo en marcha, trabajando en casa en mi tiempo libre, mucho, ahora que estoy en paro.

En cuento al proyecto, que tengo bautizado como "U3D" pretende ser un mata-marcianos inspirado en juegos de la antigua escuela ("Uridium 3-D" sería el nombre para los jugadores veteranos de los 16-bits ;) ) .Un buen punto de referencia es el remake del "Tempest" que hace Kenta Cho en "Torus trooper" aunque con menos rafagas de disparos, en definitiva, adaptando las reglas de los matamarciandos como simplicidad de movimientos, enemigos sin inteligencia, rapidez de reflejos y todo movido en un universo 3D por alguna targeta gráfica con billones de triangulos por segundo, ... Por soñar no me quiero quedar corto :P...

Antes de continuar, desde aquí podeis descargar el primer "prototipo" inacabado hasta la fecha, por cierto, el comentario que me han hecho en la página me parece muy acertado, creo que lo pondré como cabecera del título:

http://sourceforge.net/projects/uthreed/

(para windows y corazones fuertes, usar los cursores para moverse y el ratón para disparar aunque no hay colisiones, 'c' cambia el modo de la camara. Tengo un fallo engorroso de programación con las mallas que hace que la camara se vaya al infinito, 'ESC' para apagar, por cierto el programa a veces no cierra bien y hay que matarlo desde el administrador de tareas...  :grrr:)

Resumiendo un poco, estoy desarrollando el motor/juego de manera gratuita como tarjeta de presentación, las especificaciones de juego serían para PC con windows, versiones recientes de DirectX y targeta gráfica 3D.  La programación del juego es en C++ utilizando Visual Express 2008 , aunque nunca he conseguido superar una prueba de programación en las entrevistas de trabajo :) ...  en algún momento diseño o analizo los diagramas de clase con algo de UML utilizando BOUML...

Utilizo el motor de programación didáctico del libro "Game Coding Complete" de Mike McShaffry, para el que no lo conozca se puede resumir como un motor de juegos basado en el patrón de diseño MVC (incluyendo gestión de eventos), con soporte para DirectX y Shaders, Grafo de Escena, caché de recursos, Scripting con LuaPlus, integración de la libreria física Bullet, sonido con DirectAudio/soporte OGG y hasta un juego completo de ejemplo que funciona perfectamente, llevo mas de un año trabajando con él y iluso de mi, pensé que con todo eso acabaría en dos días... Antes de que alguien diga algo, me interesa aprender a programar, no hacer juegos con motores cerrados.

En cuanto al diseño, utilizo Blender como herramienta de modelado/editor de niveles, mis modelos son un poco "cúbicos" ya que no se trabajar en 3D, pero me defiendo lo suficiente para poder importar modelos que encuentro por internet y programar los exportadores de modelos y niveles a un formato propio utilizando el Python de blender.

Lo único que puedo decir es que despues de todo este tiempo sigo un esquema de trabajo caotico, sin ninguna documentación, con un modelo que supera las ¿cien y subiendo? clases, tampoco tengo claro cuanto tiempo podré seguir trabajando sobre el proyecto, y tampoco tengo experiencia ni ninguna dirección para poder confirmar en que dirección tirar... Aun así, ya he llegado a un punto de saturación en el que creo que tengo suficiente base para empezar a programar la lógica de juego, aunque el agotamiento mental ya es alto   :-X...

Supongo que esta no es la mejor manera de pedir algún tipo de colaboración, aunque me imagino que este tiene que ser el día a día de hacer un juego:
-  Tengo claro que aunque la propuesta en apariencia sencilla y divertida, pero no acaba de calar, pero una cosa que no puedo evitar decirme es que si no tengo la posibilidad de hacerlo ahora, dentro de la industria las posibilidades serán todavía mas escasas... Me llevé un  "mal sabor de boca"  al acabar este proyecto en el Master después de trabajar como un loco durante ese año. Sin pretender desanimar a nadie, estoy de acuerdo con un comentario sobre un Modder amateur del L4D que leí hace poco: "Hacer un videojuego es la tarea peor recompensada que conozco"...
- No estoy muy interesado en los temas de diseños conceptuales ni los gráficos de juegos, me gustaría que fuera visualmente vistoso, pero en mi caso como programador prefiero ver cuatro cubos persiguiendose que una explosión que me ralenticé mi pobre Radeon...
- Me costaría bastante explicar todo el trabajo realizado para poder ver como repartirlo, el código está bastante saturado y mal comentado, no me considero ningún crack en matematicas 3D, DirectX, ni estructurando el código,... y supongo que estoy afectado de esa extraña enfermedad del programador de no quere enseñar el código para que no te lo copien o aun peor me lo tiren abajo...

En definitva, que con este post no pretendo ir mas allá de explicar la situación actual de mi proyecto y tampoco tengo ninguna expectativa de despertar algún interés. Me digo a mi mismo que tendría que estar diseñando un nivel en vez de perder medio día explicando cosas sin sentido...

@B^)>

Hola,

Este es mi primer post por aquí, saludos a todos!  :)

El caso es que estoy haciendo unas pruebas en OpenGL para importar directamente arrays de vertices indexados desde Blender hacia mi motor (usando glDrawElements sin extensiones)... Mas que nada por aprendizaje tengo claro que prefiero hacerlo así en vez de usar algún formato de exportación... Aunque finalmente puedo ver el modelo con la textura en mi motor, no se acaba de ver bien (ver imagen si la puedo subir), y no tengo claro si es un problema de la parte de OpenGL o de la exportación y hasta donde llego creo que he limpiado el DepthBuffer y he probado a activar/desactivar el cull y con todas las funciones del depth buffer que se me han ocurrido

Podeis sugerir alguna ayuda? Gracias por adelantado

@B^)>

Mas o menos el código para el render de cada frame es este...

Código [Seleccionar] Expand



glFrontFace(GL_CCW);
glEnable(GL_DEPTH_TEST);

glDisable(GL_ALPHA_TEST);
glDisable(GL_STENCIL_TEST);
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
glDepthFunc(GL_GREATER);

glDepthMask(GL_TRUE);
glShadeModel(GL_SMOOTH);
glDisable(GL_CULL_FACE);

glViewport(0, 0, 640, 480);

glClearDepth(0.0f);
glClear(GL_COLOR_BUFFER_BIT+GL_DEPTH_BUFFER_BIT+GL_STENCIL_BUFFER_BIT);


glLoadIdentity();