Comunidad Game Maker

Sí, el doble signo igual se usa para comparar, el signo sencillo para asignar. Ten en cuenta que En game maker:

if (subir_vida == 1) también se puede escribir if (subir_vida)

if (subir_vida == 0) también se puede escribir if (!subir_vida)

Sobre lo que mencionas de indicar cuándo es verdadera y cuando falsa

IF (subir vida)
{
    el código que pongas aquí se ejecuta si subir_vida es 1 (verdadero)
}
ELSE
{
   el código que pongas aquí se ejecuta cuando subir_vida es 0 (falso)
}

Cuando ocurre una colisión, el código se puede poner en cualquiera de los dos objetos involucrados en la colisión. Como yo lo haría sería:

EN CREATE del objeto jugador
subir_vida = 0

En EVENTO COLISIÓN del objeto con el que chocas (item, pared, etc)
obj_jugador.subir_vida = 1    <---- llamas a la variable del objeto jugador desde el objeto item

En STEP del objeto jugador
if (subir_vida)
{
    salud += 5;
    subir_vida = 0     
}

El código de colisión y el de step puede ponerse en cualquiera de los dos objetos, pero tienes que se cuidadoso al llamar las variables, saber cuáles son locales y cuales no. Por ejemplo, si quieres subir la vida del jugador desde el objeto item

en STEP del objeto item
if (obj_jugador.subir_vida)
{
    obj_jugador.salud += 5;
    obj_jugador.subir_vida = 0     
}

Cita de: selafio en Agosto 12, 2013, 08:28:09 PM

(y ademas me encontre que al colisionar con el objeto, el nivel aumentaba desmesuradamente hasta que dejaba de colisionar con el. Como hacer para que al colisionar con un objeto este detenga al objeto que esta colisionando con el? como hacer murallas y esas cosas...)

Lo que pasa es que en el evento de colisión, tú haces algo parecido a esto:

If colision == 1           //Si hay colisión
     {salud += 5}        // Aumentar cantidad de salud

Lo que tienes que hacer es declarar una variable que funcione como "interruptor" o switch para aumentar la salud. En CREATE:
subir_vida = 0

En el evento de colisión
subir_vida = 1                            //Indicar que hay que aumentar la salud

En el evento step
if (subir_vida == 1)
{
    salud += 5;
    subir_vida = 0        //Después de subir la salud,  "desactivas" la variable para que ya no siga subiendo
}

http://www.fontspace.com/

http://www.dafont.com

Hay demasiados tipos de fuentes como para que uno al azar se adapte a tu juego.

Mmm pues qué mañosos! *Rompe el manual de GM*  >:(

La posición de los caracteres corresponde a ANSI/Unicode, no a ASCII. ¡Con razón nunca salían los condenados caracteres acentuados ni la ñ! Gracias Texic, tienes ganado el cielo de los programadores  :D

Creo que yo fui el que posteó eso del framework. Pero no debias desinstalar el framework, pues es muy necesario en windows

Era deshabilitar la versión más reciente (4 o 4.1, no sé bien) y dejar funcionando la 3. Tampoco recuerdo bien la respuesta pues la leí en YoYo.

Yo intenté hacer lo mismo y no pude. No me aparecían los caracteres acentuados a la hora de dibujar texto.

No recuerdo bien, suponiendo que comienzas tu juego de caracteres por el espacio, creo que la ñ debe estar en la subimagen 132  de tu sprite, porque los primeros 31 caracteres del código ascii no se utilizan. Si logras que te funcione, comparte la solución por favor, sería de gran ayuda.

Justamente los últimos días he estado haciéndome líos planeando el inventario de mi proyecto. Y justamente también quiero un inventario donde esté el item y la cantidad y otro solamente el item. Mi objetivo es que sea similar al inventario de Castlevania SOTN / aria of sorrow. Hasta ahora sólo he escrito código en papel, pero más o menos voy sacando algo.

Sobre tus arreglos:

- Estás usando " Pocion[2][0] ", si lo que quieres es declarar un arreglo de dos dimensiones, la sintaxis correcta es Pocion[2,0] = algo

-

Cita de: Fenix oscuro en Julio 21, 2013, 11:10:30 AM
y solo llegue a la conclusion de esto

Create Event:
Inventario[0] = Amuleto_A
Inventario[1] = Amuleto_B
Inventario[2] = Amuleto_C

Eso esta bien, pero es más cómodo y fácil de entender esto (yo le llamo etiquetar los índices del arreglo, otros le llaman declarar constantes):

Create EVENT:
amuleto_a = 0
amuleto_b = 1
amuleto_c = 2
espada_1 = 3
escudo_2 = 4

Inventario[amuleto_a] = ID del amuleto A
Inventario[amuleto_b] = ID del amuleto B
Inventario[amuleto_c] = ID del amuleto C
Inventario[espada_1] = ID de la espada tipo 1
Inventario[escudo_2] = ID del escudo tipo 2

Obviamente, puedes hacer lo mismo en un arreglo de dos dimensiones, que creo es lo más conveniente, y asi no tienes que preocuparte por saber qué número de casilla corresponde a qué item, o puedes mover los ítems en el arreglo (amuleto_a = el numero que gustes) y la estructura del arreglo se mantiene

-El código que tienes para subir o bajar por el inventario está bien, pero el detalle es que tal como está no puedes ciclar el inventario (si estás en el último item, tienes que navegar por todo el inventario para llegar al primer item)

Si llega a funcionar, postearé mi sistema de inventarios cuando esté completo, aunque falta todavía para que eso suceda  :-[

Usar superficies sólo por reemplazar  el dibujado "normal" de cada instancia, no creo que proporcione beneficios en el rendimiento. Además. las superficies se crean en la memoria de video, eso está bien, pero hay que tener en cuenta que una gran cantidad de usuarios tienen "video integrado", por lo que se va a utilizar la memoria RAM de la PC para crear las superficies

Donde si marcan diferencia las superficies es por ejemplo: Dibujar figuras, líneas o polígonos con las rutinas propias del GM (sin sprites), En lugar de ejecutar las rutinas a cada paso,  se puede dibujar todo una sola vez en una superficie,  y dibujar esa superficie para mostrar la figura, lo que te ahorraría poder de cómputo del CPU

No lo he comprobado, pero en algún lugar leí que si se usan font sprites, el rendimiento mejora si en lugar de dibujar directo la fuente, se dibuja el texto en una superficie.

El código que te puso Galo es para que lo pongas en el evento STEP del personaje cola. El detalle es que así como está, el personaje cola estaría pegado en todo momento al personaje principal

se puede hacer x=principal.x + espacio para que haya un espacio entre el personaje principal y el de la cola. Esto presenta tres problemas:

1. El valor del espacio siempre se va a sumar a la coordenada x del personaje principal, pero esto no debe ser siempre así: si el personaje principal avanza hacia la izquierda, el valor de espacio se debería restar en lugar de sumar.

2. Se deduce del punto 1, que hay que tener una variable que indique hacia donde avanza el personaje principal, para saber si restar o sumar el espacio.

3. A lo mejor se va a ver poco natural que siempre haya la misma distancia entre los dos personajes, como que se vería muy mecánico. Se vería mejor que el personaje cola tardara un tiempo en reaccionar antes de seguir al principal.

No, no es la variable timer. Al llegar a 4000, los fps marcaban 35.

Hice que se reiniciara timer al llegar a 4000, pero los frames seguían bajando. Luego revisé la memoria: Al empezar el juego, ocupaba alrededor de 39 MB de memoria RAM, para cuando el timer llegaba a 4000, la memoria ocupada era de como 80 MB

El problema es cómo estás usando la dll para manejar INIs. Esa dll es más rapida que GM porque las operaciones las hace en memoria, pero tú estás creando el ini una y otra vez y asignándolo su ID a la variable "path"en step. Eso debes moverlo a create, para que se ejecute nada más una vez. El código que maneja el INI lo puse en comentarios, y los fps ya no bajan, ni el espacio ocupado en RAM aumenta

No tengo idea por qué funciona así, pero parece que en memoria se crean muchas copias del mismo INI una y otra vez. Al menos haz descubierto una manera "divertida" de consumir los recursos de los usuarios  XD

Ah ya, había entendido mal. Pero 3500 es un número muy bajo, el límite de GM en enteros anda por ahí de los miles de millones (no recuerdo bien). Aquí hay una DLL que según permite manejar números enormes, sólo limitados por la capacidad de tu PC (yo no la he usado)

http://gmc.yoyogames.com/index.php?showtopic=454894

¿El contador sólamente cuenta? ¿No hay nada más donde tenga efecto? También pudieras subir el proyecto para probarlo

Cita de: Karras en Julio 18, 2013, 07:32:37 PM
Pues lo estuve probando, eso si sin animaciones y creo que quedaba pixelado cuando el personaje media menos de 200 y pico pixeles de altura... Hasta ahora no e visto ni un juego de GM que lo utilizara, pero en otros juegos e visto que queda un movimiento bastante artificial y me gustaria tenerlo claro antes de pasar todos los personajes a vectores.

A mi esa manera de animar siempre me ha parecido que se ve muy artificial, y entre más grande el srpite, más se nota. Difícilmente vas a ver un juego 2D hecho en GM o en cualquier otra plataforma, con personajes de más de 200 pixeles de alto

El avatar de tu cuenta mide 64X64, tiene rellenos planos y no se ve pixelado.

¿Quieres decir que vas subiendo la velocidad del room en cada paso?

No estoy seguro, pero creo que ese es el límite de tu PC, más allá de eso, ya no puede procesar todo en tiempo. No es que el contador sea elevado (GM puede manejar cifras bastante altas), sino que lo que controlas con el contador no es un número cualquiera. ¿Por qué quieres elevar tanto los fps?

GM es muy permisivo con ciertas cosas, aunque si es raro que la dll no soporte espacios. No pensé que eso fuera el problema, yo de pura casualidad vi un ejemplo del creador de la dll, y vi que no manejaba espacios en el ini, por eso desde ahí hice mis inis sin espacios, pero no había probao a ver si funcionaba con espacios. Siempre se aprende algo nuevo  :)

Mmm, yo también uso esta dll, y no me da problemas. la única diferencia que veo es que yo no dejo espacios en el archivo .ini, por ejemplo:

Path=song/kashmir.mp3

pero no creo que sea eso...