Comunidad Game Maker

¡Buenas! Pues tengo una cámara con una posición 3D dada, digamos "x, y, z". El problema es que si me pongo contra un muro, la cámara puede quedarse dentro de él, viendo las cosas desde ángulos incorrectos o hasta pudiendo ver cosas que hay detrás de las paredes. Incluso si no ocurre esto, podría ocurrir que la cámara quede al otro lado de un muro, sin colisionar con nada en x, y, z, pero sí colisionando en la línea, quedando la cámara al otro lado de la pared y también viendo cosas que no debería poder ver.

Hice un bucle para calcular en qué coordenada poner la cámara, comenzando en el personaje, sumando 1 píxel a la distancia, calculando que no haya colisión, y así iterar hasta llegar a la posición de la cámara, habiéndome asegurado que entre el personaje y ésta no haya sólidos. Pero iterar tanto y buscar colisión en cada iteración dispara el coste. Intenté poner un modo "económico" en que hiciera saltos por ejemplo de 50 en 50 píxeles (los muros son de tamaño 150), pero a veces los atraviesa igual.

También pensé alternativas, como dejar que la cámara atraviese los muros, pero si lo hace, poner la vista en negro, o teletransportarla al personaje, o mil cosas.... pero ninguna me convence. Y el problema principal es saber que entre la cámara y el personaje no haya sólidos y colocar la cámara a la distancia máxima (pegada al muro) sin disparar el coste con un bucle y mil comprobaciones.

¿Quien haya hecho algo similar, cómo lo arreglaste?

Vale... al final resulta que draw_set_color sí funcionaba con modelos si usabas el draw vertex base SIN especificar color ni alpha... Al final encontré una forma de lograr mi efecto deseado sin especificar alpha en los modelos, y entonces me agarró el alpha global. La vida xD Gracias por todo. Lo de los shaders podría estar bien tenerlo en cuenta.

@bygdle, agradezco la explicación elaborada, pero (más o menos) eso es lo que ya hacía, y precisamente lo haces con primitivas.

CitarDibujé primitivas, pero creo que también funcionará en vértices de modelos.

Precisamente el problema es que con modelos NO funciona. Ignora totalmente el draw_set_alpha y draw_set_color y toma los definidos por el modelo, los inmutables.

@Clamud Sin duda... bastante complicado tengo ya las texturas como para eso xD Y serían demasiadas, tengo que tener muchos tonos de color. Lo del shader no entendí...

EDIT: Vale. Entre una cosa y otra lo he resuelto. Activé la fog en negro, y segun la distancia, los objetos se van oscureciendo, así que lo pude reducir a sólo 1 modelo donde ya no necesito que sus vértices tengan colores dinámicos, pues el fog ya lo hace. Aunque por si alguien sabe, dejo esto abierto, quizás a futuro hace falta para otra cosa...

¡Buenas! Gracias, pero me expliqué mal. Da igual si creo los modelos manualmente o mediante una aplicación que yo haga. El problema es, que en ambos casos, debería usar d3d_model_vertex_texture_colour para definir colores en distintos puntos del modelo. Y al dibujar ese modelo, ignora mis draw_set_color, cuando quiero que se mezclen. Draw_set_alpha no sirve para esta tarea, pues debo definir el alpha (y color) de cada vértice con el método descrito, creo.

¡Buenas! Pues yo creo en Create de un objeto controlador modelos usando las funciones d3d_model_create, d3d_model_primitive_begin y d3d_model_vertex_texture. Entonces a la hora de dibujarlo con d3d_model_draw, yo puedo hacerle antes un draw_set_color y un draw_set_alpha sin problemas, y se aplica correctamente. El problema es cuando el modelo lo creo con d3d_model_vertex_texture_colour, pues es necesario que diferentes vértices tengan diferentes alphas y colores. Al dibujarlo, me ignora el draw_set_color y el draw_set_alpha.

Es NECESARIO usar modelos, pues sin ellos iría demasiado lento. Logré resolver esto creando 10 modelos distintos, copia, cada uno con colores distintos en los vértices, y llamando a cada uno según la situación, pero a futuro con otros modelos sería una locura seguir con esta técnica, y molaría hacer limpieza de modelos innecesarios. ¿Alguna forma de que un modelo con alphas y colores definidos en sus vértices, tenga en cuenta el draw_set_color y draw_set_alpha? Que el segundo se aplique, se sume, sobre el del modelo, básicamente. Igual que cuando tengo un sprite con colores distintos en distintos pixeles (modelo con colores distintos en distintos vertices) y le aplico el color encima con draw_set_color, etc.

EDIT: El título original era "Intentar entender cómo aplicar los quaterniones para rotaciones en 3 ejes". Pero logré (parece, debo testear más, pero tiene muy buena pinta) el resultado con ángulos de euler.

- Debo tener una matriz de rotación iniciada en identidad, y cada step actualizarla con el pequeño incremento en ángulos de ese step, multiplicando por las matrices de rotación correspondientes en orden (mi caso, x-y-z). Voy acumulando la matriz con la rotación TOTAL.
- Cada step, desde el controlador, debo almacenar esa matriz para tener registro de la matriz antes de hacer la actualización.
- Cada step, para cada objeto que rote, debo usar la transpuesta de la matriz anterior almacenada (del step anterior, antes de aplicar la rotación de este step) para mover el objeto al inicio. Ahí, le vuelvo a aplicar la matriz acumulada con el step actual, para moverlo a su posición correcta.
- Cada step, el personaje se moverá como si estuviera siempre en x=0,y=0,z=0, y con los tres ángulos en 0,0,0. En su lugar, al moverse él, mueve las coordenadas del resto de objetos a la inversa, así como sus ángulos.

Hay que duplicar las operaciones (operar con dos matrices para cada objeto) en vez de una como tenía en el caso anterior, pero por ahora es la única forma que tengo de evitar los errores de calcular la matriz de golpe con los 3 ángulos sin tener su avance progresivo.

¡Buenas! Realmente siento que no puedo resumir el problema en un título.

Imaginad un stickman en 3D con una corbata que mira abajo.



El sprite de la corbata es 2D y SIEMPRE MIRA HACIA LA CÁMARA.



Por mucho que el stickman rote, la corbata siempre apunta hacia abajo. Qué pasa. Que quiero que la corbata esté pegada a su cuerpo. Y tenemos un problema cuando entra en factor una segunda variable. La inclinación.



Al rotar 90º, la corbata ya no mira hacia abajo. La corbata también ha rotado 90º. Si rotamos 45º, la corbata también rota 45º. QUIERO ESO.

El problema es que el stickman es 3D, y hay más rotaciones. Tenemos una variable, la inclinación. Y tenemos otra variable, la DIFERENCIA ENTRE LA CÁMARA Y LA DIRECCION DEL STICKMAN. Si la cámara y la dirección del stickman es la misma (vemos su espalda), da igual cuánto se incline, la corbata siempre rota 0º.



En esas 3 imagenes, tenemos una "d" de 0 (diferencia entre la direccion de la cámara y la dirección del cuerpo), y unas inclinaciones "i" de 0, 45 y 90 (en la tercera está tirado contra el suelo y vemos su culo). En los tres casos, la corbata no rota.

El problema es que hay muchos casos intermedios y no consigo sacar una fórmula que, dadas esas dos variables, me de la rotación de la corbata.



Por ejemplo, si "d" = 90 y "i" = 45, bien, la corbata es 45. Pero si "d" = 45 (no está ni de espaldas ni de lado) y se inclina "i" = 45... ¿cuál es el ángulo de esa corbata? ¿22.5? ¿Y para el resto de ángulos? No saco la fórmula xD

EDIT: ambas variables se pueden llamar "phi" (diferencia) y "theta" (inclinación) si es más cómodo (?) ángulos eulerianos (?)

EDIT2: Al final lo "resolví". La mejor forma de resolver un problema es evitar que haya problema en primer lugar. Ruta alternativa. Tengo que retocar porque si te pones al detalle no queda tan bien, pero creo que me vale xD Si alguien quiere resolverlo por la curiosidad adelante (?)

Gracias por responder :D Lo he probado, conseguí convertir x,y a enteros según pude comprobar pero continuaba fallando ;_;

al final hice lo que odiaba (?) pero en vez de anclar al PJ en el centro, hice que cada vez que el PJ se alejara X distancia del centro, teleport al centro y teleport inverso a todo lo demás xD Por ahora parece que funciona bien. Los demás objetos sí están en coordenadas super lejanas, espero que eso no provoque problemas, pero podría arreglarlo con otra chapucilla (???)

¡Buenas! Pues ando necesitando que mi juego use números un poco grandes para las coordenadas de mis objetos. Definí el límite como 1 000 000, pero ocurre que a medida que me acerco (pasando del 100 000), las cosas comienzan a ir mal... algunos gráficos y controles fallan. Y si regreso a coordenadas pequeñas, se soluciona. ¿Alguna idea de por qué podría pasar? No veo que sean números tan grandes, pensé que GM usa decimales de 32 bits y eso alcanza para muchos millones. ¿O quizás aún siendo relativamente pequeño, a partir de 100 000 comienza a perder precisión? Aunque sea poca, los problemas se notan... ¿Alguna forma de arreglar esto?

Sé que una opción es que mi personaje esté siempre quieto en 0,0, y en su lugar mover el resto de objetos. Intentaría evitarlo porque le daría la vuelta a todo y me complicaría, pero al menos está ahí... ¡Gracias!

Nombre del creador: DarkKRuleR.
Breve descripción de su función: Calcular la distancia entre un punto y una recta.
Ejemplo para el que yo lo usé: dado un proyectil de coordenadas xR, yR (el punto en la recta) y dirección angR (la dirección de la recta), y un objetivo de coordenadas xP, yP (el punto separado de la recta), calculando la distancia del punto a la recta (del objetivo al proyectil) puedes calcular si éste impactará antes de disparar. Puedes añadir los radios del proyectil y/o del objetivo, y calcular si la distancia dada es menor que su suma, para calcular si el proyectil gordo impactará en el objetivo gordo.
Versión GM utilizada: GMS 1.4.
Código del Script:

[gml]/// scLonPuntoRecta(xP, yP, xR, yR, angR)
// xP, yP: punto separado de la recta.
// xR, yR: punto contenido en la recta.
// angR: ángulo de la recta.

var xP = argument0, yP = argument1, xR = argument2, yR = argument3, angR = argument4;
var xV = dcos(angR), yV = -dsin(angR);

// Obtenemos la ecuación general de la recta en la forma Ax + By + C = 0.
var A = -yV, B = xV, C = -xV*yR + yV*xR;

// Dividimos la ecuación de la recta general sustituyendo el punto, entre la longitud de A,B,
// para obtener la distancia deseada.
var sustituida = xP*A + yP*B + C;
var longitud = sqrt(A*A + B*B);
return abs(sustituida/longitud);[/gml]

¡Buenas! Vengo con una duda nueva.

No me he olvidado que tengo esta pregunta pendiente:
- https://www.comunidadgm.org/preguntas-y-respuestas/al-dibujar-una-surface-los-alphas-no-funcionan-bien/
Pero al final resolví el problema simplemente no usando transparencias, pues me di cuenta que usarlas realmente era peor aún si lo resolvía. Sin embargo, quiero mantener la pregunta "congelada" porque dicen cosas interesantes que podrían ser útiles para el uso de surfaces en el futuro si me topo con algo similar  :-[

Al tema... (?)

Estaba pensando en los errores. Después de todo el testeo obvio, es inevitable que incluso así puedan escaparse algunos errores. Los errores sutiles que no interrumpen la ejecución ni joden el flujo del programa están bien. En plan, ataco y no hago daño por X motivo, no pasa nada, le hago daño de otra forma. O el personaje falla el movimiento segun X circunstancia concreta, no pasa nada, puedo seguirme moviendo. Simplemente son reportados y parcheados y ya. Si el error jode el flujo de ejecución no se puede hacer nada, sólo rezar que se pueda recuperar.

Sin embargo, están los errores que petan la ejecución, la ventanita de windows. ¿Hay alguna forma de evitar que estos errores salgan? Que si fuera a salir este error, simplemente el juego no diga nada, o poner el error en un .txt para poder informar al desarrollador, pero sin que pete la ejecución, porque quizás puedes ignorar esa parte de código y seguir jugando normal. No funcionaría del todo bien, pero quizás hay suerte y puedes seguir jugando.

Básicamente pensé que... sería muy jodido tener esos errores que bloquean y cierran el juego, y pensé si había alguna forma de desactivarlos para el jugador, que no aparezcan.

Y si hubiera la opción, ¿es aconsejable usarla? Jodería mucho la experiencia de juego, ¿o no?

¡Gracias! Le echaré un ojo al itch.io
Sehh, ir mostrando el juego poco a poco es importante... y hay que tener cuidado. Subir algo mal puede costarte caro ^^u No tengo twitter... -pensando- además de esa me recomendaron kickstarter, y también lo quiero subir a Steam. ¿Por qué iba a ser malo subir a varias a la vez? Más público y difusión :0

Los detalles... rebotar en la cama y sofá... mover la silla y subirte encima... chocar con el techo... La cantidad de detalles, el humor, lo original... Me ha dejado totalmente boquiabierto. De haber ganado tú sin duda hubiera sido merecido, estaba complicado xDDDD

Ahí le entré. ¡Me he enamorado de la app mostrando los participantes en tiempo real y automáticamente! Menos mal que no la cagué y subí una versión errónea  :-[

Sin duda mi yo de hace años fue idiota por no entrarle a estas cosas, o supongo que no me sentía preparado, pero ahora soy diferente >: )

-Tomato intensifies-

Cita de: Arcadian en Octubre 31, 2019, 01:52:19 PM
El tema entiendo que es fijo, navidad, vale, pero por qué tiene que tener 5 niveles, mínimo?

Y si no tiene niveles? Si me da por hacer un ajedrez navideño online, qué quiere decir 5 niveles?

Haces un ajedrez con 5 oponentes :v xDDD

Venga, entre una cosa y otra me habéis convencido, haré un sencillo minijuego para tomar un descanso de estar 100% con mi otro proyecto. El tener 2 meses para hacerlo ha sido la clave, con tiempo y calma todo sale :)