Una cámara de fotos dentro del juego en Godot 4: visor, zoom, JPG y medir el encuadre

Junto al baúl de la playa de salida hay una caja con una cámara. Se coge con USAR, se cuelga al cuello y, puesta, el botón FOTO (o P) te mete en el visor: la vista pasa a los ojos del personaje, aparece un marco con el zoom y las fotos que quedan, y se dispara con un clic, la barra espaciadora o DISPARAR. Hay un destello y un aviso con lo que ha salido. Las fotos van a un álbum (L) con rejilla, foto en grande con su día y su hora, y opción de borrarlas. Caben 48.

Cómo está hecho

Una cámara propia en los ojos. El plan era acercar la cámara del juego hasta distancia casi cero, pero el turbo reescribe su ángulo cada fotograma (se comería el zoom) y la cámara orbital deja de girar con una distancia horizontal tan pequeña. El visor usa una Camera3D propia que sigue el giro de la del juego, con su propia inclinación, de −75° a 80°.

La foto. Se esconden las capas de interfaz un fotograma, se lee la pantalla, se reduce a 640 px de ancho y se guarda como JPG en una carpeta que sale del nombre de la partida, así ninguna prueba toca las fotos reales. La partida solo guarda los datos de cada foto. Medido en el PC: unos 15–20 ms en total, un tirón de un fotograma a 60 FPS. Cada JPG pesa entre 13 y 20 KB en la playa, y 61 KB con el filtro Game Boy del estudio de estilos puesto, que también sale en la foto.

La cámara solo mide. Al disparar, por cada cosa que otro mod haya registrado, calcula su alto en el cuadro, cuánto se desvía del centro, si está de cara o de espaldas, si hay algo en medio, la distancia y su postura. Qué es una buena foto lo decide quien registró el sujeto (el bestiario, por ejemplo). La cámara no sabe qué es una criatura.

«Algo en medio» es un rayo contra todo lo que tiene colisión, más muestras del relieve cada 2 m para lo lejano. Pero las copas de los árboles no tienen colisión, así que se miran aparte, como elipsoides, con los datos de dónde crece cada árbol:

static func _hits_ellipsoid(a: Vector3, b: Vector3, center: Vector3, radii: Vector3) -> bool:
	var p := (a - center) / radii
	var q := (b - center) / radii
	var d := q - p
	var t := clampf(-p.dot(d) / maxf(d.length_squared(), 0.000001), 0.0, 1.0)
	return (p + d * t).length() < 1.0

Dividiendo por los radios, el elipsoide pasa a ser una esfera de radio 1 y basta con el punto del segmento más cercano a su centro.

Lo que salió mal

La cámara la hizo un subagente de IA (Opus) en su propio worktree, y varios fallos los vio en fotos de verdad, no en las pruebas:

• Las copas no tapaban. Una manta de aire escondida detrás de un árbol daba 3 estrellas. De ahí los elipsoides.
• El zoom llegaba un fotograma tarde. Una foto justo después de cambiarlo salía con el de antes. Lo destapó la prueba de otro mod, el bestiario.
• No se podía mirar alto. La inclinación de la cámara del juego tiene un tope pensado para jugar; con él, una gaviota a 24 m de altura salía descentrada. Por eso el visor lleva la suya.
• Al entrar, el visor ponía a cero la inclinación de la cámara del juego, y como esa es la que se guarda, cerrar con el visor abierto la dejaba así.
• Sin ventana no hay pantalla que leer: en las pruebas, leerla escribe un ERROR: del motor (y la suite falla), así que la foto sale de una imagen de sustitución y todo lo demás se mide igual.

Al final: 167 comprobaciones propias y 27 mutaciones vistas fallar.

Lo que falta por comprobar

Nada en el móvil: cuánto tarda leer la pantalla a resolución nativa y hacer el JPG, ni los dedos en el visor y el zoom. El sonido del obturador se generó y sus números dicen que no satura, pero no lo he oído. Y las esquinas del marco del visor rozan el botón MENÚ: se dejó así.