Menú

Mostrar Mensajes

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

Menú Mostrar Mensajes

Temas - DarkKRuleR

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

[gml]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;
    }
[/gml]

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

[gml]gpu_set_alphatestenable(true);
gpu_set_zwriteenable(true);
gpu_set_ztestenable(true);[/gml]

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

[gml]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, yMancha, size, size, 0, colMancha, alphaMancha);

surface_reset_target();
   
if (surface_exists(sur)) txEstrella = surface_get_texture(surEstrella);[/gml]

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

[gml]/// 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);[/gml]
#14
¡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?
#16
¡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.
#17
¡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...
#18
¡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...
#19
¡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
#20
¡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.
Powered by EzPortal
SMF spam blocked by CleanTalk