Comunidad Game Maker

Buenash! Pues esto me está rompiendo la cabeza... a ver, funcionar funciona genial, pero trae muchos pequeños detalles que me encantaría solucionar.



Esa es la imagen. Fijáos en que tiene partes con alpha entre 0 y 1, intermedios. Hay una al fondo y una al frente.

Si primero dibujo la del fondo y luego la del frente todo va bien, pero si dibujo al revés... la del frente "se come" parte de la del fondo, y la del fondo aparece con una parte desaparecida al solaparlas. Ya intento dibujar en el orden correcto, pero sumado a que hay por todas partes y que tanto sus posiciones como la cámara pueden estar en cualquier parte, es complicadísimo, y siempre hay varios errores de éstos mientras que la otra mitad es correcto. ¿Alguna opción que pueda tocar por ahí para arreglarlo, viendo (CREO) que NO ES VIABLE dibujarlos TODOS en el orden correcto?



Di importancia al alpha, porque si el sprite sólo tiene alphas de 1 (opaco) y 0 (transparente) sin píxeles intermedios, entonces el error es mitigado, y en su lugar simplemente aparece un borde blanco alrededor del frontal (al dibujarlo antes que el del fondo). Molesta, pero menos. Y es necesario hacer alphas intermedias así que...

habrá, por todo el escenario 3D, MUCHOS de ellos, en posiciones cambiantes y la cámara se mueve constantemente, es imposible poder alterar el código para dibujar en orden de los más profundos a los más cercanos...

En el estudio de Guineu groga necesitamos gente seria, actualmente se está reestructurando el estudio para volver a lo que era antes, un estudio independiente de manga y videojuegos serio en el que publicaban constantemente las novedades.

Los proyectos de Guineu groga son 4:
- Videojuego: Alma apocalíptica
- Alma apocalíptica (manga)
- Requiem for a fox (manga)
- Web y dominio propio para Guineu groga (Del cual el diseño y creación correrá a cargo del fundador y de mantener el dominio propio también).

¿Qué necesitamos?
- Spriters para hacer la parte gráfica del juego digitalmente y a color. Estos son los más necesarios.
- 1 Programador web (El que ayudará al fundador con la web).
- 1 Programador para el videojuego que sepa Game Maker (el primer proyecto será con Game maker, el segundo, a futuro, ya se decidirá), yo estoy haciendo la base y ellos ayudarían en cosas como diseñar Inteligencias Artificiales enemigas, hacer el sistema de tal menú, programar tal puzzle, las mecánicas de combate o de aventura... cualquier cosa
- Ilustradores que harían bocetos para el manga y el juego, ilustraciones para el juego (splash arts o imágenes en grande de los personajes, objetos y enemigos, fondos y escenarios, etc para servir de guía a los spriters), pero NO dibujar el propio manga, debido a que los dos mangas ya tienen alguien haciéndolos. Ilustración tradicional (sobre papel) o digital.

¿Pagamos? Por ahora no, esto es un hobby común (por ahora), si llega lo lejos que estamos pensando que llegará sí será posible que ganéis dinero por ello.

CitarIntroducción del manga y juego Alma apocalíptica, para que veáis de qué va el proyecto.

Haremos el juego paralelo al manga, basado en el mismo universo, historia y personajes, aunque obviamente el juego tendrá mucho más contenido y extras. Tenemos escritores trabajando en personajes e historia, que se usará tanto para el manga como para el juego, pero hay dos cosas básicas que nos faltan para el juego: spriters y programadores. Spriters sobretodo.

El inicio está localizado en nuestro mundo normal, nuestra dimensión. Y una dimensión alterna que siempre ha existido paralelamente. A lo largo de la historia ha habido grietas que ha permitido a criaturas extrañas cruzar a nuestro mundo desde ese mundo de fantasía extraño. Fue cuando la humanidad vio a los primeros unicornios, trolls e incluso criaturas aladas como ángeles o demonios, que más tarde derivarían en leyendas, mitos y religiones.

Existe un árbol enorme en ambos mundos, el árbol Hyperión, exactamente igual en ambos. La historia comienza cuando, por alguna razón que desconocemos, ambas dimensiones chocan bruscamente, fusionándose en un sólo mundo, y sólo quedando un árbol. Más de la mitad de los humanos y animales desaparecen aniquilados, y todos los humanos del planeta despiertan ese día con una extraña mutación que parece haberlos fusionado con animales... y aparecen criaturas mitad humano, mitad animal, que existían originalmente en la otra dimensión. Un mundo post apocalíptico y en caos despierta, y nadie sabe qué ocurrirá. La humanidad ha despertado con partes del cuerpo y con capacidades de animales, en un mundo extraño y destrozado, con otros como ellos y con muchas criaturas mitológicas, extrañas y hostiles por todas partes.

CitarImágenes del estudio (personajes de varios proyectos, del estudio o personajes aleatorios que no pertenecen a nada). También tengo el prototipo de la base para el juego, que será 2D en cuanto a sprites y fondos, pero con el sistema para animaciones 3D, y hecho a base de sprites, pues queremos un primer proyecto más simple. Los que se apunten lo recibirán para testear
[spoiler]








[/spoiler]

Mirad esta imagen:



El juego tiene entorno 3D, e inicia en pantalla completa. Pero no sé CUÁNDO esto puede ser falso.

1- Qué puede ocurrir para que la pantalla completa desaparezca? Es decir, debería tener código que constantemente chequee la pantalla (completa o no) para volver a completa si se sale? Puede ocurrir de forma natural? Como al volver al escritorio, cuando aparezca un mensaje del antivirus... no sé. Por ejemplo al hacer un show_message o string_get, la pantalla completa se pierde.

2- Al perderla (en mi caso con string_get, o get_string), la volví a poner completa y apareció el error que véis en la segunda imagen. El personaje 3D está formado por muchos sprites, uno "encima de otro". Todos los píxeles tienen alpha 0 o 1, no intermedios (daba errores), y vemos cómo funciona mal en el segundo caso, tras RE-activar la pantalla completa. Esto a qué se debe? Pasaría siempre? Algún arreglo? Las partes se dibujan en este orden: Cuerpo, Cabeza, Brazos, Piernas. Debería ir bien como en el primer caso. PD: Me he fijado que en el segundo caso dejan de verse los píxeles y se difumina todo, recuerdo este efecto... parece que se hizo de forma manual. y todo se ve mejor, pero sucede eso. Es raro, porque de inicio tengo marcado el "Interpolate pixels"

El tema pantalla completa me tiene mareado xD

Buenash! Pues veréis, tengo esto:

var file;
file = file_text_open_write(working_directory + "\datosParaDarkK.txt");
file_text_write_string(file, "AaaAAaaAaa");
file_text_close(file);

No sé dónde lo guarda, pero quiero que, dando el juego a cualquier usuario, éste sea fácilmente capaz de localizar dónde se ha guardado y poder acceder al fichero. Por ejemplo en el escritorio... cómo lo hago?

Buenas! Pues tengo una función que requiere 26 argumentos y, cómo Game Maker sólo permite 16, pensé en mandarle un array en su lugar, pero TENGO que poder crear el array en una sola línea, en la misma línea de la llamada.

scPerAsignaPose( [ 0, x, 90, 0, 90, 0, x, 270, 0, 270, 0, x, 270, 0, 270, 0, x, 270, 0, 270, 0, x, 270, 0, 270, 0 ] );

Yo llamo a la función, y tengo que PODER pasarle el array así (de lo contrario simplemente puedo llamar a dos funciones, que juntas suman 32 argumentos). Cuál es la forma correcta? Suponiendo que la haya...

En el estudio de Guineu groga necesitamos gente seria, actualmente se está reestructurando el estudio para volver a lo que era antes, un estudio independiente de manga y videojuegos serio en el que publicaban constantemente las novedades.

Los proyectos de Guineu groga son 4:
- Videojuego: Alma apocalíptica
- Alma apocalíptica (manga)
- Requiem for a fox (manga)
- Web y dominio propio para Guineu groga (Del cual el diseño y creación correrá a cargo del fundador y de mantener el dominio propio también).

¿Qué necesitamos?
- Spriters para hacer la parte gráfica del juego digitalmente y a color. Estos son los más necesarios.
- 1 Programador web (El que ayudará al fundador con la web).
- 1 Programador para el videojuego que sepa Game Maker (el primer proyecto será con Game maker, el segundo, a futuro, ya se decidirá), yo estoy haciendo la base y ellos ayudarían en cosas como diseñar Inteligencias Artificiales enemigas, hacer el sistema de tal menú, programar tal puzzle, las mecánicas de combate o de aventura... cualquier cosa
- Ilustradores que harían bocetos para el manga y el juego, ilustraciones para el juego (splash arts o imágenes en grande de los personajes, objetos y enemigos, fondos y escenarios, etc para servir de guía a los spriters), pero NO dibujar el propio manga, debido a que los dos mangas ya tienen alguien haciéndolos. Ilustración tradicional (sobre papel) o digital.

¿Pagamos? Por ahora no, esto es un hobby común (por ahora), si llega lo lejos que estamos pensando que llegará sí será posible que ganéis dinero por ello.

CitarIntroducción del manga y juego Alma apocalíptica, para que veáis de qué va el proyecto.

Haremos el juego paralelo al manga, basado en el mismo universo, historia y personajes, aunque obviamente el juego tendrá mucho más contenido y extras. Tenemos escritores trabajando en personajes e historia, que se usará tanto para el manga como para el juego, pero hay dos cosas básicas que nos faltan para el juego: spriters y programadores. Spriters sobretodo.

El inicio está localizado en nuestro mundo normal, nuestra dimensión. Y una dimensión alterna que siempre ha existido paralelamente. A lo largo de la historia ha habido grietas que ha permitido a criaturas extrañas cruzar a nuestro mundo desde ese mundo de fantasía extraño. Fue cuando la humanidad vio a los primeros unicornios, trolls e incluso criaturas aladas como ángeles o demonios, que más tarde derivarían en leyendas, mitos y religiones.

Existe un árbol enorme en ambos mundos, el árbol Hyperión, exactamente igual en ambos. La historia comienza cuando, por alguna razón que desconocemos, ambas dimensiones chocan bruscamente, fusionándose en un sólo mundo, y sólo quedando un árbol. Más de la mitad de los humanos y animales desaparecen aniquilados, y todos los humanos del planeta despiertan ese día con una extraña mutación que parece haberlos fusionado con animales... y aparecen criaturas mitad humano, mitad animal, que existían originalmente en la otra dimensión. Un mundo post apocalíptico y en caos despierta, y nadie sabe qué ocurrirá. La humanidad ha despertado con partes del cuerpo y con capacidades de animales, en un mundo extraño y destrozado, con otros como ellos y con muchas criaturas mitológicas, extrañas y hostiles por todas partes.

CitarImágenes del estudio (personajes de varios proyectos, del estudio o personajes aleatorios que no pertenecen a nada). También tengo el prototipo de la base para el juego, que será 2D en cuanto a sprites y fondos, pero con el sistema para animaciones 3D, y hecho a base de sprites, pues queremos un primer proyecto más simple. Los que se apunten lo recibirán para testear
[spoiler]








[/spoiler]

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

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?

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?

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é

Buenas. Hasta ahora... más de 10 años haciendo juegos con game maker. Acabé uno, el Four Elements: Draco's Mission, un tanto cutre respecto a lo que sé hacer ahora, pero es todo lo que hice. A lo largo del tiempo he hecho decenas de juegos, todos abandonados al 3% de comenzarlos, ya sea por pereza, por tener otras ideas y... sobretodo, porque todos los hice yo solo. Hace bastante tiempo me uní a un grupo. El jefe es un amigo de la infancia que creó un grupo de gente para hacer mangas y juegos. Entre ellos tiene un primo y varios amigos, y me metió. Soy el único programador, y al aportar una idea comenzamos a desarrollar un juego. El 100% de todo lo hemos hablado y avanzado por skype.

Al princio todo guay, surge la idea, creamos un documento en google drive, todos aportan algo.. a los días la gente fue abandonando. Tal cual, pasó medio año, MEDIO, en el que los progresos eran... ¿nulos? Yo siempre estaba 100% activo, tenía (TENGO) unas inmensas ganas de CREAR, y un tanto de tiempo (hasta que no comience la universidad, pero aún con la uni SIEMPRE he tenido algo de tiempo para avanzar... aunque fuera cada día o cada dos días un poquito). Pero la cosa estuvo parada 6 meses... nadie hacía nada. Entre excusas de la universidad y noséquecosas. Hace unos meses hablé con un miembro, dijo que hay que ponerse serios, ir a por algo más sencillo de primeras... el tema es que cogimos a los más activos, ahora somos unos 6. Yo programo, escribo la historia y guión junto con otro, un spriter, y 3 ilustradores.

Obviamente, cuando digo que pasó medio año así, me refiero a que muy de vez en cuando iba escribiendo cosas en el grupo de skype con TODOS, ya fueran palabras, o incluso poner las cosas que yo iba avanzando.. enseñar lo que había programado, cosas guays. Con suerte alguien lo comentaba, y eso pasado 1 o 2 días la mayoría de veces. Ausentismo extremo. Una vez les hablé a todos por privado,todos estuvieron de acuerdo en continuar y me dijeron que estaban listos. Se inició,y de nuevo, todos ausentes.

Y volvió a pasar. Ahora mismo tengo al spriter comenzando los sprites de la prota, y a un ilustrador haciendo un fondo. Hace 1 semana y... no hay prácticamente NADA. En cambio yo tengo desde hace un mes un prototipo en game maker (usando sprites y fondos de internet) con la mecanica de una "linterna" direccional implementada usando surfaces (oscuridad, apuntas en cono para la luz) entre otras cosas. Yo estoy para currar al 100% pero.. no sé qué le pasa a la gente. Y me llevo bien, al principio.. e incluso ahora todo va bien, dejando de lado el estar ausentes

Avanzo que trabajamos por "amor al arte". Mi idea es que somos gente que nos gusta lo que hacemos (programar, dibujar, escribir), que nos gustan los juegos y que QUEREMOS hacer un juegazo, pero luego nadie nunca tiene tiempo. En el primero (y del segundo se dijo algo) teniamos pensado subirlo a steam y ponerlo a un precio bajo, para amortizar un poco.

Estoy en otro grupo, solo somos 3, todo por facebook, fue hace un mes, se escribió y habló bastante, y a la semana... de nuevo NADA. Uno nos dice que tiene varios problemas, varios familiares están mal y uno lejano muerto, el otro estuvo con clases... éste dice que ahora está libre, pero esperamos al tercero para continuar. No digo que sea mentira ni mucho menos pero... en serio TODO EL MUNDO está tan ocupado? Aclaro que en el PRIMER GRUPO han entrado y salido más de 10 personas, constantemente el jefe ha ido metiendo amigos y conocidos hasta echarlos por no hacer nada. Tan difícil es? Nadie hace nada? Soy el único con unas ganas increíbles de crear un juegazo en grupo, pero que ha tenido nefasta suerte encontrando un solo spriter, guionista o ilustrador de fondos?

Cuál es vuestra experiencia con el tema? Por qué me ha ocurrido todo esto? Aquí sigo, con unas inmensas ganas de crear, pero sin nadie. Tengo experiencia en GML en game maker, podría crear prácticamente cualquier cosa (ciñiéndonos al 2D y single player), tengo tiempo y ganas, pero en todos los grupos que he entrado pasa ALGO para torcerlo. En serio la gente, cuando tiene exámenes, ocupa el 100% de su tiempo en ello? Obviamente no. Si realmente QUISIERAN hacer un juego, tuvieran la PASIÓn y GANAS de hacerlo, siempre sacarían un poco de tiempo para ir avanzando casi diariamente, como máximo un retraso de 3-4 días cuando surja.

Siento el tocho, en parte quería desahogarme, pero ver las experiencias de la gente ayudaría, quizás estoy pensando algo mal o soy un soñador estúpido, pero si a mí me viniera un spriter a decirme "tengo pasion y ganas por crear un juegazo, y seré activo porque me apasiona, hacemos algo?" yo diría "WOHOO", ese es mi caso pero en programador. Aunque hasta ahora he tenido que dedicar la mayoría de mi tiempo a ser guionista, diseñar las mecánicas, etc... y en el peor caso spritear, pero intento librarme (pues bastante tengo con ser guionista y el único programador, esto ultimo no me desagrada, incluso me encanta, siempre que tenga gente que haga los gráficos, músicas, fondos y escriba por mí...)

Estoy realmente con la cabeza ardiendo y aún no logro sacar esto...

Tengo dos sistemas de referencia. El primero es el real. 0 derecha, 90 arriba, 180 izquierda, 270 abajo. El jugador puede mirar hacia dónde quiera, y lo defino como vrDir. Es, en este sistema, hacia dónde mira el jugador.

El segundo sistema es respecto a la vista del jugador. En la pantalla, el jugador siempre, SIEMPRE mira hacia arriba (90). Si vrDir = 90, o sea, si yo miro hacia arriba, en la pantalla miraré hacia arriba y todo encaja. Pero si por ejemplo vrDir = 0, yo miro a la derecha, en la pantalla siempre miraría arriba. Eso significa que lo que yo tuviera enfrente, o sea, tuviera a la derecha del sistema original, aparecería arriba del todo en el sistema de la pantalla. En la pantalla, el sistema siempre está mirando hacia arriba. Así que cuando el personaje  rota, el mundo rota al revés en la misma medida.

Mi objetivo es, dada una dirección del ratón en la pantalla, en el sistema del jugador, pasarlo al sistema original y, dado en el original, pasarlo a la pantalla. Realmente no lo logro...

Ejemplo: si yo miro a la izquierda (180), en la pantalla miraré SIEMPRE a 90. O sea, arriba veré lo que haya a la izquierda en realidad (180). Desde esa perspectiva, si yo eligiera la dirección 90, es decir, a mi frente (desde la pantalla), eso debería traducirse a 180 (hacia dónde miro). Si elijo 60 se traduciría en 150. Espero que entendáis la idea de los dos sistemas, el real que todos conocemos, y el del personaje, donde siempre el 90 está hacia arriba. Necesito pasar ángulos de uno a otro...

Sé que en ambas fórmulas deben intervenir vrDir, la dirección que quiero transformar, y creo que también el número 90, debe ser un conjunto de sumas y restas entre ellos, pero no lo saco. He llegado a sacar varias fórmulas medio exitosas, pero siempre fallaba algo

EDIT: no me creo cómo he tardado tanto
De pantalla a mundo: vrDir + (vrAng - 90)
De mundo a pantalla: vrAng - (vrDir - 90)

Podéis cerrar, o borrar, o lo que sea xD

Buenas! Estoy en GM Studio, y no tengo claro el tema eficiencia. Tenía pensado usar sprites 120x120, pero ahora surge la necesidad de subir a 150x150. Habrá MUCHOS personajes y enemigos, y cada uno tendrá muchas animaciones con, seguramente, muchos frames, sobretodo el prota, y dudo que pueda ir muy lento con la subida a 150x150. Recuerdo que en GM8 podías... guardar los sprites en una carpeta a parte, cargarlos por código y borrarlos cuando no fueran necesarios, pero ahora, con el tema de que GM studio crea un exe para instalar.. no sé si es automático, se puede hacer o no... así que

1- El tema este de peso-ralentización por tener demasiados sprites, sigue en GM studio? Cómo? Debo preocuparme por el peso de mis recursos, o ahora que hay un instalador es automático y te lo guarda fuera en carpetas?

2- Debo preocuparme por subir de 120x120 a 150x150 (pensando que habra MUUUUUUCHOS sprites) o es sufrir innecesariamente, pues sigue siendo un tamaño pequeño?

Buenash! Imagen. Izquierda el resultado, derecha el sprite real


(Fondo de Resident Evil 3, personaje de Ragnarok Online)

Podéis ver cómo, al hacer PANTALLA COMPLETA y hacer algo de zoom a la imagen, se destroza totalmente. He pensado este código para simular el "mantener escala en fullscreen" que tenía el GM8 y NO tiene el GMS:

/// Ajustes clave
view_wview[0] = display_get_width();
view_hview[0] = display_get_height();

view_wport[0] = display_get_width();
view_hport[0] = display_get_height();

view_xview[0] = obEli.x - display_get_width()/2;
view_yview[0] = obEli.y - display_get_height()/2;

Pero no sé por qué no funciona. La idea es coger un tamaño de view igual al monitor del jugador, ajustar el viewport igual, y poner al personaje en el centro. Con eso el jugador SIEMPRE, independientemente de la resolución de su monitor, al poner pantalla completa, debería verlo con calidad 100%, SIN ningún zoom, pero obviamente cogiendo y viendo a la vez mucho más room respecto a un jugador con una pantalla pequeña. Y si no me equivoco, si la room es menor al monitor o el jugador está en el borde, vería todo negro (fuera de room), cosa que no pasaba en GM8. Por qué no funciona? En su lugar lo veo como reducido, alejado... y cuadrado, cuando el background es 1024x768!

Buenash, pues estoy últimamente trastocando con cube maps





Eso lo pones en un cubo 3D y, mirando desde el interior, parece como si fuera un entorno 3D real. El problema es que vienen pre-hechos. Si uno quisiera hacer su propio cube map, de la misma forma que haces tus propios gráficos... ¿Alguien tiene experiencia/herramientas/idea de cómo sería? Si os fijáis no es fácil, a parte de tener que representar todo el entorno visto desde un punto sobre 6 paredes, las paredes no son planas, las imágenes tienen efectos extraños de zoom en los bordes para dar el efecto correcto, a parte el conectarlo todo... alguien ha logrado hacer manualmente alguno? No me refiero a foto, me refiero a coger lápiz y papel por ejemplo y hacerlo, ya sea directamente o indirecta mediante una herramienta. Digamos que si quisiera hacer un juego cuyos escenarios fueran cube maps y, obviamente, tuviera que hacerlos un experto gráfico desde cero... es viable en la práctica, es posible?

PD: También estoy leyendo sobre spheremaps, y quizás podría servir igual pero no me aclaro

Os paso un ejemplo en 3D de cube mapping, donde creo un cubo 3D (por ahora sin techo ni suelo) y podéis, con el ratón, mirar en todas direcciones.

La room es 500x500. Zoom inicia en 2.
Fijáos en el multiplicador. A la hora de definir la proyección multiplico por "zoom" las coordenadas del personaje, que inicialmente son 250, 250.
Dibujo los muros en x=0, 500, y=0, 500. El personaje, por lo tanto, queda en el centro. Si véis la room todo esto es perfecto.

Entonces, iniciando con zoom = 2, el personaje pasa a 500,500, pero los muros se dibujan en 0, 0, 1000, 1000. Podéis aumentar mucho más zoom. Si os fijáis el personaje siempre queda en el centro de la sala, pero cada vez hay más distancia entre él y las paredes. O sea, debería ver las paredes cada vez más lejos.

PERO NO!

Las paredes nunca cambian, es absurdo! A ver quién encuentra qué falla, porque estoy volviéndome loco!! Por lógica, al aumentar el zoom, el personaje siempre debería quedar en el centro de la sala, pero ésta hacerse cada vez más grande. Quiero verla grande, si os fijáis al ejecutar hace demasiado zoom en ellas, pero no funciona!

PD: No sé si sería más bonito visualmente hacer esto en 3D o en 2D, pero en 2D tenía problemas a la hora de alzar la vista, no sabía cómo, así es más fácil, aunque temo que las cosas se deformen

Edit: he logrado alejarlo usando d3d_set_projection_ext en su lugar, y aumentando el ángulo "field of view", se ve más lejos pero el zoom deja de funcionar, no le veo sentido a que aleje los muros (porque se alejan, no veo razón para que eso falle) y no se dibujen más lejos, así que no podría considerarlo resuelto, quiero saber exactamente qué falla

Buenas! Pues llevo tiempo haciendo un juego con un grupo de amigos, programándolo en GM: Studio, la versión gratuita  que me bajé cuando la pusieron gratis (creo que fue standard, pero ahora la sigo viendo gratis), de siempre he pensado (leí por ahí) que podías comercializar perfectamente los juegos, pero ahora dudo, porque no encuentro nada al respecto... nuestra intención es subirlo a steam. Exactamente cómo va el tema, si se puede hacer gratuitamente, el papel de yoyogames (o quien tenga ahora el gm studio)... info, info D: muchas gracias

Buenash! Pues tengo que hacer, para un boss serpiente, varias colas, pero no tengo mucha idea de cómo hacer una cola de serpiente para que parezca casi real.. es decir, no simplemente X sprites conectados que se ve a simple vista (haciendo una escalera), sino que se vea fluido, como si no estuvieran conectados... que pueda mover la cola y cada una de sus "uniones" en cualquier dirección, pero que gráficamente se vea algo constante entre ellas. En 2D con sprites.

Ideas? Algo similar que ya se haya hecho para ver qué tal es e inspirarme? Ideas para código?

Buenas! Saqué código del siguiente vídeo:
https://www.youtube.com/watch?v=dYbCfhX3Hu4

el problema es que TODA LA PANTALLA se pone oscura, y las luces lo iluminan. Quiero hacer que el fondo no se vea afectado, es decir, que el fondo siempre tenga iluminación máxima, y que la luz (todo oscuro y se ilumine con la linterna) sólo afecte a las tiles y objetos, pero NO al background. Tengo un objeto con depth 10000 que hace draw_background, pues quiero que ese draw no se vea afectado por la luz, que se vea al 100% claro.

Os pego el código del vídeo, está en el objecto controlador, -1000 depth


CREATE
light = surface_create(view_wview, view_hview);

STEP
surface_set_target(light);
draw_set_color(make_color_rgb(200, 200, 200));
draw_rectangle(0, 0, view_wview, view_hview, false);
surface_reset_target();

DRAW
draw_set_blend_mode(bm_subtract);
draw_surface(light, view_xview, view_yview);
draw_set_blend_mode(bm_normal);


Hecho eso, en cualquier lugar, por ejemplo el objeto linterna:

DRAW
draw_set_blend_mode(bm_subtract);
surface_set_target(objCtrl.light);

// Dibujar la luz: un sprite cuyos píxeles blancos iluminarán el entorno

surface_reset_target();
draw_set_blend_mode(bm_normal);

Buenash! La duda es simple, dado un ángulo inicial val y un ángulo objetivo X, ambos entre 0 y 359, cómo obtengo cuál es la dirección de giro que he de tomar, positivo o negativo, para alcanzar X de la forma más rápida? El hecho de que salte de 0 a 359 de un plumazo jode los cálculos simples y ahora mismo ando muy perdido...