Kennyspirit's Blog

Que profundidad de color estas usando? Si utilizas paleta de 8 bits ocupara mucho menos...

utilizamos paleta 8 bits, ahí está el problema, que no se puede reducir más. Poniéndolo a 16 bits se nos come 2 megas más de ram automáticamente

bueno acabo de pegarle un tijeretazo bastante considerable que lo ha dejado en 512x3200 sin perder calidad de animación. Aunque mucho me temo que tendré que petar algún movimiento para ganar un poco más

a 8 bits por pixel serian:

8*512*3776 = 15466496 bits
entre 8: = 1933312 bytes
entre 1024 dos veces: 1,84375 mb

Cuanto tiene la gp32? 8 mb no? con 8 bits deberia ir perfectamente

Creo que esta bien hecho el calculo no?

Ademas presupongo que es el trozo mas largo de imagen que vais a tener en memoria, no creo que tengais mas colecciones de animaciones asi de grandes xD

no os da con 6mb para el resto del juego?

Yo con el BugaFactor creo que ya voy ocupando unos 20mb o asi, pero como es para gp2x en principio pues no me preocupo mucho xD

Si multiplicas por 8 y luego divides por 8 tienes las mismas Estopero xDD

La cosa es que luego estan los fondos, las musicas, los fx .... si, si solo en sprites se van 2mb.. el tema puede estar chungo.. y no digamos si lo hacen en 16 bits.. entonces ya son 4mb...

Joe y como lo hacian los creadores del metal slug para meter eso en la memoria de la neo-geo? XDDD

Supongo que habra que intentar no tener todos los sprites del personaje en memoria a la vez e ir cargando dinamicamente :S

perfecto el cálculo Estopero. La verdad que no se lo que ocurre, porque en un source que usaba en un proyecto antiguo, de ocupar 4.2 megas en ram pasa a 6.1 (vale, perfecto todo), pero si lo cargo de nuevo para imaginar que hay un enemigo en memoria, ya la GP no lo abre.
Y la versión de source de Eskema con todo mejor estructurado y tal con el prota se come 9 megas y algo... recordemos que la gp tiene sólo 8 así que no cabe ¡y apenas tiene gráficos!
La versión recortada por ahora ocupa 1.56 megas, pero no creo que sea suficiente. Ahora si quito más cosas ya empezará a perder calidad, Eskema ha dicho incluso de flipear los gráficos, y el prota no es simétrico ¡f00ck!, ahi ya sería ocupar la mitad directamente.
Joer si no ocupara tanto el source, no entiendo ni de donde salen esos 6 megas misteriosos...

Algun memory leak? xD, alguna estructura o algo que no esteis definiendo los tipos de la forma "minima" ? como textos, short int en vez de int, ese tipo de cosas. Yo no las tenia en cuenta, hasta que hice la parte del "sistema de particulas" y cuando por cada estructura de particula añadias unos bytes de memoria... se notaba mucho en el consumo la verdad xD

Seguro que se menos que vosotros de C/SDL asi que seguro que lo habeis tenido ya en cuenta

Sobre flipear los graficos... macho, si vais a reducir a la mitad practicamente el consumo de los sprites... yo ni me lo pensaba, de hecho estaba dando por hecho que los flipeabais xDDD. Creo que es innecesario un dibujo distinto segun para donde mire, si te sobrara RAM pues vale, pero no es asi...

bueno Eskema me acaba de decir que se da un tiempo mientras se empolla un libraco del copón para programar mejor, así que mientras él vuelve me toca a mi darle al source (cielos santo, esto se va al garete xD). Seguramente voy a tirar de mi viejo source que consumía menos y voy a limpiarlo, corregirlo y añadirle las funciones básicas, que tengo todo el juego en mente, sólo es ponerme (suerte que pienso cosas sencillas en versión para ceporros programando).
Por ahora no voy a flipear nada, que está dibujado distinto para cada lado y es lo que le da un poco de calidad (son dibujos sencillos de por si como para quitarle más personalidad)

No prometo ya nada de si estará, de cuando estará ... etc, tengo un examen que estudiar y esto no me puede consumir tiempo como para asumir la otra mitad del curro, pero a lo mejro en un par de tardes lo tengo rulando, no lo se todavía.
Ala, voy a darle un poco al source a ver si lo encamino

Pásame a mí algunos gráficos y te doy mi opinión de colega grafista ^^

te agrego al mesanyer y te mando algo cuando me aceptes que es más cómodo que montar archivos .zip y petar bandejas de MPs xD

Pregunta tonta, cargais las cosas dinamicamente o del tiron cuando carga el juego?Ahi podria estar la solucion...

se cargan del tirón, pero es un juego rápido, no creo que sea buena idea meterle cargas y descargas entre movimientos...

yo creo que teneis que echar un revisado al codigo, eso que dices de que con un codigo va y con otro no porque ocupa mucho mas es que hay algo mal en el codigo.

si ocupa 2mb, ocupa 2 mb, con 6mb mas libres, el codigo no deberia ocupar casi nada, salvo que tenga algun error.


PD1. Yo que tu no "recortaba" nada hasta que se revise ese codigo
PD2. Tampoco os emparanoieis con cargas dinamicas, revisar antes el codigo que eso tiene que caber por cojones, y sino se empuja

En serio, no compliqueis innecesariamente el codigo con cargas parciales ni recorteis las animaciones antes de revisar y encontrar el bug que debeis tener en el codigo.

Aiken

El código que ocupa poco es un cutre código de plataformas que me curré hace la tira (umm tengo unos videos en youtube de cuando los enseñé por aquí xD) y que no estaba muy fino. Ásí que Eskema lo pilló, lo separó en archivos y aprovechó funciones del survival y otros proyectos, pero extrañamente ocupa más (también tiene un menú, pero una imagen 320x240 no ocupa 4 megas más). Como por ahí hay algo que no está muy fino y la estructura que sigue el tito Eskema no me convence (me pierdo xDD) he pillado mi antiguo source y le estoy echando unos apaños para mejorarlo por mi cuenta mientras él estudia.
Por ahora he quitado toda la porquería que tenía en el source, le he mejorado unas funciones y ahora me estoy peleando con una animación que no se me quiere reproducir, pero ya tengo enfilado ésto como lo quería , lástima de tener poco tiempo para pelearme con él xD
Ahora me ocupa 5,7 megas de ram en Windows, me tengo que mantener ahí hasta que añada enemigos (en la GP con uno bien completito de 1,5 megas como el prota va que chuta xD)
Por cierto he cambiado todos los int a short int, ya que no uso valores altos, aunque no he notado una bajada de tamaño (incluso ha subido unos kb xDD), auqneu la cosa es que ahora después de todo el meneo se le ve más fluído

lo de los short int puede ser porque creo recordar que la GP32 tenia algo que se llamaba algo parecido a 4-byte aligned, que viene a significar que todo lo que ocupa menos de 4 bytes (los short int supongo que deberia ser la mitad de un int, o sea 2 bytes) lo alinea/redondea a 4 bytes enteros para tener la memoria alineada ... ahora no me preguntes para que sirve tenerla alineada pero supongo que sera mas simple para el micro trabajar con palabras de 4bytes enteras. Curiosamente 4bytes son 32bits que debe ser lo que maneja el micro.

supongo que ahora encima el codigo ocupara mas porque tus short ints se tiene que tomar la molestia de aliearlos.

PD. Como te decia no te compliques en eso, cuantos ints tienes en todo el codigo? 1000 ints? que son 1000x4bytes aprox. = 4KB te vas a ahorrar ?

Aiken

Aiken

PD. cuanto ocupa el binario antes de convertirlo en fxe? creo que es el archivo con extension .elf o quizas el .gxb, cuanto ocupan?

quizas estes leyendo los archivos (tu o las librerias) en buffers temporales (punteros) y luego se
te queda los dos archivos copiados.

Por ejemplo, habia en SDL (lo estas haciendo en SDL?) una funcion que la gente suele usar para
adaptar los colores a la paleta que tenia el pequeño inconveniente de que copia la imagen y la convierte a la paleta, pero te deja la antigua imagen en el puntero antiguo sin borrar (doble memoria) y la tienes que eliminar tu, no recuerdo el nombre de la funcion pero casi todo el mundo la usa asi que lo mismo te suena.


Aiken

si si, usamos esa función. Pero cargamos la imagen en una capa temporal, la pasamos a la profundidad usada en caso que sea diferente, la copiamos en otra capa dándole el colorkey y vaciamos la primera, así que no parece ser eso

A mi me da que todas las librarías que hay cargadas de la SDL de por si ocupan ya lo suyo (SDL SDL_image, SDL_mixer... jour aún no he puesto la ttf, seguramente lo apañe con imágenes porque es tope lenta XD)

Lo de la ram que ocupa lo estoy mirando todo el rato en windows, que en la GP ni idea de cómo mirarlo xD pero bueno, como mínimo da una idea aproximada.

Acabo de compilar la nueva versión para contestar tu pregutna sobre el tamaño:
.fxe =364kb
.elf= 737kb
.gbx=658kb
.map= 140 kb

y el .exe 300kb (ésto ya por curiosidad xD) y 5.757 kb en RAM de windows

Bueno voy a ver si dibujo un poco para la uni y si llego a cierto punto me vuelvo a poner a programar (que la animación de estar cayendo en el aire se me está atragantando xDD)

Kennyspirit, dame un toque por MP si quieres que yo estuve trabajando dos años en juegos Java para móviles y algo se tiene que poder hacer pero necesitaré saber como tenéis montado el asunto. Ya nos pasamos el msn si quieres y hablamos del tema, hay que quemar todas las posibilidades antes de ponerse a reducir animaciones!

Buenas noticias, por culpa del foro me he picado con el juego y acabo de conseguir que empiece a funcionar la animación que me tenía atascado
Muchas gracias saucjedi, cuando necesite que alguien me eche un cable te "emepearé". Creo que lo he dicho por ahí, pero no pienso reducir más animaciones, me he montado unas funciones nuevas que me permiten reusar frames repes en cada animación (y controlar los tiempos individualmente, con lo que las animaciones quedan cojonudas )

¡Ya va perfecto el salto! Éste es un nuevo hito para la historia xD, luego empezaré con los golpes y después enemigos