Comunidad Game Maker

Únicamente con GML

Mediante las funciones device_ mouse GM:S permite usar hasta 5 dispositivos diferentes, y por dispositivos diferentes entiéndase dedos. Esas son las funciones ideales cuando se quiere implementar multitouch. Me parece que GM:S incluye un tutorial al respecto.

http://docs.yoyogames.com/source/dadiospice/002_reference/mouse,%20keyboard%20and%20other%20controls/device%20input/index.html

No, por una sencilla razón: El reglamento del foro

Desactivando las características de ahorro de energía del dispositivo, es decir, usar la siguiente función:

http://docs.yoyogames.com/source/dadiospice/002_reference/operating%20system/os_powersave_enable.html

Esa función para agregar la tecla no la encuentro en el manual  ???. Acabo de probar con las funciones listadas en el manual y se muestra el rectángulo sin problemas

Parece que las funciones YoYo_ fueron renombradas hace más de dos años (de una versión a otra), pero se dejaron latentes en GM:S para ofrecer compatibilidad. Hay que tener en cuenta que de hace dos años a la fecha, muchas cosas han cambiado, entre ellas la incorporación del nuevo sistema de dibujo y el evento DRAW GUI, que es la capa donde se dibujan las teclas virtuales drectamente.

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

Para ir a lo seguro, creo que lo mejor es usar las funciones más recientes.

Ese mensaje tiene más de dos años en la GMC y no se refiere a la función virtual_key_show(), se refiere a YoYo_ShowVirtualKey que me parece es una función que ya no existe en una versión de GM obsoleta.

Los tutoriales incluídos en GM:S hacen uso de virtual_key_show. Hace unos meses hice uno de esos tutoriales y no tuve problemas en que apareciera el rectángulo de la tecla virtual. A mi me parece que virtual_key_show() es una función vigente y funcional

¿vkup es el nombre de la variable que usaste para guardar el resultado de virtual_key_add()?

porque una cosa es vk_up y otra vkup, y en virtual_key_show(); debe ir el nombre del manipulador (la variable) y no el de una constante del teclado. La función virtual_key_show() también se ve afectada por funciones draw que ajusten el color y el alfa.

Así están mapeados en GM:S:

Botón trasero - vk_backspace
Botón HOME - Tecla H
Botón MENÚ - Tecla M
Botón SEARCH - vk_control

Problemas en la programación... ¿Eso qué quiere decir exactamente? Problemas hay muchos. ¿Algún indicio sobre qué está mal en específico? ¿Una muestra del código que usas, quizás?

Tengo entendido que a partir de Agosto (corríjanme si me quivoco) el sistema de ADS viejo (GM:S 1.2 y anteriores) dejará de funcionar y el uso del nuevo sistema de extensiones para publicidad (GM:S 1.3 y siguientes) será obligatorio para manejar ADS

No uso ads, así que no estoy bien enterado, pero recuerdo haber leído algo al respecto

Una página de textura es un contenedor que alberga todos los gráficos del juego colocados y ordenados en un espacio de ciertas dimensiones. Es como un catálogo en donde se insertan las imágenes (sprites, fondos). Por ejemplo, Si tu juego tiene 500 imágenes entre subimágenes de sprites animados, sprites estáticos y fondos, GM va tomando esas imágenes y las junta en digamos (es sólo una suposición) 20 páginas de textura. Cuando GM necesita dibujar algo, internamente hace un llamado a la página en textura donde se encuentra el recurso en cuestión.

Los problemas ocurren cuando un gráfico es mayor que la dimensión establecida de la página de textura (esta es una opción que se puede cambiar en la configuración global del juego). GM reajusta el tamaño de los gráficos para que se ajusten o "quepan" dentro de una página de textura, lo que puede crear gráficos borrosos o distorsionados.  Creo que esto no sería tu caso, pues tus tiles van a tener dimensiones de decenas de pixeles o cientos de pixeles, según comentas.

Yo he usado muy pocas veces los tiles, y nunca para crear "paisajes" enteros. Mi duda sobre todo es si habría problemas en dispositivos Android al ensamblar muchos tiles. Creo que no, pero tendrías que probarlo y ver si no hay baja de rendimiento en ciertos modelos de dispositivos móviles. En PC creo que no habría problemas por tener muchos tiles

Otro detalle es que GM por defecto crea las páginas de textura a lo salvaje, es decir, mete gráficos como le da la gana, por ejemplo, si el juego tiene 10 niveles, mezcla gráficos del nivel 1 con gráficos del nivel 10. Lo que recomienda YoYo es (sólo disponible en la versión PRO) usar el administrador de grupos de textura, de esta manera creas grupos de manera ordenada, y así te aseguras que si estás en el nivel 2, las páginas de textura usadas tienen solamente gráficos correspondientes a ese nivel y no tienen gráficos "intrusos" de otros niveles, lo que mejora el rendimiento a la hora de dibujar cosas (esto se notaría más en algunos dispositivos android de gama baja, no en PC)

Gracias por el comentario, spidermonkey. Sí tengo un perfil en deviantart el cual cree hace poco, aunque la verdad es que no tengo mucho material gráfico subido. Una vez que salga la beta de mi juego pienso colgar más y mejores sprites ahí, pero de momento no quiero mostrar sprites antes de mostrar el juego. Gracias también por el link a www.pixeljoint.com, se ve interesante el sitio.

[gml]
randomize()
instance_create(x, y, choose(obj_item1, obj_iem2, obj_item3) )
[/gml]

Teniendo en cuenta lo que ha comentado Guacusio, sobre que las instancias se crean todas en el mismo ciclo y que no es necesario cambiar su orden de creación, la solución a mi me parece bastante fácil, aunque no estoy seguro si funcionaría porque no la he probado

En el evento CREATE del objeto cámara:
[gml]view_xview[0] = x - offset_horizontal
view_yview[0] = y - offset_vertical[/gml]

Eso forzosamente posicionaría la view en la posición del obj_camara antes de que se ejecutara DRAW, por lo que el primer frame se debería dibujar en la posición correcta y no en una posición alejada del objeto cámara. No tengo manera de saber el valor de offset exacto para tu juego, pero es cuestión de que les des valores adecuados.

¿En qué evento y con qué finalidad se crea el segundo objeto? Más que destruír uno de dos, la intención debería ser que el segundo no se creara.