Comunidad Game Maker

Primero, mil gracias por responder, me has dejado flipando :D

He intentado implementar el segundo que parece más fácil. Me he asegurado que lo he pasado sin errores, y no funciona, en ninguno de los dos casos (alternando los +-)... debería ver el sprite SIEMPRE con el mismo ancho, mientras que el alargado (distancia de la recta AB, o sea, alargado del sprite) no, y no ocurre... me he dado cuenta que Cz no se usa. Pero bueno, quiero entender e implementar al menos el segundo, que lo veo más viable. Supongo que mi idea era correcta, y antes de rotar en "y" y luego en "z", PRIMERO tengo que rotar en z en un valor igual a "a"...

Luego he intentado entenderlos, y simplemente no lo logro. Por qué rotas el vector de la cámara... sé que tiene que usarse la cámara para obtener la rotación z inicial, pero no lo pillo para nada :C Por ahora no hablo del primero, eso ya lo entiendo 14 veces menos

Buenash! Pues veréis, modo 3D, yo tengo un sprite plano ALARGADO mirando hacia el eje x positivo. O sea, su normal apunta en ese eje. Está en vertical.



La recta AB indica que el sprite está ahí en vertical, con el plano mirando hacia el eje x. El sprite está colocado encima de la recta AB, tocándola al 100%. Entonces yo aplico 2 rotaciones al sprite: primero una rotación en el eje y de "σ" grados, que hará al sprite "agacharse", y luego otra en el eje z de "φ" grados, que hará al sprite rotar y mirar alrededor. Al finalizar tenemos la recta AB alterada, como en el dibujo, con esos 2 ángulos.

Mi objetivo? Rotar el sprite sobre la recta para que se ponga mirando a la cámara. No quiero que el sprite mire al 100% a la cámara, sino que lo haga sin separarse de la recta. O sea, que puede quedar reducido a lo largo de la recta, pero no a lo ancho de ésta.

Para ello, PRIMERO aplicaré una rotación en el eje z y así, después de rotar sobre el eje y y luego sobre el z otra vez, el sprite final estará como quiero. El problema es cómo calcular esa rotación z inicial (si mi planteamiento es correcto). Debería poder calcular esa z inicial a partir de las rotaciones siguientes "σ" y "φ", pero no me sale.

Cabe decir, que la cámara puede estar en cualquier altura, arriba o abajo, y eso se debe tener en cuenta. La idea es que da igual desde dónde mires, SIEMPRE tienes que ver el sprite plano mirar a la cámara, pero sin que se separe de la recta AB. Es decir, rotar el sprite alrededor de su recta AB (o sea, rotarlo en z al inicio, antes de nada) para que al final mire a la cámara

Creo que si necesitas usar un with para muchas instancias, el problema es de diseño. Todas ellas deberían tener un parent en común, necesitando un solo with. Por ejemplo, si es un with para todos los objetos enemigos, sólo deberías hacer un with(obEnemigoParent), siendo ese el parent de todos los enemigos

Buenas ideas, sin duda.

He confirmado que ENTRA en la porción de código que toca, que ENTRA en el script (sólo lo llamo aquí, en ninguna otra parte más) y...

if (scKey(vk_space)) {
with(argument0) {
    obCtrl.vrPlaceMeetingWith = place_meeting(argument1, argument2, argument3);
    show_message("A"+string(place_meeting(argument1, argument2, argument3)));
}
show_message("B"+string(argument0 == obCly));
show_message("C"+string(argument3 == obPilarCristales));
show_message("D"+string(obCtrl.vrPlaceMeetingWith));

return obCtrl.vrPlaceMeetingWith;
}

A0, B1, C1, D0.
He pulsado espacio justo cuando yo veía que ambos objetos, Cly y PilarCristales, colisionan. Asegurado, pues el segundo temblaba, y sólo pasa mediante un código a parte cuando colisionan. Resultado anterior, no lo ha detectado. Nadamás pulsar espacio ha mostrado eso anterior. Ambos place_meeting devuelven 0.

Las instancias van bien, pero place_meeting, ni siquiera el que se ejecuta originalmente DENTRO del with, funciona. Esto ya no lo entiendo.. algo va mal con el propio "with"?

En la llamada he probado estas 4 combinaciones

scPlaceMeetingWith(obCly, x, y, obPilarCristales)
scPlaceMeetingWith(obCly.id, x, y, obPilarCristales)
scPlaceMeetingWith(obCly.id, x, y, obPilarCristales.id)
scPlaceMeetingWith(obCly.id, x, y, obPilarCristales.id)

Sigue sin funcionar (aún no tengo claro cuándo va bien .id y cuándo el nombre del objeto, incluso en casos en que sólo haya UNA instancia de él, pero no parece ser el problema)

EDIT: Me acabo de dar cuenta que a la llamada de paso las x e y incorrectas. Debo pasarle obCly.x, obCly.y. Ya funciona!

Muchas gracias por la ayuda, qué fallo más tonto xDD Al final no colisionaban... porque chequeaba donde no tenía que hacerlo

- Puedo asegurar que argument0 colisiona con argument3. Tengo ese mismo código en otra parte pero de forma manual, y veo cómo sí colisionan. Pero el script no.
-Ambas tienen máscara, o sprite en su lugar. A demás, por el punto 1, sí colisionan si el código es HECHO desde una de ellas y manualmente.
-Ambas existen

Tan bien se ve el script? Significa que está bien y el error está en otro lado que yo no puedo percibir?... :C

PD: sólo hay UN obCtrl

En create:

vrPlaceMeetingWith = false;

Y esa variable no la toca ningún otro objeto ni script, ni la toca el propio obCtrl. Es sólo un contenedor auxiliar para poder guardar el resultado del "with" y recogerlo en el script. ObCtrl tiene muchas cosas, crear la cámara 3D, ajustar display, inicializar variables clave...

Y realmente no importaría ni el valor inicial, ni si otro objeto lo modifica. SIEMPRE que voy a leer esa variable dentro del script es porque acabo de asignarle un nuevo valor al hacer place_meeting, así que no importa qué suceda fuera del script con la variable. Y obCtrl es persistente. Realmente sólo tengo una room por ahora, y puedo asegurar que el objeto nunca se desactiva ni se destruye

He creado este script

with(argument0) {
    obCtrl.vrPlaceMeetingWith = place_meeting(argument1, argument2, argument3);
}
return obCtrl.vrPlaceMeetingWith;

La idea es poder hacer un place_meeting usado la colisión de OTRO objeto, pero no desde ese objeto. La idea es hacer el width y guardar el resultado en otro objeto, obCtrl, que es persistente y siempre está ahí, para recuperar el resultado. Por qué no funciona?

ObCtrl ya tiene en create la inicialización de la variable. No da ningún error, simplemente... no funciona. O sea, que no devuelve lo que tiene que devolver
NO quiero usar variables globales, las odio a más no poder, no hice pruebas extensas pero creo que daban errores por todos lados. Usar una variable local de un objeto persistente debería servir, no?

Cita de: penumbra en Agosto 11, 2015, 02:48:03 AM

Cita de: DarkKRuleR en Agosto 11, 2015, 02:27:40 AM
Espera... me estás diciendo que mouse_x, en 3D, devuelve la posición del ratón EN LA PANTALLA y no en la room? De forma automática?...

NO. Yo no lo digo. Lo dice el manual  :D

CitarYou can, however, still get the position of the mouse on the screen (in the view)

Pensé que se refería a usar las funciones window_get_mouse_x o screen_get_mouse_x, como fuera... gracias! Esto lo simplifica todo. Tendré que testear un poco, claro, pero resuelto

Cita de: penumbra en Agosto 09, 2015, 09:41:18 PM
Pero el manual no dice que esas funciones se vuelvan inservibles ni que dejen de funcionar al entrar en modo 3D. Lo que dice el manual es que esas coordenadas seguirán devolviendo la posición del mouse en pantalla (no en un espacio 3D).

La relación entre las coordenadas del personaje y la posición del ratón te funciona porque en ninguno de esos cálculos se involucra la coordenada z (estás "viendo" la escena desde el mismo plano siempre) y no necesitas hacer cálculos adicionales para obtener una posición en un espacio tridimensional.

Espera... me estás diciendo que mouse_x, en 3D, devuelve la posición del ratón EN LA PANTALLA y no en la room? De forma automática?...

en ese caso es más que perfecto, sobretodo porque mi único plan era apuntar con el ratón. O sea, obtener el point_direction(personaje.x, personaje.y, mouse_x, mouse_y), y eso funcionaría incluso si mouse_x está loco. Pero si realmente da las coordenadas en la pantalla, entonces puedo usarlo para mucho más...

Uh, sin duda es llamativo, pero hay veces en que las cosas funcionan por un error, o están colgando de un hilo, y luego se va todo a la mierda por no hacerlo con conocimiento real, por eso prefiero preguntar xD Pero sin duda me está facilitando MUCHO las cosas que esto siga funcionando, tengo ganas de seguir para adelante

Buenas! Pues hasta ahora siempre pensé que al activar el modo 3D el ratón se vuelve inservible, mouse_x y mouse_y dejan de funcionar y tienes que coger las coordenadas del ratón en la pantalla en su lugar y trabajar con ellas (como dice el manual) pero...

mi proyecto es top-down. La cámara está en el eje z positivo, y mira hacia abajo. Es decir, veo la room IGUAL que se vería como si fuera 2D. +X a la derecha, +Y abajo (modificar coordenadas), y miro hacia -Z. La idea es que, aún siendo 3D, veo la room igual que se vería en 2D. Y estoy trabajando como lo hacía cuando era 2D, usando mouse_x... y me sigue funcionando. Hago un draw_text, y mouse_x sigue funcionando. Lo principal, que es la relación entre las coordenadas del personaje y mouse_x, para saber si el ratón está a su derecha o izquierda, y el ángulo entre el personaje y el ratón... todo sigue funcionando. Es normal? (Teniendo en cuenta que la perspectiva de la cámara 3D está simulando la vista tal cual 2D, es decir, no hago primera persona, sino que miro perpendicularmente al plano XY), o es alguna casualidad y podría fallar o ser inestable? Puedo continuar usando mouse_x?

@ordo_ab_chao, es interesante la idea de hacer reuniones semanales, sin duda... y en el caso de que fueran todos cara a cara lo mismo. Hmmm

@kakashigna, cómo olvidarme, los dos comenzamos más o menos al mismo tiempo (ahora miro y me fijo que unos meses de diferencia). Ains, yo tampoco estoy muy activo, más que nada para consultar dudas. Ahora mismo he comenzado un proyecto individualmente, aunque ahora salió la idea que me ayude un compañero del grupo en cuanto a ideas (él siempre ha estado activo), pero sí, tengo demasiados proyectos inacabados xD Recuerdas Parallel Dimension: White, y el más reciente Oscuridad en Saetherna? Mi idea es coger el sistema del primero (pantallas de exploración y puzzle, criatura encerrada en una dimensión) y la apariencia, jugabilidad y poderes del segundo (en ambos juegos podías colgarte de casi cualquier pared y techo y avanzar), así que en parte estoy recuperando su legado, aunque por desgracia no tratará sobre las somb...

...

me diste la idea, puedo hacer que en este juego también aparezcan las sombras como seres vivos. Gracias por darme una idea tan valiosa sin darte cuenta xDD Por si no te acuerdas, dos de mis mejores proyectos (Shadow's Bone Armor y Oscuridad en Saetherna) los seres vivos son seres hechos de sombras. Y la dificultad siempre seguirá siendo extremadamente hardcore, pero ahora añado modo normal más accesible para elegir :D

Ya, es cierto que a veces tras acabar responsabilidades uno solo tiene ganas de sentarse a ver la tele o jugar, pero mira tu caso, tú amas hacer juegos aún tras todo eso, pues igual debe haber gente que ame dibujar, spritear o escribir tras todo eso, y esa es la que buscaba >_>

@Marron121, joder cómo de identificado me siento T_T al parecer la teoría de que "joder, si hay cientos, miles de personas que dibujan, escriben, hacen música y programan por su propia cuenta en solitario, debería ser la hostia reunirse y todos deberían tener ganas y motivación para avanzar algo en grupo", pero parece que no siempre se cumple...

Buenash! Pues quiero simular un draw_sprite_ext para el 3D, siendo la cámara mirando desde arriba, del eje z positivo hacia el negativo, y hacer una primitiva cuadrada con el sprite. Pero quiero que simule lo anterior. O sea, que tenga en cuenta image_xscale e image_yscale, y el ORIGEN del sprite. Que si pongo la cruceta en un lado, al cambiar el image_xscale e yscale, mueva los vértices. He hecho esto:

// sc3DDrawSprite(txText, vrX, vrY, vrZ, vrWidth, vrHeight, vrXScale, vrYScale, vrAngle, vrXO, vrYO);
var txText, vrX, vrY, vrZ, vrWidth, vrheight, vrXScale, vrYScale, vrAngle;
txText = argument0;
vrX = argument1;
vrY = argument2;
vrZ = argument3;
vrWidth = argument4; // tamaño real del sprite en el juego
vrHeight = argument5;
vrXScale = argument6;
vrYScale = argument7;
vrAngle = argument8;
vrXO = argument9; // Respecto a width y height, NO al tamaño del sprite - potencia de 2
vrYO = argument10;

d3d_transform_set_identity();
d3d_transform_add_rotation_z(vrAngle);
d3d_transform_add_translation(vrX, vrY, vrZ);

d3d_primitive_begin_texture(pr_trianglestrip, txText);
    if (image_xscale == 1)  d3d_vertex_texture(-vrXO*vrXScale,             +(vrHeight-vrYO)*vrYScale,     0, 0, 1); // UL
                            d3d_vertex_texture(-vrXO*vrXScale,             -vrYO*vrYScale,                0, 0, 0); // DL
    if (image_xscale == -1) d3d_vertex_texture(-vrXO*vrXScale,             +(vrHeight-vrYO)*vrYScale,     0, 0, 1); // UL
                            d3d_vertex_texture(+(vrWidth-vrXO)*vrXScale,   +(vrHeight-vrYO)*vrYScale,     0, 1, 1); // UR
                            d3d_vertex_texture(+(vrWidth-vrXO)*vrXScale,   -vrYO*vrYScale,                0, 1, 0); // DR
d3d_primitive_end();

d3d_transform_set_identity();

Como os podéis fijar... en cierto modo he intentado que tenga en cuenta el origen del sprite, pero me ha salido mal. Es decir, los vértices no se mueven del sitio. He logrado que la ROTACIÓN respecto al eje z tenga en cuenta este origen, pero no el xscale y el yscale.

Ejemplo: si tengo un sprite 100x100, y el origen está en 10, 50, al hacer image_xscale = -1, los dos vértices de la izquierda se moverán 20 píxeles a la derecha, y los dos de la derecha 180 hacia la izquierda (90x2), se hará el MIRROR respecto a eso. Es lo que no he logrado. También debe aceptar decimales, ejemplo image_xscale = 0.6.

El problema del que he puesto es que, si reduzco la xscale de 1 a 0 GRADUALMENTE, se ve cómo se encoge hacia el centro del sprite, y no hacia el centro de coordenadas (cruceta) elegida, y eso lo estropea todo

Alguien sabría cómo? T_T me tiene frito

EDITO: podéis cerrar o borrar, ya lo he resuelto. He pegado la versión "final". Con el culling(true) sí funciona para image_xscale = -1, pero se corta, ya lo resolveré

Claro, pero tampoco es plan de estar todo el rato tras de ellos, pinchando con "EH, YA HAS HECHO TU PARTE? COMO VA? HOLAAA", deberían salir las ganas de ellos mismos, estar motivados como lo estás tú o yo, y anticiparse, avanzar las cosas por su cuenta... y esto no cambia ya sea a distancia o cuerpo a cuerpo, sólo entran las ganas de la persona. Si esto no se ve en las personas... el proyecto no va a ninguna parte. La gente debería participar activamente y tener ganas. Joder, si había gente del grupo que no se ha mirado ni una vez el documento (con TODA la historia pensada, mecánicas de juego..) si yo entrara a un grupo lo primero que haría es mirarmelo ENTERITO y proponer todo lo que pueda. No entiendo xD

Una vez llegué a pensar que el problema era "yo", que "impuse" (y en parte es cierto) mis ideas para el juego casi sin pensar en qué quería la gente... luego pasé una temporada en que estuve a full escuchando a todos (a los POCOS que respondieron en ese entonces) qué querían, cuál era su idea para el juego. Todos deberían tener su pedacito y hacer algo que aman. Hasta para diseñar al protagonista esperé que todos dieran opiniones, pero nadie dijo nada... en general pareció que a todos les gustaba la idea pero viendo el panorama, no hago más que preguntármelo todo, qué hay mal, qué hago mal, qué se puede hacer.

@tu padre
estoy de acuerdo, debe ser interesante y accesible, la clave es que entre más gente, cada una especializada a un rol, se logra
En tus errores ya no estoy de acuerdo. A parte de que yo soy el único programador, siempre he mostrado yo un 100% de interés, actividad y ganas, y no he visto correspondencia, así que nada de "por poco que te alejes los demas tambien lo harán", lo hicieron tras mostrar yo máximas ganas. Organización creo que también lo intenté...

@Marth, totalmente cierto, pocos aliados pero muy buenos. Me gustó leerte :D Lo de los contratiempos es cierto y normal que suceda de vez en cuando, pero como digo, cuando la cosa va a meses de desaparición, o medio año en el primer caso que os digo, pues a uno le toca un poco la moral y se desanima. Y aún con eso seguí intentando estar animado, proponer y fomentar actividad, pero ná xD

@penumbra, parece muy cierto eso de la distancia... por experiencia. Pero no lo pillo del todo.. cuando las personas quieren, no debería importar la distancia, y más si es desarrollar un juego donde todos pueden hacer las cosas paralelamente. Será lo dicho, gente no adecuada... claro,  ya sea a distancia o en vivo, si no hay ganas nada servirá, por lógica ambas formas deberían llevar al éxito si los integrantes quieren, y seguramente falle por esto último. Tendré que seguir pensando en ello... y quizás... la solución sí sea hacerlo en vivo. En el grupo precisamente sería posible, aunque no con todos. Pero ya demasiados nos han fallado. También quiero seguir pensando que la distancia no debería importar...