Noticias

¡Ayuda a la Comunidad GM, haz una donación!

* Sponsor

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
¡Buenas! Pues tengo un vertex_buffer vacío. Cada vez que le doy a un botón, lo reseteo (vertex_delete_buffer) y creo uno nuevo con 1 elemento. Al volver a pulsar el botón, lo vuelvo a borrar y creo otro vertex buffer con 2 elementos... Cada vez voy haciendo el vertex más grande. Cada vez que pulso el botón se laguea un poco, y es normal, porque consume en crearlo. Pero una vez creado el vertex buffer gigante... Cada step lo único que hago es un vertex_submit. Y laguea un montón. Incluso si no dibujo el vertex y no vuelvo a crearlo ni referenciarlo, cada step laguea un montón, como si... la sola existencia del vertex provocara que cada step el garbage collector se volviera loco, aunque no esté creándolo, destruyéndolo ni dibujándolo...



Tiene muchos elementos, hay que decirlo. Cada vez que añado un elemento, son 50 cubos, y cada cubo tiene sus vértices. Pero con sólo crear 5 ya se dispara así de loco. Y se supone que una vez creado el buffer, éste no debería consumir ni el garbage collector debería volverse loco, no estoy haciendo nada con él, literalmente... ¿Qué se me escapa?

El código para crear el vertex es:

function getVertexMegaCorrupcion() {
        var _ver = vertex_create_buffer();
        vertex_begin(_ver,oControl.vertexFormat);

        for (var i = 0; i < instance_number(oCorrupcion); ++i) {
            var _cor = instance_find(oCorrupcion,i);
            repeat 50 {
                var _phi = choose(0,90), _theta = choose(0,90);
                var _dir = random(360), _lon = random(25);
                var _xMas = _lon*dcos(_dir), _yMas = -_lon*dsin(_dir);
// Script que hace una secuencia de vértices (vertex_position_3d, vertex_colour, vertex_texcoord)
            }
        }
        vertex_end(_ver);
        return _ver;
    }

Sí, es un poco grande, es lo que llamo un megamodelo, mega vertex buffer. Un vertex agrupando muchos objetos para hacer 1 solo draw (vertex_submit). Pero en el pasado hice cosas peores y más grandes... Y con sólo 2 -3 objetos ya comienza el garbage collector a volverse loco!

EDIT: Si borro el vertex con vertex_delete_buffer y lo reconstruyo, el garbage se vuelve más y más loco con cada reconstrucción... aunque el número de oCorrupcion no cambia, así que debería re-crearlo con el mismo tamaño. Algo hago mal...

2
Preguntas y respuestas / [Resuelto] Orden de dibujo en 3D para GMS2
« en: Agosto 11, 2021, 02:09:19 pm »
¡Buenas! Pues usando el 3D en GMS1.4, con activar el zwrite ya era automático. Da igual en qué orden dibujo cosas en 3D, las que están más cerca de la cámara se dibujan por encima de las que están lejos. Esto no parece funcionar del todo bien en GMS2... Me ocurren casos donde no aplica. Tengo esto en create. Lo raro es que funciona para algunos triángulos pero para otros no.

gpu_set_alphatestenable(true);
gpu_set_zwriteenable(true);
gpu_set_ztestenable(true);

Aquí el ejemplo



Un tubo rojo y otro blanco, ambos salen de una esfera amarilla. Podemos ver que si miramos desde la derecha, el tubo rojo está más cerca de la cámara y se ve por encima del blanco, y si miramos por la izquierda, el tubo blanco está más cerca de la cámara y se ve por encima del rojo. TODO BIEN. Pero esa esfera amarilla es gigante y debería estar por encima de AMBOS TUBOS, cubriéndolos. ¿Por qué no aplica a la esfera?

RESUELTO, estaba definiendo los triángulos en el orden incorrecto para la esfera

3
¡Buenas! Esto es mu raro... tengo una surface con color plano de fondo y, cada vez que dibujo un sprite semitransparente, éste deja un "agujero" que me permite ver a través de la surface... ¿Alguna idea? >_<

if (!surface_exists(sur)) sur = surface_create(size, size);
if (surface_exists(sur)) surface_set_target(sur);
draw_clear_alpha(c_black, 0);
draw_set_blend_mode(bm_normal);
draw_sprite_ext(iconoDeColorOpacoRojoOscuro, 34, 256, 256, 8, 8, 0, c_white, 1);

draw_sprite_ext(manchaBlancaConTransparencias, 0, xMancha[i], yMancha[i], size, size, 0, colMancha[i], alphaMancha[i]);
 
surface_reset_target();
   
if (surface_exists(sur)) txEstrella = surface_get_texture(surEstrella);

EDIT: Resuelto con bm_add, el efecto me gusta.

4
¡Buenas! ¿Alguien conoce cuál es la implementación de d3d_model_block y similares? Como no tiene coordenadas de textura, alpha ni color, tuve que crearme uno personalizado, y pos tiro de d3d_model_primitive_begin y d3d_model_vertex_texture_colour, y me va perfecto. Pero noto que el juego ralentiza bastante. Lo que gano en eficiencia de poder tener 300 cubos en 1 solo modelo y 1 sola llamada a draw, lo pierdo en tener que definir los vértices de cada una en cada step (modelo dinámico que debo redefinir en cada step).

¿Sabéis si d3d_model_block también hace esto, o si hace algo como "precargar" el modelo e insertarlo? ¿Es posible hacer (emularlo) en caso de que exista eso, definir los vértices del modelo en otro lado e "insertarlo"/"fusionarlo" al modelo actual? Si tengo que hacer 300 draw_block, volvería de nuevo a ralentizar todo...

5
Preguntas y respuestas / Fatal error in Vertex Shader Compilation
« en: Noviembre 02, 2020, 06:34:43 pm »
Así sin más, sin menos. Le explotó en la cara en el PC de algunos amigos. Es raro porque en el pasado ya les funcionó lo mismo en esos mismos PCs, y no veo que haya añadido nada nuevo para que ocurra... Al resto nos va bien.


6
Preguntas y respuestas / [Resuelto] Orden triángulos en modelo 3D
« en: Octubre 08, 2020, 02:17:31 am »
¡Buenas! La duda, la duda... ¿Cómo lo hace la gente en el mundo y todos los juegos para no tener problemas con el orden de los triángulos en un modelo 3D? Imaginad un caso simple, una mesa. Si dibujo primero las patas y luego la tabla, se ve bien mirando desde arriba, pero si miro desde abajo... Al principio mis modelos eran simples pero... a la mínima complejidad, el modelo peta si lo miras desde otro lado. No se me ocurre nada que sea... viable. ¿Cómo le hacen en los demás juegos? Gracias.

7
¡Buenas! Os cuento el resumen. Yo tengo mis personajes. Defino las coordenadas de las partes del cuerpo y sus ángulos (hombro, codo, cintura, rodilla...), para tener la información de dónde dibujar el cuerpo y en qué pose. Entonces dibujo los sprites en esas coordenadas (el brazo, la mano, la pierna, el pie).

Qué pasa, que se ejecutan muchos draw_ .... y el coste se dispara bastante. He hecho comprobaciones y es como el 90% del coste de mi juego, sólo los personajes. Al parecer lo costoso no es la complejidad de qué dibujas, sino el hecho de llamar a las funciones de dibujo. Y como ejecuto muchos draw_ ... separados, pues consume mucha memoria.

¿Hay alguna forma de hacer esto más eficiente? Al ser el cuerpo dinámico, en principio no puedo hacer un modelo estático, pues si me muevo, las piernas se mueven, cambiando las coordenadas de sus vértices. ¿Alguna forma de dibujar todo esto sin tener el coste por llamar muchas veces a draw? ¿Alguna forma de, no sé, guardar todas esas coordenadas en una iteración, y luego dibujar todo de golpe, aunque sean coordenadas distintas en cada step?

EDIT: Justo he encontrado vertex_create_buffer y vertex_submit y demás, podría ser la solución... pero me cuesta entender.

8
¡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?

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

10
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.

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

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

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

14
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?

15
¡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?

Páginas: 1 2 3 ... 10