Pues eso, me gustaria usar
esta caracteristica de:
http://wiki.bennugd.org/index.php?title=Scale_resolution_orientation
de rotacion de pantalla....
pero no reconoce la varible global.
PixTudio Blender 1.0.0 (Nov 11 2016 22:31:22)
Pixtudio comes with ABSOLUTELY NO WARRANTY
See COPYING for copyright details
D:\pixtudio\tests\test_scale_resolution_aspectratio.prg:38: error: Unknown identifier ( error in token: "SCALE_RESOLUTION_ORIENTATION" ).
D:\pixtudio\tests\test_scale_resolution_aspectratio: doesn't exist or isn't version 8 DCB compatible
en cambio estas dos, si la reconoce:
scale_resolution -> Si funciona bien
scale_resolution_aspectratio -> No parece hacer caso al cambio, siempre se ve con Relacion aspecto, y no estira la pantalla.
Resumiendo, lo que si funciona o lo que no funciona.... (lo comento dentro del código en mayusculas)
//Activates/deactivates scale_resolution.
if(key(_r))
while(key(_r)) frame; end //Wait until the key is released
if (scale_resolution==-1); //If scale_resolution is not active...
scale_resolution=08000480; //...then resize the screen FUNCIONA
else //If scale_resolution is already working...
scale_resolution=-1; //...then stop it. //FUNCIONA
end
set_mode(800,600,32);
end
//This rotates the screen. Only works when SCALE_RESOLUTION is being used. //NO LO RECONOCE EL COMPILADOR!!
if(key(_0)) scale_resolution_orientation=SRO_NORMAL;end
if(key(_1)) scale_resolution_orientation=SRO_LEFT;end
if(key(_2)) scale_resolution_orientation=SRO_DOWN;end
if(key(_3)) scale_resolution_orientation=SRO_RIGHT;end
//This activates/deactivates the ASPECT RATIO. Only works when SCALE_RESOLUTION is being used.
if(key(_a))
while(key(_a)) frame; end
if (scale_resolution_aspectratio==0);
scale_resolution_aspectratio=SRA_PRESERVE;
else
scale_resolution_aspectratio=SRA_STRETCH; //NO FUNCIONA! NO HACE CASO
end
set_mode(800,600,32);
end
Si me lo pueden arreglar, que funcionase.
Me gustaria usarlo.
{ "MODE_WINDOW" , TYPE_DWORD , MODE_WINDOW },
{ "MODE_FULLSCREEN" , TYPE_DWORD , MODE_FULLSCREEN },
{ "MODE_WAITVSYNC" , TYPE_DWORD , MODE_WAITVSYNC },
{ "WAITVSYNC" , TYPE_DWORD , MODE_WAITVSYNC },
{ "MODE_8BITS" , TYPE_DWORD , 8 },
{ "MODE_16BITS" , TYPE_DWORD , 16 },
{ "MODE_32BITS" , TYPE_DWORD , 32 },
{ "MODE_8BPP" , TYPE_DWORD , 8 },
{ "MODE_16BPP" , TYPE_DWORD , 16 },
{ "MODE_32BPP" , TYPE_DWORD , 32 },
{ "MODE_MODAL" , TYPE_DWORD , MODE_MODAL }, /* GRAB INPUT */
{ "MODE_FRAMELESS" , TYPE_DWORD , MODE_FRAMELESS }, /* FRAMELESS window */
{ "SCALE_NONE" , TYPE_DWORD , SCALE_NONE },
{ "SRO_NORMAL" , TYPE_DWORD , SRO_NORMAL },
{ "SRO_LEFT" , TYPE_DWORD , SRO_LEFT },
{ "SRO_DOWN" , TYPE_DWORD , SRO_DOWN },
{ "SRO_RIGHT" , TYPE_DWORD , SRO_RIGHT },
{ "SRA_STRETCH" , TYPE_DWORD , SRA_STRETCH },
{ "SRA_PRESERVE" , TYPE_DWORD , SRA_PRESERVE },
{ "SCALE_NEAREST" , TYPE_BYTE , 0 },
{ "SCALE_LINEAR" , TYPE_BYTE , 1 },
Y LAS VARIABLES
"graph_mode = 0;\n"
"full_screen = 0;\n"
"scale_resolution = -1;\n"
"scale_resolution_aspectratio = 0;\n"
"BYTE scale_quality = 1;\n";
te reporto las cosas que NO funcionan:
{ "MODE_WINDOW" , TYPE_DWORD , MODE_WINDOW }, Siempre se ejecuta en modo ventana...
{ "MODE_FULLSCREEN" , TYPE_DWORD , MODE_FULLSCREEN }, ---> No se puede aplicar en SET_MODE, tampoco no funciona en la variable full_screen.
error: Incorrect number of parameters. Function: SET_MODE MinParams: 3. ( error in token: "(" ).
se supone que el 4 parametro de set_mode deberia permitir añadir atributos: MODE_FULLSCREEN,MODE_WAITVSYNC,MODE_WINDOW ...
{ "MODE_WAITVSYNC" , TYPE_DWORD , MODE_WAITVSYNC },
{ "WAITVSYNC" , TYPE_DWORD , MODE_WAITVSYNC },
Esta MODE_WAITVSYNC no puedo aplicarlo... error en 4 parametro en set_mode
{ "MODE_8BITS" , TYPE_DWORD , 8 },
{ "MODE_16BITS" , TYPE_DWORD , 16 },
{ "MODE_32BITS" , TYPE_DWORD , 32 },
{ "MODE_8BPP" , TYPE_DWORD , 8 },
{ "MODE_16BPP" , TYPE_DWORD , 16 },
{ "MODE_32BPP" , TYPE_DWORD , 32 },
Estas de profundidad de color, no hay problema, solo es un numero, 8,16,32.
{ "MODE_MODAL" , TYPE_DWORD , MODE_MODAL }, /* GRAB INPUT */
{ "MODE_FRAMELESS" , TYPE_DWORD , MODE_FRAMELESS }, /* FRAMELESS window */
Estas no puedo aplicarlo... error en 4 parametro en set_mode
{ "SCALE_NONE" , TYPE_DWORD , SCALE_NONE },
desconozco el uso de esta constante, pero seguro que vale 0
{ "SRO_NORMAL" , TYPE_DWORD , SRO_NORMAL },
{ "SRO_LEFT" , TYPE_DWORD , SRO_LEFT },
{ "SRO_DOWN" , TYPE_DWORD , SRO_DOWN },
{ "SRO_RIGHT" , TYPE_DWORD , SRO_RIGHT },
Carece sentido tener las Constantes, si no existe la variable global: scale_resolution_orientation
no existe...
{ "SRA_STRETCH" , TYPE_DWORD , SRA_STRETCH },
{ "SRA_PRESERVE" , TYPE_DWORD , SRA_PRESERVE },
Estas no funcionan en la variable: scale_resolution_aspectratio
{ "SCALE_NEAREST" , TYPE_BYTE , 0 },
{ "SCALE_LINEAR" , TYPE_BYTE , 1 },
Si funciona con scale_quality.
Y LAS VARIABLES
"graph_mode = 0;\n"//funciona bien,
"full_screen = 0;\n"//no funciona, no hace caso a las constante
"scale_resolution = -1;\n"//Si funciona, perfectamente
"scale_resolution_aspectratio = 0;\n"//No funciona usando las constantes
"BYTE scale_quality = 1;\n";//si funcionan
Hola:
Lo de la orientación es intencionado: considero que la rotación debe gestionarla la plataforma y no PixTudio, así que eliminé el código para hacer rotaciones. Tanto en Android (http://"https://developer.android.com/guide/topics/manifest/activity-element.html#screen") como en iOS es muy sencillo decir que la aplicación debe lanzarse en modo apaisado.
Por otra parte: el tema del aspect_ratio ya está anotado aquí (http://"https://bitbucket.org/josebagar/pixtudio/issues/15/scale_resolution_aspectratio-is-not-being").
Respecto a MODE_FULLSCREEN y demás: Sí deberían funcionar pero eliminé el parámetro de "densidad de bits" en set_mode() dado que PixTudio sólo funciona a 32bpp.
De forma que lo que en BennuGD es:
set_mode(800, 600, 32, MODE_FULLSCREEN);
en PixTudio es:
set_mode(800, 600, MODE_FULLSCREEN);
[Edito] Gracias por daros cuenta: he quitado las constantes relacionadas con las rotaciones, porque no tienen efecto.
Si no cuesta mucho dejarlo dejalo.
Son mas incompatiblidades añadidas a pixtudio.
Si quiero ejecutar un juego a posta volcado en pc, en android no iría bien el mismo juego.
Pienso yo. Y si no cuesta mucho, mejor dos opciones para girar, una por código y otra por la plataforma en la que rule.
Es que siguiendo esa regla de tres, casi todo sobra, casi todo se puede hacer en android directamente :D ;)
Quote from: DCelso on November 27, 2016, 08:18:25 PM
Si no cuesta mucho dejarlo dejalo.
Son mas incompatiblidades añadidas a pixtudio.
Si quiero ejecutar un juego a posta volcado en pc, en android no iría bien el mismo juego.
Pienso yo. Y si no cuesta mucho, mejor dos opciones para girar, una por código y otra por la plataforma en la que rule.
Es que siguiendo esa regla de tres, casi todo sobra, casi todo se puede hacer en android directamente :D ;)
No puedo dejar la rotación por la forma en que he cambiado el sistema de renderizado en PixTudio para que use la tarjeta gráfica (a través de SDL) en lugar de pintar por software.
Y como lo he quitado, no tiene sentido que deje órdenes en los módulos que luego son ignoradas. Ponte en la perspectiva de una persona que llegara nueva a PixTudio y viera ciertas opciones que no hacen nada. ¿Qué sentido tendría eso?
Lo que sí puedo hacer es una cabecera de "compatibilidad" con BennuGD que salve estas cosas y permita compilar (pero el comportamiento cambiará en algunas cosas).
En todo caso, creo que sería incorrecto hacer ésto del lado de PixTudio. Cuando BennuGD lo hizo fue porque había plataformas donde no había soporte nativo para rotar la pantalla, pero era para salvar una carencia de la plataforma que no existe en las plataformas a las que está destinado PixTudio.
Pues no se, quítalo entonces, para que esté de adorno ... :D , para que compile el código se puede hacer un .h con lo que falte.
Creo que lo que más interesa ahora es que, aunque use solo modo 32 bits para el renderizado, pueda cargar recursos de las distinas profundidades (básicamente pngs y fpgs) ya que ocupan menos espacio en disco y el jaleo que conlleva pasarlas a 32 bits los hace incompatibles hacia atrás en plataformas que no soportan 32 bits y no compensa o dificulta la migración de éstos.
:) .
Ah! Menos mal!!
Lo vi raro que no funcionara, o constante es que carecen de uso.
Gracias por la aclaración del set_mode pues des que llege a pixtudio, usaba el 3r parametro para la profundidad de bits sin darme cuenta!
Sobre uso de orientación/rotación de pantalla si la idea es usarlo en dispositivos móviles claro.
Te confirmó que cualquier apk que se hace con pixtudio no tiene el auto rotado, por ejemplo si cogemos el móvil en horizontal, el juego se programo en landscape, si dentro del juego nos apetece girar 180°, la idea es que rote, gracias al sensor de inclinación...
Pero no lo hace...
Con la variable global esa de orientación estaría solucionado.
Realmente lo vas a borrar 100%???
No abra manera de que se pueda rotar...
Técnicamente no se si es una característica propia de android integrada en el apk.... No se.
Podría tener alguna solución mas adelante sobre este tema de orientación??
Sobre funciones , constantes y variables globales... Propias para operaciones sobre 8/16 bits se pueden eliminar.
Estaría enfocado solamente a 32bits únicamente.
Quote from: DCelso on November 27, 2016, 08:18:25 PM
Si quiero ejecutar un juego a posta volcado en pc, en android no iría bien el mismo juego.
Es posible que el mismo juego se pueda programar en dos sistemas de destinos diferentes, la magia esta en la variable OS_id
Con ella puedes separar códigos, métodos de entrada, botones en pantalla, modo de pantalla.
Y el juego es el mismo.
Quote from: DCelso on November 27, 2016, 09:45:06 PM
Pues no se, quítalo entonces, para que esté de adorno ... :D , para que compile el código se puede hacer un .h con lo que falte.
A ver si hago la cabecera y la subo a la documentación. En todo caso, el PixTudioPM ya hace esa tarea.
Quote from: DCelso on November 27, 2016, 09:45:06 PM
Creo que lo que más interesa ahora es que, aunque use solo modo 32 bits para el renderizado, pueda cargar recursos de las distinas profundidades (básicamente pngs y fpgs) ya que ocupan menos espacio en disco y el jaleo que conlleva pasarlas a 32 bits los hace incompatibles hacia atrás en plataformas que no soportan 32 bits y no compensa o dificulta la migración de éstos.
:) .
Sí, eso es un poco rollo. De todas formas, aunque con limitaciones, es posible cargar recursos de 16bpp.
Quote from: alicesimu on November 27, 2016, 10:11:33 PM
Ah! Menos mal!!
Lo vi raro que no funcionara, o constante es que carecen de uso.
Gracias por la aclaración del set_mode pues des que llege a pixtudio, usaba el 3r parametro para la profundidad de bits sin darme cuenta!
Sobre uso de orientación/rotación de pantalla si la idea es usarlo en dispositivos móviles claro.
Te confirmó que cualquier apk que se hace con pixtudio no tiene el auto rotado, por ejemplo si cogemos el móvil en horizontal, el juego se programo en landscape, si dentro del juego nos apetece girar 180°, la idea es que rote, gracias al sensor de inclinación...
Pero no lo hace...
Con la variable global esa de orientación estaría solucionado.
Realmente lo vas a borrar 100%???
No abra manera de que se pueda rotar...
Técnicamente no se si es una característica propia de android integrada en el apk.... No se.
Podría tener alguna solución mas adelante sobre este tema de orientación??
Sobre funciones , constantes y variables globales... Propias para operaciones sobre 8/16 bits se pueden eliminar.
Estaría enfocado solamente a 32bits únicamente.
En principio hacer que la resolución cambie al girar el móvil sí es técnicamente viable aunque ahora mismo probablemente no funcione y tengo que ver cómo.
Por favor ponme un bug en bitbucket para que no se me olvide y lo miro cuando tenga un rato.
Quote from: josebita on November 27, 2016, 09:19:07 PM
Quote from: DCelso on November 27, 2016, 08:18:25 PM
Si no cuesta mucho dejarlo dejalo.
Son mas incompatiblidades añadidas a pixtudio.
Si quiero ejecutar un juego a posta volcado en pc, en android no iría bien el mismo juego.
Pienso yo. Y si no cuesta mucho, mejor dos opciones para girar, una por código y otra por la plataforma en la que rule.
Es que siguiendo esa regla de tres, casi todo sobra, casi todo se puede hacer en android directamente :D ;)
No puedo dejar la rotación por la forma en que he cambiado el sistema de renderizado en PixTudio para que use la tarjeta gráfica (a través de SDL) en lugar de pintar por software.
Y como lo he quitado, no tiene sentido que deje órdenes en los módulos que luego son ignoradas. Ponte en la perspectiva de una persona que llegara nueva a PixTudio y viera ciertas opciones que no hacen nada. ¿Qué sentido tendría eso?
Lo que sí puedo hacer es una cabecera de "compatibilidad" con BennuGD que salve estas cosas y permita compilar (pero el comportamiento cambiará en algunas cosas).
En todo caso, creo que sería incorrecto hacer ésto del lado de PixTudio. Cuando BennuGD lo hizo fue porque había plataformas donde no había soporte nativo para rotar la pantalla, pero era para salvar una carencia de la plataforma que no existe en las plataformas a las que está destinado PixTudio.
no se puede forzar la orientacion? yo he visto juegos que se ponen en una orientacion y por mas que rotes el celular se queda fijo en donde quiere el programa, incluso no es la orientacion estandard...
Estaría bien que se propusiera que orientación usar, date cuen que android normalmente estan en telefonos y tablets, que se usan en vertical y horizontal. Si quisiera hacer un juego en vertical tipo tetris, por ejemplo, deberia haber una ''formula'' para que no rote la pantalla accidentalmente y lo eche todo a perder
eso ya existe es en la configuracion al crear el apk creo
Ahora mismo la idea es que el usuario fuerce la orientación mediante las propiedades del fichero de metadatos del APK al que enlacé. Ahí se puede especificar qué orientación se quiere para el juego: apaisada o retrato. Cómo es muy sencillo y es el sistema quien rota la pantalla por hardware no tiene sentido que yo vuelva a implementar eso (que lo voy a hacer peor que el sistema).
Eso funciona estupendamente y el juego PixTudio no tiene que hacer nada: siempre que no llame a set_mode para forzar la resolución el juego se ejecutará a la resolución nativa del móvil (en apaisado o en retrato).
Lo que digo es que es posible que alguien pueda querer que el juego pueda funcionar de ambas formas, al igual que casi todas las aplicaciones que no son juegos (imaginad que cuando el móvil está en apaisado muestra el juego propiamente dicho y cuando está en retrato muestra un mapa, por ejemplo). Eso no se soporta ahora mismo y quizás podría ser interesante
Para mi proyecto se programa en apaisado y tiene la resolución fija set_mode 480p de definición, se auto ajusta el ancho dependiendo de la regla de tres:( ancho original/alto original)*480=ancho escaladao para set_mode, con esto prevengo de las barras negras...
Funciona muy bien,lo tengo bastante controlado.
Solo me queda que pueda rotar la pantalla 180° mediante sensor. O es 0° / 180°
Es muy simple, hay juegos que usan esa técnica
Aun así puedo simularlo gracias a esta app de rotación forzosa.
Modo landscape(auto)
https://play.google.com/store/apps/details?id=com.googlecode.eyesfree.setorientation
Realmente funciona el invento.
Quote from: alicesimu on November 28, 2016, 10:23:08 AM
Para mi proyecto se programa en apaisado y tiene la resolución fija set_mode 480p de definición, se auto ajusta el ancho dependiendo de la regla de tres:( ancho original/alto original)*480=ancho escaladao para set_mode, con esto prevengo de las barras negras...
Funciona muy bien,lo tengo bastante controlado.
Solo me queda que pueda rotar la pantalla 180° mediante sensor. O es 0° / 180°
Es muy simple, hay juegos que usan esa técnica
Aun así puedo simularlo gracias a esta app de rotación forzosa.
Modo landscape(auto)
https://play.google.com/store/apps/details?id=com.googlecode.eyesfree.setorientation
Realmente funciona el invento.
Ponme, por favor, un bug en bitbucket y miro cómo de posible es implementar ésto de forma nativa en PixTudio.
Lo contrario de apaisado es inhiesto o enhiesto
:emoticon guiño:
Quote from: Futu-block on November 28, 2016, 11:35:57 AM
Lo contrario de apaisado es inhiesto o enhiesto
:emoticon guiño:
No tenía ni puñetera idea de cómo se decía y me negaba a usar "vertical", mil gracias :)
Por cierto, alicesimu: creo que te había entendido mal. Pensaba que querías cambiar de modo apaisado a enhiesto al rotar el móvil.
Si lo que quieres es que el juego se muestra apaisado siempre, pero en la orientación adecuada sólo tienes que cambiar el fichero AndroidManifest.xml para que donde pone:
<activity android:name="MyGame"
android:label="@string/app_name"
android:screenOrientation="landscape">ponga:
<activity android:name="MyGame"
android:label="@string/app_name"
android:screenOrientation="sensorLandscape">Lo he cambiado en el git, que parece que es más sensato que lo que había hasta ahora.
Quote from: josebita on November 28, 2016, 12:22:51 PM
Quote from: Futu-block on November 28, 2016, 11:35:57 AM
Lo contrario de apaisado es inhiesto o enhiesto
:emoticon guiño:
No tenía ni puñetera idea de cómo se decía y me negaba a usar "vertical", mil gracias :)
domo arigato gozaimashita, senpai
Quote from: josebita on November 28, 2016, 12:22:51 PM
Por cierto, alicesimu: creo que te había entendido mal. Pensaba que querías cambiar de modo apaisado a enhiesto al rotar el móvil.
Si lo que quieres es que el juego se muestra apaisado siempre, pero en la orientación adecuada sólo tienes que cambiar el fichero AndroidManifest.xml para que donde pone:
<activity android:name="MyGame"
android:label="@string/app_name"
android:screenOrientation="landscape">
ponga:
<activity android:name="MyGame"
android:label="@string/app_name"
android:screenOrientation="sensorLandscape">
Lo he cambiado en el git, que parece que es más sensato que lo que había hasta ahora.
Oooohhh graciaaasd!!!!
Es justo la necesidad que buscaba para mi proyecto
SensorLandscape.
Es eso!
Tenía la duda si se tenia que programar dentro del prg (como el mod_ext de android), o si formaba parte del apk y todo los ficheros que tiene dentro...
Pues si he sabido del fichero AndroidManifiest.XML
Para personalizar detalles sobre la app, además de añadir servicios como admod, google juegos...etc.
Y vi el parametro de la pantalla Landscape, pero no se me ocurrió buscar info sobre dicho parametro jejjeje
Pero no tengo experiencia como programar android.
Pero si soy capaz de retocar pequeñas cosas, pero siempre que tenga información sobre ello.
Hala, pues todo está bien.
Remplaze el parametro de landscape por el sensorLandscape
Dentro del AndroidManifest.xml
Que esta dentro de la ruta de mi proyecto,/juego/PixtudioExport_Juego/Android/AndroidManifest.xml
También dentro hay otro AndroidManifest.xml
En la carpeta /bin/
Lo puse los dos ficheros iguales el atributo.
Pero cuando exporto el apk con el packator...
Si crea el apk con normalidad, a excepción de que me machaca los datos del AndroidManifiest
Y por ende dentro del apk no tiene aplicada el atributo
Voto de que lo copia del android_teample dentro de pixtudio/pack/android_temple...
Donde debo aplicar el atributo, para que no se me borre por el original Landscape?
Y me genere el apk con la modificación correcta
Pues no lo sé... La herramienta para evitar que uses debería darte la opción. O puedes probar a empaquetar a mano, ejecutando "ant debug install".
Entonces, si no he entendido mal, en Android no se recomienda usar SET_MODE para cambiar la resolución, y para saber si se está en apaisado o en "portarretrato" (o como se traduzca "portrait" :D) hay que hacer un GRAPHIC_INFO al mapa (0,0) en cada frame, así mismo como para saber la resolución de la máquina ¿no?
Quote from: Drumpi on November 28, 2016, 05:57:45 PM
Entonces, si no he entendido mal, en Android no se recomienda usar SET_MODE para cambiar la resolución, y para saber si se está en apaisado o en "portarretrato" (o como se traduzca "portrait" :D) hay que hacer un GRAPHIC_INFO al mapa (0,0) en cada frame, así mismo como para saber la resolución de la máquina ¿no?
Es la idea, sí, en la medida de lo posible.
Quote from: josebita on November 28, 2016, 06:32:23 PM
Quote from: Drumpi on November 28, 2016, 05:57:45 PM
Entonces, si no he entendido mal, en Android no se recomienda usar SET_MODE para cambiar la resolución, y para saber si se está en apaisado o en "portarretrato" (o como se traduzca "portrait" :D) hay que hacer un GRAPHIC_INFO al mapa (0,0) en cada frame, así mismo como para saber la resolución de la máquina ¿no?
Es la idea, sí, en la medida de lo posible.
Yo discrepo mucho xD
Trabajamos con bitmaps, no con dibujo vectorial. Es difícil hacer un juego para móviles sin usar set_mode :)
Y alicesimu, no está mal preguntar en el foro algunas dudas, pero deberías intentar buscar las soluciones un poco por tu cuenta.
PixTudioPM permite exportar en vertical. Pégale un vistazo a su código y averiguarás cómo lo hace.
https://bitbucket.org/panreyes/pixtudiopm/src/f01b60fd178eb35b7922453c43c34c9691ac7e30/pixtudiopm.au3?at=master&fileviewer=file-view-default
Un saludo
Llámame vaga, pero dudo mucho que pueda programar un bat o lo que sea, para montar un apk firmada con todo lo que conlleva.
No llego a tanto.
Hasta este punto hay que llegar... Para solo cambiar un sencillo atributo de AndroidManifest.xml
Es una locura montarse tu propia linea de comandos, solo para solventar un sencillo problema.
Al packator solo debería añadir un botón check, si quieres que use el sensor. Añadiría sensor delante del Landscape/Portraid.
Quote from: panreyes on November 28, 2016, 06:39:06 PM
Quote from: josebita on November 28, 2016, 06:32:23 PM
Quote from: Drumpi on November 28, 2016, 05:57:45 PM
Entonces, si no he entendido mal, en Android no se recomienda usar SET_MODE para cambiar la resolución, y para saber si se está en apaisado o en "portarretrato" (o como se traduzca "portrait" :D) hay que hacer un GRAPHIC_INFO al mapa (0,0) en cada frame, así mismo como para saber la resolución de la máquina ¿no?
Es la idea, sí, en la medida de lo posible.
Yo discrepo mucho xD
Trabajamos con bitmaps, no con dibujo vectorial. Es difícil hacer un juego para móviles sin usar set_mode :)
La mayoría de juegos, por no decir todos, trabajan con bitmaps. La diferencia está en que, por ejemplo, los que usan Unity, tienen un motor que escala las imágenes (mucho mejor que el que usamos nosotros) y adapta el juego a la pantalla (y creeme, es una pesadilla hacer esos ajustes, incluso el profesor que nos estaba enseñando a manejarlo nos decía que al final era cuestión de ensayo-error).
Además, hacen uso de gráficos de distinto tamaño en función de la resolución. Supongo que lo habrás visto, que existen diversas carpetas con nombres predefinidos según el tamaño de pantalla.
Y no es necesario usar gráficos vectoriales, siempre puedes crear algunos en tiempo de ejecución, y otros se pueden escalar dos veces sin una pérdida significativa de calidad (si son pixelart, puedes escalarlo todo lo que quieras :D). Pero claro, ya hay que tener cierta experiencia en ello, si no, hay que tirar de scale_resolution y bloquear el sensor de posición.
También se puede usar mod_svg y pedir la resolución para crear el bitmap de cada gráfico, así siempre será perfecta, Independiente de cada resolución del juego.
Muy buena idea. Y es más, sólo habría que hacerlo en la primera ejecución: en ese momento se crean, se guardan en FPG en alguna carpeta del usuario (o PNG si hay quien lo prefiere así), y ya lo tienes listo para tu dispositivo por los siglos de los siglos :D
si quieres tener graficos segun la resolucion de pantalla, evitando el escalado de bennugd, tambien puedes hacerlo, es la misma idea que los graficos pre-rotados que viene desde DIV
Sí, escalar los gráficos antes, es lo que he dicho de las carpetas para distintas resoluciones, pero eso tiene la pega de que ocupa mucho espacio, y en Android, cuanto menos se ocupe, mejor, porque los fabricantes de los dispositivos, vale, te dan 4GB u 8GB de espacio interno, pero luego sólo 2GB se destinan a aplicaciones (o menos) y te llenan el 80% con las suyas.
Yo tengo un Xperia U1 (creo que ese era el modelo) y tiene tantas cosas que no necesito preinstaladas, que le he metido 5 apps de menos de 7MB, el Pokemon Go (que encima no funciona) y ya tengo la memoria interna al 85%.
Quote from: Drumpi on November 29, 2016, 02:13:27 PM
Sí, escalar los gráficos antes, es lo que he dicho de las carpetas para distintas resoluciones, pero eso tiene la pega de que ocupa mucho espacio, y en Android, cuanto menos se ocupe, mejor, porque los fabricantes de los dispositivos, vale, te dan 4GB u 8GB de espacio interno, pero luego sólo 2GB se destinan a aplicaciones (o menos) y te llenan el 80% con las suyas.
Yo tengo un Xperia U1 (creo que ese era el modelo) y tiene tantas cosas que no necesito preinstaladas, que le he metido 5 apps de menos de 7MB, el Pokemon Go (que encima no funciona) y ya tengo la memoria interna al 85%.
si, un desastre
Quote from: josebita on November 28, 2016, 04:19:54 PM
Pues no lo sé... La herramienta para evitar que uses debería darte la opción. O puedes probar a empaquetar a mano, ejecutando "ant debug install".
Bueno investigando ficheros...
dentro del JUEGO\Pixtudio_Export_juego\Android\
encontre este BAT: AndroidCreateAPK.bat
y probe a modificar, poner ant debug install
ejecute...
y me creo un APK que termina en debug.apk
me lo instale en el dispositivo android y funciono en sensorLandscape!!!
Volvi a modificar el BAT en modo release
ant release install.
y tambien me funciono!
no me machaco ningun fichero como AndroidManifest.xml y puedo realizar pequeños ajustes en el ahora, como si deseo cambiar el numero de version por ejemplo.
solo crea las nuevas dentro del: bin
Desconozco si el APK esta firmada, con las keys mias...
pero si encontre este BAT: AndroidFirmarAPK.bat