Comunidad Game Maker

Diooos, ¡El znear! Nunca lo hubiera dicho xDDD ¡¡Gracias!! Problema resuelto. Siempre uso znear = 1, y debió ser cuando dividí todos los tamaños entre 10, que ahora todo era tan pequeño que entró en el znear... le puse 0.001 y ya funciona ^^

¡Buenas! Esto antes no me pasaba y no sé qué quité o cambié y ahora... ¿Cómo puedo evitar que los planos cercanos a la cámara se corten?



¿Hay forma de resolverlo sin tocar las coordenadas? No puedo alejar más la cámara... Y antes funcionaba bien así.

Lo que hago es un "d3d_set_zwriteenable(false);" al inicio del draw, y lo pongo a true al final de nuevo. Y en el draw, hago varias llamadas a "User Defined Events" para hacer los dibujos. He probado a ponerlo fuera, directamente en el draw, y también falla... también probé a poner el d3d_set_culling y el d3d_set_hidden a false al inicio y nada... No recuerdo qué más podría ser.

@Goganpis: ¿Crees que vaya a preguntarle a un youtuber desconocido y ya? xD Bueno, si no conseguimos sacarlo aquí en la comunidad, queda como recurso

@Clamud: Los escribí yo en base a código que encontré, copypasteando las partes e ideas clave, fórmulas, etc. La idea es sencilla: imagina un suelo rocoso y arriba el cielo. Con los ángulos de euler puedes hacer un típico "first person shooter" y mirar en todas direcciones. Es más, con sólo 2 ángulos puedes hacerlo. Imagina que eres una nave. Si yo quiero, quiero rotar en un tercer ángulo, el roll, y ponerme boca arriba, para que el suelo de rocas sea el techo (ver literalmente arriba como techo lo que antes era suelo) y que mi nuevo suelo, bajo mis pies, sea el cielo. Y si quiero rotar 90º, tener una pared de roca. Quiero total maniobrabilidad para rotar en los 3 ejes pero, desde cualquier rotación, moverme de forma normal. Al ponerme boca arriba, aunque el suelo pase a ser techo, me sigo moviendo de forma normal como si nada.

No conseguí hacer eso con los ángulos de euler, no era coherente, y por eso intentando todo esto :)

Vale. Esto es lo que tengo. No consigo que funcione, pero por todo lo que he investigado es a lo que he llegado y creo entender, y me siento bastante perdido xDD

A la hora de dibujar:

var res = scVecRotateArroundQuaternion(scArray(x, y, z), scArray(roll, pitch, yaw));
d3d_transform_add_translation(res[0], res[1], res[2]);

Pasando como parámetros el punto x, y, z que queremos dibujar, y los ángulos roll, pitch y yaw, nos devuelve el punto transformado sobre el cual dibujar, tomando la rotación respecto al 0, 0, 0, origen de coordenadas, que es donde estará siempre la cámara mirando en dirección del eje x positivo, con el vector normal en la z positiva.

scVecRotateArroundQuaternion:

var arr = scArray(0, argument0[0], argument0[1], argument0[2]), rot = argument1;

var pA = scAxisAngleToQua(rot[0], scArray(1, 0, 0));
var pB = scAxisAngleToQua(rot[1], scArray(0, 1, 0));
var pC = scAxisAngleToQua(rot[2], scArray(0, 0, 1));
var qua = scQuaMultiplicar(scQuaMultiplicar(pA, pB), pC);

var quaRes = scQuaMultiplicar(scQuaMultiplicar(qua, arr), scQuaConjugar(qua));

return scArray(quaRes[1], quaRes[2], quaRes[3]);

Esta parte no sé si está bien. Básicamente creamos 3 quaterniones, cada uno a partir del ángulo y su eje correspondiente (roll para el eje x, pues la cámara mira en dirección positiva, pitch para el y, yaw para el z). Multiplicamos los 3 quaterniones para obtener el final.

Entonces, aplicamos la fórmula mágica v = p · q · p'. Obtenemos el vector transformado por los ángulos, y como ese vector era el punto a transformar, pues obtenemos el punto transformado.

scAxisAngleToQua:

var theta = argument0/2, v = argument1;

var arrNorm = scArrNormalizar(scArray(scCos(theta), v[0]*scSin(theta), v[1]*scSin(theta), v[2]*scSin(theta)));

return scArray(
    arrNorm[0],
    arrNorm[1],
    arrNorm[2],
    arrNorm[3]
);

Tomamos el ángulo como su mitad, y aplicamos la hermosa fórmula para formar un quaternión. Lo normalizamos.

scArrNormalizar:

var arr = argument0;
var lon;

if (array_length_1d(arr) == 3)
    lon = sqrt(arr[0]*arr[0] + arr[1]*arr[1] + arr[2]*arr[2]);
else
    lon = sqrt(arr[0]*arr[0] + arr[1]*arr[1] + arr[2]*arr[2] + arr[3]*arr[3]);

if (lon != 0) {
    arr[0] = arr[0]/lon;
    arr[1] = arr[1]/lon;
    arr[2] = arr[2]/lon;
    if (array_length_1d(arr) == 4) arr[3] = arr[3]/lon;
}

return arr;

Hecho a mano porque no sé si existe un método que normalice, pero por si acaso lo pongo...

scQuaMultiplicar:

var qua1 = argument0, qua2 = argument1, res;

res[0] = qua1[0] * qua2[0] - qua1[1] * qua2[1] - qua1[2] * qua2[2] - qua1[3] * qua2[3];
res[1] = qua1[0] * qua2[1] + qua1[1] * qua2[0] + qua1[2] * qua2[3] - qua1[3] * qua2[2];
res[2] = qua1[0] * qua2[2] + qua1[2] * qua2[0] + qua1[3] * qua2[1] - qua1[1] * qua2[3];
res[3] = qua1[0] * qua2[3] + qua1[3] * qua2[0] + qua1[1] * qua2[2] - qua1[2] * qua2[1];

var arrNorm = scArrNormalizar(scArray(res[0], res[1], res[2], res[3]));

return scArray(arrNorm[0], arrNorm[1], arrNorm[2], arrNorm[3]);

Hermosas matemáticas.

scQuaConjugar:

var qua = argument0;

qua[1] = -qua[1];
qua[2] = -qua[2];
qua[3] = -qua[3];

return qua;

GG Easy.

También estaba el método "scQuaToAxisAngle" pero aparentemente no hace falta usarlo...

¿Alguna idea sobre el tema? Lo he hecho todo a mano con lo que he encontrado y a saber si lo hice bien o si tengo el concepto bien. No sé. Me parece increíble llevar 2 días buscando y no ser capaz de haber dado con la solución. A veces me planteo que tengo algún problema con hacer funcionar las cosas  :-\

@Clamud ¡Mola mucho! Pero no sé si entendí la explicación xDD Yo también usaba theta, phi, r, pero no me funcionaba

@Goganpis un poco como el .exe de Clamud, que te puedes poner tanto en un extremo del meteorito como en otro y en ambos puedes moverte libremente. Que no exista un arriba y un abajo.

@Johann ya sabes que estoy estos días dándole a los quaternions y tratando de entenderlos, por eso no comenté xD Comentaré mis avances más adelante por aquí (n_n) muchas gracias

¡Buenas! Pues tengo una duda gorda matemáticamente que no logro sacarme...

Quiero tener un sistema libre de cámara 3D en que literalmente pueda moverme con total libertad por el espacio sin estar anclado al suelo. Lo más fácil hasta ahora es tener 2 ángulos: cuánto sube/baja la cámara y si apunto a derecha e izquierda, y combinando estos ángulos puedo mirar en todas direcciones, pero siempre estás "pegado al suelo". Yo quiero tener total libertad. Que si miro hacia arriba, el techo sea el nuevo suelo. Que no haya suelo. Que pueda rotar la cámara con un tercer ángulo: rotación respecto al eje de visión.

https://www.youtube.com/watch?v=2xATkQBVidU

Como en este juego. Ahí si tú quieres, si te da la gana, puedes hacer que el suelo sea techo. Puedes volar sobre un suelo vacío, sobre un precipicio infinito, con un techo. O si quieres, puedes volar haciendo que el suelo sea una pared. O sea, rotar la cámara, girando, con total voluntad, y maniobrar de forma normal totalmente independiente de ello...

Para eso necesito 3 grados de libertad, rotar sobre los 3 ejes a la vez, y no sólo sobre los ejes z (profundidad/altura, theta) e y (longitud, phi). Pero no consigo que funcione lo anterior... ya que sigue funcionando como si estuvieras siempre pegado al suelo.

No sé si me he explicado bien y alguien capta a qué me refiero, es un concepto complicado... mi ejemplo era el sencillo:

x -> cos(phi)*cos(theta)
y -> sin(phi)*cos(theta)
z -> sin(theta)

Haciendo que el aumento en x/y sea cos/sin de phi, al mirar a los lados, giro de forma normal. Sin embargo, esto sólo aplica si theta vale 0, o sea, si estoy mirando al frente. Si comienzo a mirar arriba, la coordenada z comienza a aumentar para mirar arriba (sin(theta)) y cancela las horizontales.

Esto funciona para una cámara para mirar en todas direcciones 3D, pero no con la sensación de "poder hacer que el suelo sea techo", ya que siempre miras respecto a que el personaje tiene los pies pegados al suelo, y el suelo siempre será suelo...

Por no hablar que si intento hacer cambios, los sistemas de coordenadas se me invierten y no responden bien...

No haría la pregunta si no fuera algo realmente complejo, pero me está superando...  :'(

Yo no sé qué tan malo sea centrar tu carrera de desarrollador en GM... pero sí creo que lo importante, más que el lenguaje en sí, es la capacidad de hacer cosas y los conocimientos.

No se trata tanto de... saber UN lenguaje en sí. Sino de saber programar en general, tener esos conocimientos para poder desenvolverte ante cualquier lenguaje que te pongan delante.

Luego, se valora mucho el hecho de haber HECHO cosas. Poder decir "sí, he hecho esto y esto". Da igual que estén hechas con un lenguaje menos o más nosequé... eso muestra tiempo, esfuerzo, dedicación, ser autodidacta, estar motivado e ir en serio en estos temas. Yo por eso estuve haciendo un juego con javascript, pero por X temas ahora estoy reintentando en GM otra vez, reuniendo todos mis años de conocimiento para hacer algo grande de una vez, que me jode mucho no haber acabado nunca nada xD (Acabé Four Elements pero eso es de mi época más noob). El hecho de poder tener cosillas acabadas y decir "esto es mío", por lo que yo entiendo vale mucho de cara al futuro... (soy un desgraciao que no acaba ná xD)

Si alguien puede contar o expandir esto que digo, estaría bien, ya que es lo que yo creo y tampoco lo tengo claro. En mis entrevistas de curro yo siempre dije que había hecho proyectos en grupo varios, sin dar detalles ni pruebas y... si me contrataron es por algo. Imagina si puedo decir y enseñar cosas concretas que he hecho y de las que estoy orgulloso xD

¡Genial! Yo desde siempre lo uso, creo que me bajé una licencia cuando la daban gratis hace años... Tengo ahí la key. No sé qué versión sea, debo mirarlo...

Actualmente, tras ir y volver, ir y volver... por temas personales he dejado aparcado mi otro proyecto y estoy retomando OTRO proyecto, uno que planeé por MUCHO tiempo... dándolo todo, tras tantos años de experiencia y nunca acabar nada  XD Y lo estoy haciendo con GMS1. Así que esto me alegra, saber que hay una última versión estable y podré desarrollar en condiciones.

Lo pondré a actualizar entonces!!!

random(X) -> irandom(X) o round(random(X)). El random normal devuelve decimales infinitos y nunca quedará exactamente en posiciones fijas aún tras multiplicar, así que toca redondear

Ya te lo dije por FB pero me hacía ilusión (?)

Estoy pensando en volver a desarrollar en mi antiguo GM Studio, ando recién iniciando. Es una versión gratuita que dieron hace tiempo... ¿Qué tal está el panorama para desarrollar? Habiendo un GM Studio 2, de cara a... soporte, legalidad, mil temas que no tengo ni idea. Llevo años desconectado de todo esto, pero realmente tengo muchísimas ganas de volver a desarrollar aquí. Para mí el entorno es muy cómodo y potente, así que quiero darle duro.

Wow... he probado la función, y... creo que da una iluminación extraña... pero en cierta medida le da un toque interesante... Y creo que, en el peor caso, la puedo activar para dibujar ciertas cosas, aunque no para todo. Aunque... voy a experimentar con ella, se ve interesante.

Y he descubierto qué ocurría. Digamos que... Los cubos que hay en los bordes y esquinas, tienen un código para rellenar todo el exterior de la room de cubos automáticamente, sin tener que poner yo manualmente cubos en todo el exterior... el código estaba mal optimizado y no aplicaba el "no dibujar si fuera de la view" a éstos cubos. Lo arreglé en 1 minuto y 60 fps estables, perfecto... pero ha costado lo suyo encontrarlo. ¡Muchas gracias a todos! ^^

¿A qué te refieres con las sombras? ¿Y con función que se repita mucho? Esto último quizás sea algo de cálculo, pero no sé cómo tomarlo cuando con la iluminación desactivada va bien.

No encontré ese botón de Preview...

Gracias! Sí, sabía que no debía usar esas funciones, y TODO lo hago con d3d_primitive_begin. Pero no sabía que esto también era ineficiente...

Okay, veré de hacer lo del modelo al inicio para los cubos, y si es aplicable a los personajes, lo cual no sé por ahora.

Y no. La cara es un plano central, y debe tener varios planos para hacer una animación dinámica.

Me preocupa que esto viene SOBRETODO al implantar la iluminación, como dando a entender que no es culpa del dibujado de cubos (que antes iba OK) sino a los cálculos de iluminación, que haga algo mal y no sepa por qué... por ahora veré si hacer que los cubos sean un modelo lo resuelve.

También me preocupa que todo se ralentiza más cuando dibujo las partes del personaje, y si no dibujo al personaje va bien... el cual a demás me da problemas gráficos (no dibuja sus transparencias). Todo muy caótico.

Toda mi rallada es que hay gente que hace cosas más compleja, que dibuja cilindros, esferas... mil modelos y mil mierdas con muchos vértices, ¿por qué a mí se me ralentizan PLANOS? No dibujo más que planos, e intentando que sea eficientemente.

Oh, y tanto que se ve mal. Compruebo la variable fps y todo va más lento, asegurado xDD

Bien, cada punto...

- La room está a 60 fps, pero antes de añadir más cubos y de la iluminación (ésta es la principal causante, antes de activarla todo iba bien) todo iba perfecto.
- No utilizo sprites, sólo texturas. Es decir, no uso ningún sprite animado, sólo agarro sus subimagenes para texturas y ya. Y todas las agarro en los evento Create. Aún con esas, los sprites no suelen superar las 2-3 subimágenes.
- La image_speed suele estar a 0, pero por lo anterior no suele afectar.
- No, pero no tengo objetos que salgan de la habitación. Cuando ocurra sí, debo recordar hacerlo.
- Hay muchos cubos, pero no se mueven.
- Todos son 128x128 de media, para usarlos de texturas. Algunos son 256x256, muy pocos, y los que no son usados para texturas, son inferiores a 100x100.
- Si no me mandas foto no lo puedo saber (>uo)7

Lo dicho, todo iba perfecto antes de activar la iluminación, con sólo algunos fps drops momentaneos que creo ahora estaría resuelto, pero con la iluminación se va todo a la mierda... y creo que lo estoy haciendo bien, por todo lo explicado. No sé qué motivos podrían ralentizarlo TANTO.

¡Buenas! Pues este tema me tiene jodido y dudando. Ando haciendo mi juego, que es un plataformas de jugabilidad 2D y personajes y objetos 2D, pero los escenarios son cubos 3D de una sola profundidad. O sea, los PJs se mueven por cubos. Éstos son simples cubos, con 4 vértices para dibujar cada cara. Un problemilla es que cada cara está formada por 5-6 planos para formar una animación. Igual, no dejan de ser PLANOS. A demás, tengo el culling activado, dibujando sólo las caras frontales de los triángulos, el hidden, para dibujar sólo lo que se ve, y no dibujo las cosas que estén fuera de la view. También creo las texturas en los eventos create y no a la hora de dibujar en cada step. Con todo esto, debería ser jodidamente eficiente... pues no. Los fps bajan de 60 a... algunas veces 40 en momentos críticos aleatorios, a veces 50.

Lo peor es cuando implanté la iluminación. Puse las normales a los vértices y todo el rollo, y probé con una pequeña luz. 15 fps constantes... es un infierno. Son sólo cubos, por dios... he visto cosas más complejas, y GM debería estar preparado... ¿Alguna idea de qué puede ocurrir? Lo peor es que mi PC es medianamente eficiente, puede correr cualquier juego del nivel de PS3 con gráficos al mínimo a 60/60.

En un ataque de eficiencia, y recordando lo que pregunté en el pasado, he quitado el evento draw de cada objeto cubo y, en el controlador, me he hecho un bucle que, para cada cubo, lee sus coordenadas y el propio objeto controlador dibuja el cubo en esas coordenadas, sin ningún "with". Así, TODOS los cubos se dibujan en UN solo evento draw, sin ejecutar código del objeto cubo. Pensé que esto aumentaría tanto la eficiencia como me pasó en mi anterior proyecto, pero sigue estancada en 20/60 fps... lo cual no tiene ningún sentido.

¿Qué cosas pueden dejar en la mierda los fps hasta este punto, más cuando sólo dibujo planos y con tanto control de eficiencia? Los personajes también son varios planos (sprites) superpuestos...