Autor Tema: conversor de mapas .y3d  (Leído 469 veces)

DIVer

  • Newbie
  • *
  • Mensajes: 25
  • Karma: 1
conversor de mapas .y3d
« en: Enero 26, 2018, 12:02:43 pm »
Sería plausible una herramienta que, importando un mapa 3d hecho con bloques de 64x64, exporte ese mismo archivo convertido a formato Yeti3D? Dinamizaría muchísimo la creación de mapas usando herramientas de terceros con sistemas "1 Unidad=1 pixel" o incluso voxelizadores que conviertan cualquier mapa en un voxel compuesto de cubos 64x64.
En mi cabeza suena fácil, "solo" habría que traducir las coordenadas de vertices o caras en el espacio 3d y guardar el resultado en .y3d, pero no tengo la habilidad suficiente para implementar algo así. Alguien se anima a meterle y ver que sale?
"We need more Quake1" - Theodore Roosevelt

l1nk3rn3l

  • Hero Member
  • *****
  • Mensajes: 2002
  • Karma: 257
Re:conversor de mapas .y3d
« Respuesta #1 en: Enero 26, 2018, 03:12:27 pm »
Suena genial,  todo es posible,
solo es buscar un voluntario...   ;D

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6280
  • Karma: 160
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re:conversor de mapas .y3d
« Respuesta #2 en: Enero 27, 2018, 01:54:54 am »
Dependerá de dos factores cruciales:
- Lo bien documentado que estén ambos formatos.
- Encontrar un voluntario con suficiente tiempo y los programas adecuados para hacer las pruebas :D

En mi caso, me manejo bien con la lectura y escritura de ficheros, pero por desgracia no tengo tiempo (ni fuerzas) para ponerme a ello, y además no tengo programas para comprobar los resultados. Tengo un lector hexadecimal, pero necesitaría un visor de ambos formatos que muestre los metadatos.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

DIVer

  • Newbie
  • *
  • Mensajes: 25
  • Karma: 1
Re:conversor de mapas .y3d
« Respuesta #3 en: Enero 27, 2018, 05:17:29 pm »
Dependerá de dos factores cruciales:
- Lo bien documentado que estén ambos formatos.
- Encontrar un voluntario con suficiente tiempo y los programas adecuados para hacer las pruebas :D

En mi caso, me manejo bien con la lectura y escritura de ficheros, pero por desgracia no tengo tiempo (ni fuerzas) para ponerme a ello, y además no tengo programas para comprobar los resultados. Tengo un lector hexadecimal, pero necesitaría un visor de ambos formatos que muestre los metadatos.
Y a pesar de que estas sin tiempo y cansado, aportas varios tips sobre el asunto... impresionante la amabilidad de los que integran esta comunidad.
Bueno, formatos documentados para usar con el mapa que creemos externamente hay muchos (varios .map, algun que otro .bsp...)
lo que no veo por ningún lado son datos reunidos y concretos del .Y3D. Todo está disperso y faltan muchos datos, no se siquiera en que formato se basa... (p.ej. se que el modo8 de DIV viene de otro proyecto que a su vez se basaba en Doom...Yeti en que se ha basado? Quake1? ni idea... el sector 0 con el que comenzamos me recuerda a div-m8 precisamente)
El visor para metadatos Y3D podría ser el propio bennugd, con sus funciones get()/set() y las fuentes, un conversor hecho en bennu sería lo mas compatible y romántico (voy a husmear a ver si suena la campana)
Blender permite importar imágenes como planos, con lo que resulta en un editor con tiles 3d muy versátil para juegos estilo retro o para móvil. Supongo que no sería lo mas complicado el traducir las coordenas de los vertices o caras, siguiendo unas restricciones durante la creación del mapa, al espacio 3D de Yeti... asunto distinto sería que el motor reconociera cada cosa como debe ser (suelo, pared, techo y cielo). Voy a pensar un par de propuestas que podrían inspirar a alguien.
"We need more Quake1" - Theodore Roosevelt

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6280
  • Karma: 160
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re:conversor de mapas .y3d
« Respuesta #4 en: Febrero 03, 2018, 01:25:14 am »
Más que GET y SET, recomiendo abrir y cerrar los ficheros con FOPEN y FCLOSE, y usar FREAD/FWRITE para leer o escribir datos.
Yo suelo crear en las funciones de lectura/escritura de ficheros una variable byte, otra word y otra int, y las uso en función de cuántos bytes necesito leer. El endian suele ser un problema, pero nada que no se solucione con lectura byte a byte y desplazamientos de bytes.

Eso sí, para dar pistas y consejos siempre hay tiempo. De escribir código ya es más complicado, especialmente si estás acostumbrado a dedicarle como máximo 5 horas, y estás todos los días 8 horas en el trabajo picando código :D
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)