Noticias

Importante: ¡Si quieres publicar tu juego no olvides leer este tema!

Comunidad Game Maker

Bienvenid@ a la comunidad hispana de Game Maker. Nuestro objetivo es crear videojuegos y dar soporte en castellano de GM. Para mejorar nuestro servicio hemos implantado, como adicion al reglamento general, algunas normas especificas en los subforos más comunes. ¡No olvides informarte antes de participar!.

Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.


Temas - DarkKRuleR

Páginas: 1 2 3 ... 10
1
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.

2
¡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 (?)

3
¡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!

4
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:

/// 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);

5
Preguntas y respuestas / Muestra de errores del lado del jugador
« en: Diciembre 23, 2019, 10:53:05 pm »
¡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?

6
¡Buenas! Veréis... una imagen lo explicará (!)



yo tengo un cuadrado rojo OPACO y una wea semitransparente. Entonces, en una surface, yo dibujo el cuadrado y ENCIMA dibujo la wea. Por algún motivo, al dibujar la surface obteniendo su textura y dibujándola en el mundo (con primitiva 3D, no sé si influya), esa transparencia de la wea parece que "atraviesa" el cuadrado, y puedo ver lo que hay detrás del cuadrado rojo, aún si éste debería ser opaco.

No tengo ningún draw_set_blend_mode así que no sé por qué pueda ocurrir. ¿Alguna idea?

7
¡Buenas! Pues veréis, tras... no sé. ¿10 años? No sé cuánto tiempo llevo con GM... Como mínimo llevo 10 años en el foro, wow xD Tras decenas de proyectos iniciados, abandonados y vuelta a empezar, por fin llevo más de un año con un proyecto que avanzo a diario, que tengo ya una base muy sólida y que veo que podré finalizar a futuro y sentirme orgulloso. Sólo he finalizado 2 juegos en mi vida, el Four Elements que es totalmente noob y ni recuerdo tener, y el del concurso que fue en pareja y hecho medio rápido xD

Pues mis planes eran subirlo a Steam (juego para PC, no tengo planes ni quiero otra plataforma), primero en modo beta para que la gente vaya probando gratis, y posteriormente lanzamiento. La idea era que fuera gratuito con varios DLC de pago para la gente que quisiera donar y de paso conseguir cosas guay, ya que en cierto modo lo hago por amor al arte y lo que más me gustaría sería conseguir que más gente lo jugase, tuviera críticas y demás. No sé si es una buena mentalidad o qué...

Y de cara a todo en general, el enfoque profesional y comercial no lo tengo nada claro. ¿Debería crear un blog donde ir subiendo desarrollo para ser transparente e ir ganando fans y feedback? ¿Debería subirlo a Steam y ahí ir dando feedback del desarrollo? ¿Debería esperar hasta cierto punto a tener algo grande y jugable para no dejar a la gente con algo no jugable? ¿Debería subirlo... teniendo en cuenta que mi desarrollo es lento y la gente podría olvidarse y perder la chispa? ¿O me conviene subirlo en cierto punto aunque tarde y actualice poco a poco? Y no entro en temas de ralladas de que me lo puedan robar y tal porque exploto. Asímismo, el 100% de los gráficos son míos, no recuerdo haber cogido código de nadie (y si lo hice 2 casos contados que dudo tengan copyright y aun asi lo tengo tan cambiado que dudo que influya), musicas por ahora nada pero cuando me ponga a ello tendré que buscar aquellas que puedan ser comercializables con alguna licencia libre.

Y... bueno. Demasiadas ralladas con este tema xDD Me rallo tanto que mantengo mi juego con mucho secretismo. Para algo que tengo estable y que le veo futuro quiero que salga bien... que con el Four Elements ya me lo robaron y subieron a otra web, y la gente de aquí fue a decirle que era un ladrón (♥) y no querría que vuelva a pasar, de ahí el hacerlo por steam y tal (pagar no es un problema) pero aún así no sé cómo vaya el tema... No sería la primera vez que cago un proyecto por hacer mal márketing o malas decisiones.

8
¡Buenas! Pues veréis. Mi PC no es algo que pueda manejar juegos del nivel de PS4 ni es de la NASA, pero sí puedo jugar juegos de nivel de PS3 con bastante... digamos, eficiencia. Así que tomo mi PC como referencia en el sentido de que si en mi PC corre bien, es buena señal. Ya que mi juego tiene 3D, asumo que el PC debe ser mínimamente potente. ¿El problema? Que lo estoy haciendo de una forma especial para buscar máxima eficiencia. Y me mosquea MUCHO que en ocasiones se me ralentiza... Os cuento.

1) No uso modelos 3D, ni precargados ni construidos. Todo, ABSOLUTAMENTE TODO está hecho de planos. Por ejemplo, el fondo es un enorme plano siempre perpendicular a la dirección de la cámara, cuyas coordenadas de textura altero dinámicamente para que parezca que se mueve. Siempre con primitivas definiendo los 4 vértices, no uso d3d_draw_floor ni similares.
2) No dibujo lo que está fuera de la vista (a mi espalda).
3) Intento siempre agrupar planos y dibujar un solo plano (4 vértices) con todo el contenido, porque el número de vértices determina el coste de procesamiento. En vez de dibujar algo 5 veces, lo dibujo en 1 solo plano con coordenadas de textura de 0 a 5.
4) Iluminación desactivada. Caras ocultas de los triángulos no se dibujan excepto en situaciones concretas. SetHidden a true para no dibujar lo oculto.
5) Disminuir el número de veces que dibujo algo usando surfaces. Gasto 1 step en todo el procesamiento lento para hacer el dibujo con sus iteraciones y weas, y consulto la textura de la surface para dibujarla posteriormente y no volver a repetir todo el procesamiento. Y el resultado vuelvo a dibujarlo en un PLANO. 4 vértices.

¿Por qué hay veces que cuando aumento el número de objetos o número de iteraciones los fps bajan de 60? Dibujando sólo planos, sólo 4 vértices, y con todas las medidas tomadas... Cuando hay gente con fps estables usando modelos con cientos de triángulos y encima iluminación... ¿Qué puedo estar haciendo mal? ¿Me equivoco en algo? A veces me desespero... Gracias...

9
¡Buenas! Pues veréis, imaginad que yo dibujo una primitiva cuya textura es un círculo. Entonces, luego yo dibujo una segunda primitiva con una forma de estrella desde el centro. Pues básicamente, quiero que sólo dibuje la estrella en aquellos píxeles que se superpongan con el círculo. Es decir, las puntas de la estrella, en caso de quedar fuera del círculo, no se dibujan.

Dudo si se puede con: https://docs.yoyogames.com/source/dadiospice/002_reference/drawing/colour%20and%20blending/draw_set_blend_mode_ext.html, pero no veo en la imagen nada que lo indique...

10
¡Buenas! Pues imaginad que tengo un sprite con mucho alpha (no es opaco). Quiero ver si hay forma de, al dibujar un sprite de éstos al lado de otro, superponiéndose, que NO se fusionen sus alphas. Que la parte superpuesta del primero sea sustituida por la parte del segundo, como cuando en el editor de imágenes usas este modo de sustitución para dibujar.

EDIT: ¿podría tener que ver con esto? Ando experimentando pero por ahora nada

https://docs.yoyogames.com/source/dadiospice/002_reference/drawing/colour%20and%20blending/draw_set_blend_mode_ext.html

11
¡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.

12
Preguntas y respuestas / Sistema de cámara 3D: movimiento libre & roll
« en: Diciembre 07, 2018, 07:01:18 pm »
¡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.



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...  :'(

13
Preguntas y respuestas / ¿Cómo está GM Studio para volver?
« en: Abril 15, 2018, 05:46:26 pm »
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.

14
¡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...

15
Preguntas y respuestas / [Resuelto] Pantalla completa bloquea el juego
« en: Agosto 08, 2017, 07:31:39 pm »
¡Buenas! Pues tan simple como eso. Al iniciar en pantalla completa, se ve todo el juego en negro y no se ve nada... tanto si inicia desde la opción del menú, como si inicia en modo ventana y manualmente la activo. En modo ventana todo se ve perfectamente. He comprobado que los objetos están ahí porque cierto evento sí reacciona, así que parece ser sólo visual, pero no sé qué hacer.

Páginas: 1 2 3 ... 10