[GAME] Unnamed

[Nightwolf]

Bueno, si no funciona Oscar, este finde espero tener un hueco libre, y me pongo con ello. (O mejor, te paso el source y lo compilas si prefieres, que soy muy paco para otros SO)

[TYCO]

Night desde una consola pon:

gemix -smac mijuego.prg

Y te crea "mijuego_mac" ese con la carpeta de DLL de MacOS (que ya las tiene Oscar), la "libfmodex.dylib" y la "libSDL-1.2.0.dylib" y creo que no me dejo ninguna más, todo eso en la de GemixGame.app y sustituyes el archivo Info.plist por el Gemix ha generado que sería el "mijuego-Info.plist".

Resumidamente no tiene mucho más.

[Nightwolf]

ah bien a ver qué sale si es tan secillo, gracias Para linux supongo que sería algo similar. ¿Entonces el ejecutable que se genera es un intérprete pero que es variable según el proyecto?

[SimulatorOne]

Buenas. No estoy nada metido con el MAC, así que no tengo mucha idea, pero... con la nueva versión de Gemix, no basta con copiar un ejecutable de cualquier otro juego, meter el gbc y a correr? ¿No es algo así como en Fenix para correr los juegos en windows/linux?

Holas Night,
creo que es necesario también el ejecutable... aunque el gbc sí sería el mismo.
Aunque, si te digo la verdad, no he probado con un ejecutable mío... pero me da que no funcionaría... de hecho los ejecutable tienen distintos tamaños.

los .exe son todos iguales. y unicamente es para Windows como todos saben.
el GBC es el mas importante y el que cambia de tamaño segun el codigo/datos declarados del juego.

para MAC generara los binarios que sean falta + el GBC.

no me pregunteis sobre MAC por que yo no tengo ni idea

[SimulatorOne]

Sobre que el juego ocupa demasiado... sí hay un archivo grande destro del fpg que forma parte del debug que se puede eliminar. Sin embargo, el suelo, debido a que no usé desde el principio un suelo tileado, sino que era siempre el mismo gráfico para el suelo y luego fue posteriormente cuando decidí poder cambiar las texturas, ya me ví con la necesidad de usar un archivo de imagen muy grande para poder hacer un map_block_copy (o algo así es la función XD) para todo el enorme mapa. Un bitmap de 5000x5000 más o menos, o sino perdería muchísima resolución. Pero bueno, limpiando el gráfico que sobra, se queda el fpg a unos 170 megas. Una cantidad ya bastante aceptable.

Pero bueno, luego está la carpeta de sonidos, que contienen mogollón de sonidos...

si, me imagine que el tamaño de la textura del suelo fuera enorme.
pero no es nada 5000x5000, yo en mi proyecto(el de Rosie) uso un mapa de 15.000 x 1200., ademas x2, uno para el mapa de durezas y otro normal. unos 92MB que pesa el FPG y es la memoria ram que consumira.
es mucho ya eso... tengo que pensar en otra manera de montar el mapa por sectores, aun que sean titles gigantes.

Pues es bueno retirar ese recursoso multimedia que jamas se utilizara en el juego, a la hora de publicar el juego para jugar.
siempre puedes tener una carpeta temporal , como sitio de trabajo, para manipular ficheros y tal, esa carpeta siempre la tendras tu.

ademas puedes comprimir el FPG/MAP ademas de cifrarlos aun asi sabes que en memoria ram consumira esos 100 y picos megas en RAM.

MAP_BLOCK_COPY?? creo que con que uses MAP_PUT/MAP_XPUT/MAP_XXPUT ya tienes mas que suficiente.

Pues al principio, usa NEW_MAP(5000,5000) para crear ese mapa nuevo,vacio para Titlear, no lo tengas en el FPG.
Te ahoras ese mapa en ese FPG... aun asi el resultado es el mismo, tener en memoria ese MAP de 5000x5000.
sea por NEW_MAP o por FPG o hasta por MAP.

[Nightwolf]

Pues sí, ciertamente es buena idea crear el mapa de 5000x5000 con new map. La falta de costumbre de usarlo. Tampoco comprimir, porque así también sé cómo ando de ocupación de memoria. Si comprimir el fpg lo que hace es luego tardar más en cargar el fpg, gemix ya es suficientemente lento en cargar fpg's como para encima meterle la compresión a mi parecer. Al menos hablando para pc. Si total era nada más para el concurso, tampoco es para cifrarlo xDDD

[erkosone]

Lento dices? tu no has programado en javascript con html5 XD.. en LOCAL cargar un ogg tarda como 100 veces mas que Gemix, y una imágen cualquiera como 300 veces mas XD.. no en serio, gemix es bastante rápido en cargar archivos fpg, teniendo en cuenta lo que son, librerías gráficas, lo hace muy rápido, otra cosa es lo que metas en el fpg XD.. que estás loco jeje.. he visto tu fpg del juego y le sobra como el 88% de lo que hay dentro, yo intento ser lo mas cuidadoso posible con eso para ahorrar tiempo, pero tienes gráficos que le sobran como 60% ya que está en negro, y eso deberías hacerlo por código, pero vaya solo es una opinión

[SimulatorOne]

Si, es muy rapido cargar un FPG comprimido(añadiendo la contraseña de seguridad)
Aun que tarde 1segundo o 2 segunos en cargar, un FPG de 95MB(REales) ya que comprimido es un Fichero de 5MB solamente
merece mucho la pena comprimir los recursos FPG/MAP.

Pruebalo

[erkosone]

Acordaos de que por ejemplo Apple dicta que si el juego pesa mas de 20 megaByte´s "descomprimido", y digo descomprimido por que se suben a la app store comprimidos, pues que si pesan mas de 20 megas directamente conectado por 3G ni se va a mostrar como disponible.. solo desde conexión wifi..
No es importante, es importantisimo, tanto el cifrado de los datos como la compresión, dos cosas muy básicas.

[Nightwolf]

Eso, insisto, estará bien en un producto comercial que debes cuidar cada pequeño detalles (y aún así cuántos gráficos se escapan en la versión final que no se usan, ocupando espacio), pero para un minijueguecillo, si veis el fpg tiene muchos gráficos que están ahí por muchos motivos, muchos de ellos incluso por cosas que están desactivados por código, pruebas por hacer, etc. Lo importante es siempre el resultado final. De nada sirve comprimir, limar el fpg... ¿qué sale al final? ¿y lo que sale merece la pena ser jugado? Erkos, me dices que el 88% de los gráficos sobra mirando el fpg... ¿has jugado al juego entero? Html5? JAVA? Por dios, son lo peor de lo peor en cuanto a rendimiento. Compáralo realmente con lo que interesa, como C/C++, ahí es cuando nota la lentitud. en un equipo mediano, y es a lo que me refiero.