[LUA] Juego de Lucha PSP

PiratePila está baneado por "crearse clones para trollear"
Hola a To2 !

- Pues bien hace unos meses empecé a aprender con LUA y hice ESTO, nada del otro mundo. Fuí aprendiendo gracias a tutoriales pero al final con los estudios y eso deje de mirarme las cosas. Ahora quiero seguir con LUA y me gustaría hacer un juego de pelea en 2D, tipo así:

Imagen

Claro esta que no como ese. Con escenarios mas simples (solo suelo y fondo) y unicamente con dos personajes (Player 1 Vs. CPU).

¿ Lo veis viable ? ¿ Alguien me puede aconsejar algo ? ¿ Sabeis donde encontrar Tutoriales donde expliquen funciones que me hagan falta ?

Me gustaría mucho hacerlo. Si me pudieras hechar una mano con cosas como por ejemplo donde encontrar informacion para hacer el menú y tutoriales donde expliquen variables y opciones que me hagan falta os lo agradecería.

Saludos !
jejeje que curioso.. bueno por una parte ya existe un juego así se llama animayhem está en lua así que el código creo que está liberado con el juego.

Por otro lado yo estoy haciendo un juego de este estilo tambien pero en SDL porque el que te he comentado antes está bastante mal hecho y la verdad soy programador y aún así hay cosas que me cuestan ( aunque claro, queremos que tenga calidad y estamos usando física y queremos que sea escalable). Así que te comento... fácil fácil no es pero se puede hacer :)

pd: joer que putada más competencia xD
PiratePila está baneado por "crearse clones para trollear"
Gracias por tu respuesta saulotmalo.

La verdad es que por ahora no se mucho pero tengo ganas de aprender. Voy a buscar ese juego que dices y ya te diré. Asi con el juego podre ver ejemplos y como montar el menú.
Yo si quieres te puedo ayudar.
pues tanto en lua como en C suppongo que sera un coñazo pero como todo solo es dedicarle tiempo

te dejo algo en Lua

http://beta.pesepe.com/story/bruce-lua

http://beta.pesepe.com/story/super-dragon-ball-z

y este creo que es el mas parecido a lo que buscas

http://beta.pesepe.com/story/xtremebattle


aunque realmente creo que buscas esto hecho en C de hasta 4 players


http://beta.pesepe.com/story/anime-wars



para ello habla con Neo_Ace, yo estare liado un tiempo (creo que Neo tambien asi que paciencia amigo)

Si te interesa, cuando lo hagas puedes añadirlo a "mi juego" http://beta.pesepe.com/story/n2-dragon-ball-portable http://beta.pesepe.com/user/neo-ace
PiratePila está baneado por "crearse clones para trollear"
Gracias a todos por contestar. Ahora cuento con la ayuda de rubensvaldemo.

Mi idea es hacer algo como Bruce LUA pero con sprites y escenarios de mejor calidad.

Si alguien tiene idea de como hacer los sprites que tambien me lo diga. Toda ayuda se agradece. [oki]

De momento voy a ponerme con el menú, a ver si puedo crearlo guapo.
saulotmalo escribió:pd: joer que putada más competencia xD



No te molestes hombre, si voy a ganar el proximo gbax con el comando2 XD
Eskematico escribió:

No te molestes hombre, si voy a ganar el proximo gbax con el comando2 XD



Un concurso extranjero?? tu?? xDDD no me lo creo xD no has visto como te ponen por ahí :P
Por curiosidad...

Veo que te preocupas mucho por lo menús, los sprites y demás, pero no veo que te haya surgido la duda de cómo implementar las peleas. ¿Puedo preguntarte cómo las harías?

Para que entiendas la pregunta, voy a plantearte una opción que yo me estoy planteando para un juego (de PC) y a lo mejor te sirve de idea:

DEFENSA:

Cuando se inicia un movimiento de ataque del contrario debería salir un sprite en su muñeco (una animación) de qué tipo de golpe va a ser: alto, medio o bajo. Tiene que dar tiempo de verlo para que puedas pulsar el botón de guardia a tiempo (recomiendo tres botones directos, uno para guardia alta-triangulo, baja-equis y media-cuadrado).

Si te alcanzan, debería causar más daño el golpe en la cabeza que en el torax y en el torax más daño que en las piernas.

También debería haber un 4 botón, el círculo, que sea una esquiva o salto hacia atrás para evitar los golpes "imparables". Si esquivas ante un golpe normal, deberías recibir una mínima parte de daño y si no esquivas un golpe imparable deberías recibir doble daño a menos que te protejas, que recibirías medio daño.
Si logras esquivar un imparable deberías dar un tiempo extra al que lo ha evitado para que en el siguiente golpe el otro tenga menos posibilidades de detener tu ataque.

ATAQUE

Como he dicho en la defensa, debe haber 4 tipos de ataque (puede haber más combos pero en definitiva 4 tipos, altos, medios, bajos e imparables). La CPU se defenderá aleatoriamente, variando su guardia y encontrando tus huecos para atacarte. Si atacas cuando tiene la guardia alta sobre otro punto de su cuerpo, le alcanzarás. Subiendo la dificultad puedes hacer poses que defiendan dos partes de su cuerpo y que cambie la guardia más a menudo.

Si le alcanzas la cabeza, es un daño crítico, si le alcanzas abajo, un daño mínimo. Recomendaría las flechas de dirección para los ataques (izquierda, arriba y abajo) y el imparable, con L1, por ejemplo.

El stick te serviría para alejarte y salir del espacio de ataque de tu adversario.

Pienso incluir en mi juego una barra de cansancio que serviría para medir bien tus fuerzas. Es decir comienzas con X puntos de golpe. Cada uno es un turno que tienes para atacar. Si atacas todo el rato, vas gastando esos puntos y si llegan a 0 estás tan agotado que no puedes seguir atacando, solo defiendes. Si el enemigo te ataca y tú no, recuperas un punto de fuerza de modo que los que más fuerza tengan tendrán más posibilidades de golpear y de ganar y puedes hacer como un juego de Rol donde vayas incrementando tus fuerzas a lo largo de la aventura y los combates. Además la barra de vida puede crecer, puedes ir mejorando tus ataques (más daño por acierto), mejorar tu agilidad (tienes más tiempo para reaccionar)...

Lo que no tengo muy claro es qué hacer cuando los dos atacan al mismo tiempo. Creo que lo mejor es provocar un choque de espadas o las armas que sean y dejar un segundo aturdidos a ambos sin poder atacar o defender. Si no consigues atacar pasado medio segundo del inicio del ataque contrario, recibes el golpe o bien dejaría medio segundo de reacción para poder detener el golpe.

Otra opción es que cuando uno empiece el ataque, suene un gemido del que lo va a recibir avisando así que o se defiende o va a sufrir.


En fin, esa es mi idea de combate. ¿Qué piensas hacer tú?
a ver en mi caso lo he planteado de una forma totalmente distinta ( que no ni mejor ni peor) de hecho hoy mismo le he dedicado unas 6-7 horas en infraestrucctura... aún estamos recreando animaciones hemos llegado a la conclusión que uno de los apartados más complicados será que tu personaje haga lo que tiene que hacer en cada momento. Por lo tanto hemos creado un conjunto de estados que representan el estado. En cada estado cada personaje podrá hacer unas acciones diferentes algunos podrán pegar en el aire, otros no otros podrán pegar y variar su estado... cosas así... creo que para un juego tipo Jump esta apreciación es mejor.

Me gusta la idea de tu barra de cansancio como luchador "real" de taekwondo sé que en una pelea el cansancio es uno de tus peores enemigos por lo que te felicito por la idea :).

Más cosas notros nos hemos centrado mucho en la implementación de una física propia para cada personaje así ciertos personajes serán más fuerte y de una ostia te podrán tirar más lejos... o... correran más o tardarán más en frenar o podrán dar saltos más altos NADA está precalculado y de momento todo va relativamente bien :).

Un juego de este estilo no tiene porque ser fácil y yo te digo me está dando muchos problemas asociar las diferentes entradas de teclado con las animaciones para que sean totalmente genéricas y cargadas desde fichero... esto lo quiero para poder crear más personajes sin tener que recompilar ni meter líneas de código.


bueno espero haber ayudado resumiendo un poco mi proyecto....


PD: se buscan diseñadores a nivel de pixel para el mismo ;) nada de si encuentro no usaremos sprites ripeados...
PiratePila está baneado por "crearse clones para trollear"
tonyjfc y saulotmalo, la verdad es que eso casi no lo habia pensado. He pensado que cada personaje tiene que tener 1 tecnica propia, pero nada mas. Quería crear primero la estructura del juego (menús, opciones, etc.) y después pensar en lo de las peleas.

Gracias por las ideas y por vuestra ayuda. Se agradece. Si teneis algo mas que decirme os lo agradecería. ;)

Tambien darle las gracias a rubensvaldemo, que me ha ayudado con el menú y ya lo tengo casi listo, lastima que no empezará con el proyecto en vacaciones. [+risas]

Pues eso, me gustan mucho vuestras ideas, de LUA tengo idea pero hay muchas variables y demas que desconozco, así que toda ayuda me vendra bien.

Y sobre las peleas, el sistema de lucha como bien deciis es importante y me centrare en ello pero tambien (como ya dije) me gustaria que fueran de buena calidad igual que los fondos. Ya que eso siempre queda bien y, personalmente me gustaría que los personajes fueran lo mas fieles posibles a la serie.
Una cosa que ubiese sido importante es empezar por las batallas que es el centro del juego!!! los menús es lo último y seguramente los acabes cambiando porque aprendas nuevas técnicas y los quieras animar o quieras liberar memoria... ya que si... la memoria en PSP no sobra así que la mínima para los menus ( es mi punto de vista otro podría pensar de otra manera ).

Cuando empieces con el sistema de lucha si tienes algún probelma con los algoritmos y tal puedes comentarnos a nosotros ya que como ya hemos pasado por las situaciones duras te podemos ayudar ( en mi caso lo he pasado ciertamente mal porque he creado un wrapper para SDL)

En fin suerte y al toro!!! yo no espero tener el mio apto para que se esté pegado hasta al menos a finales de diciembre... así que tomate las cosas con calmal
PiratePila está baneado por "crearse clones para trollear"
El problema es que para empezar con las batallas tengo que tener los sprites de los personajes y no los tengo al igual que los fondos. Por eso me centraba en el menú ahora.

Una cosa, sabeis como puedo hacer para que se ve como las linias de un rectangulo rojo y caigan justo encima de las opciones ?

No se si me explico bien.
la memoria en PSP no sobra


Si con 32 MB de RAM, 2 MB de VRAM y compresión de texturas por hard no te sobra...

La GBA tiene 32 MB como límite para la memoria del cartucho, 256 KB de RAM y 96 KB de VRAM, y para un juego de lucha 2D sobra por todas partes.
los juegos de advance pueden gastar la memoria propia del cartucho para almacenar imagenes aviertas y luego copiarlas .... así que en psp ese espacio lo tenemos en la llamada ram y luego de memoria real la vram.

vamos... o eso tengo entendido... por cierto preguntarle a eskema si sobra o no sobra xD
Recuerda que la RAM de la PSP es igual de grande que la máxima cantidad de memoria disponible en un cartucho de GBA. Si la PSP tiene potencia para emular una GBA, puede cargar imágenes desde RAM con una velocidad igual o mayor que la portátil de Nintendo.

La idea está en cargar en RAM imágenes comprimidas de 256 colores (o 16 si es posible) y tener en la VRAM sólo lo que se muestre en pantalla. De esta forma incluso con menos de 1 MB de RAM tienes para mostrar en pantalla lo que te apetezca.
a ver si eso yo lo sé... pero es fácil llegar al techo aún así!!! te lo creas o no es simplemente una cuestión de aritmética supongamos que queremos tener personajes de 100x100 pixeles en pantalla ( relativamente pequeños) con una profundidad de color de 256 colores por componente 8(bits) y 3 componentes( sin canal alfa) y que el personaje tenga 256 animaciones... de las cuales 8 para el movimiento 8 para el salto 8 para el ataque esto sería

100*100*8*3*256= 61 440 000 bits

7 680 000 bytes

7,3242185 Mbytes !!!! Eso sólo un personaje!!!!! si metes 4 personajes en la misma pantalla a la vez ya no cabría .... la solucion reducir animaciones por ejemplo... porque es uno de los factores que más influye en la memoria en mi caso aún no se si llegaré a gastar tantas animaciones como he dicho pero ten en cuenta que tienes que tener las de la derecha y las de la izquierda si no quieres perder tiempo de procesado girando la imagen en tiempo real...
Creo que estás haciendo mal los cálculos. En las imágenes paletizadas se guardan por un lado la paleta y por otro lado la imagen, apuntando los píxeles de la imagen a los colores almacenados en la paleta:

Paleta: numColores * componentes * bitsPorComponente = 256 * 3 * 8 = 6144 bits = 768 bytes.
Imagen: imágenes * ancho * alto * punteroAPosiciónPaleta = 256 * 100 * 100 * 8 = 20480000 bits = 2560000 bytes.

Así que cada personaje debería ocupar en RAM 2560768 bytes = 2.44 MB. Además, si guardas los sprites con 16 colores en vez de con 256, el personaje ocupa la mitad, pudiendo meter en la RAM de la PSP hasta 25 personajes distintos. Por otro lado, 256 animaciones por personaje me parece un número excesivo incluso para un proyecto comercial.

http://sdb.drshnaps.com/sheets/Media/Other/JumpSuperstars/GokuFull.png

Tomando como ejemplo el Jump Superstars de la DS, cada personaje ocupa como máximo 64x64 pixels, usa una paleta de 16 colores tiene como mucho unas 128 animaciones. De esta forma, cada personaje ocupa:

Paleta: numColores * bitsPorColor = 16 * 16 = 256 bits = 32 bytes.
Imagen: imágenes * ancho * alto * punteroAPosiciónPaleta = 128 * 64 * 64 * 4 = 2097152 bits = 262144 bytes.

Por tanto, cada personaje ocupa unos 256 KB. Y todo esto sin tener en cuenta que la PSP soporta texturas comprimidas por hardware.
Osea q los graficos a 256 colores ya se ven pobres, ni te digo usar 16 colores, eso estaria bien para la gb o la gba, pero en una psp usar 16 colores...
¿Lo has probado? pq hablar de teoria esta muy bien, pero yo con 256 ya veo un acabado bastante cutre, con 16.......
Eskematico escribió:Osea q los graficos a 256 colores ya se ven pobres, ni te digo usar 16 colores, eso estaria bien para la gb o la gba, pero en una psp usar 16 colores...
¿Lo has probado? pq hablar de teoria esta muy bien, pero yo con 256 ya veo un acabado bastante cutre, con 16.......
Hombre, no se yo donde ves el beneficio de usar sprites de 16 colores en un juego de Game Boy X-D
El set de sprites de Goku puesto arriba está a 16 colores.

http://sdb.drshnaps.com/sheets/Misc/Misc/NamcoXCapcom/Ryu.png
Un set de sprites de Ryu a 16 colores usado en el juego Namco X Capcom de la PS2.

http://sdb.drshnaps.com/sheets/Capcom/Other/StreetFighter/SFA3/RyuSFA3.gif
Otro set de sprites de Ryu a 16 colores, esta vez del juego Street Fighter Alpha 3, portado a la PSP.

http://sdb.drshnaps.com/sheets/Capcom/Other/Darkstalkers/Demitri.png
Y un set de sprites de Demitri a 16 colores, del juego Darkstalkers. Este juego también ha sido portado a la PSP.

De hecho, creo que lo difícil es encontrar un juego comercial con sprites de más de 16 colores. Y en PSP los colores se deberían ver igual de bien que en cualquier otra portátil actual.
Por las respuestas q das de librillo de maestro, no parece q hayas probado lo q dices, tu teoria es fantastica, de hecho segun las cuentas de la lechera q estas haciendo, con tan solo los 2 mg de la vram vamos mas q sobrados.
Que lastima no tener tus conocimientos para hacer esa magia tan especial q tu haces con 16 colores, se ven de pm y encima te sobra memoria por todos los sitios, yo de mayor quiero ser como tu [sati]
Chano Marrano escribió:Creo que estás haciendo mal los cálculos. En las imágenes paletizadas se guardan por un lado la paleta y por otro lado la imagen, apuntando los píxeles de la imagen a los colores almacenados en la paleta:

Paleta: numColores * componentes * bitsPorComponente = 256 * 3 * 8 = 6144 bits = 768 bytes.
Imagen: imágenes * ancho * alto * punteroAPosiciónPaleta = 256 * 100 * 100 * 8 = 20480000 bits = 2560000 bytes.

Así que cada personaje debería ocupar en RAM 2560768 bytes = 2.44 MB. Además, si guardas los sprites con 16 colores en vez de con 256, el personaje ocupa la mitad, pudiendo meter en la RAM de la PSP hasta 25 personajes distintos. Por otro lado, 256 animaciones por personaje me parece un número excesivo incluso para un proyecto comercial.

http://sdb.drshnaps.com/sheets/Media/Other/JumpSuperstars/GokuFull.png

Tomando como ejemplo el Jump Superstars de la DS, cada personaje ocupa como máximo 64x64 pixels, usa una paleta de 16 colores tiene como mucho unas 128 animaciones. De esta forma, cada personaje ocupa:

Paleta: numColores * bitsPorColor = 16 * 16 = 256 bits = 32 bytes.
Imagen: imágenes * ancho * alto * punteroAPosiciónPaleta = 128 * 64 * 64 * 4 = 2097152 bits = 262144 bytes.

Por tanto, cada personaje ocupa unos 256 KB. Y todo esto sin tener en cuenta que la PSP soporta texturas comprimidas por hardware.


Eso es e el caso de que se use una paleta de colores!! pero si no se usa? que es en la mayoría de homebrew... en mi caso gasto SDL la cual NO usa una paleta de colores por lo tanto al menos para SDL, LUA y todo lo que pongas cargarImagen("nombreimagen") se suele gastar la imagen sin paleta de colores por eso ocupa tanto.
PiratePila está baneado por "crearse clones para trollear"
Veo que os estais desencaminando y me estais llevando el hilo al lado oscuro. XD

No me importa que discutais aquí, es broma. ;)

Pero ahora que estamos en el tema... ¿ Alguien se anima a ayudarme con los sprites ? Hay que hacer los personajes de la serie. Aunque son menos de diez.

Si os soy sincero de sprites no tengo ni idea, necesito un maestro y un ayudante. Aprendo rapido. XD

EDITO: Me encantara ver en mi proyecto sprites de este tipo:

http://sdb.drshnaps.com/sheets/Misc/Misc/NamcoXCapcom/Ryu.png

Es genial.
Siento mucho no poder hacer una demo ya que ni tengo una PSP ni he trabajado nunca con la librería SDL. De todas formas no entiendo qué problema puede haber en usar sólo sprites de 16 colores.

Ahora mismo estoy haciendo un sistema de batalla para la GBA, y todos los sprites que uso son de 16 colores, tanto los que hago yo como los que provienen de otros juegos. Ahora mismo el juego muestra 5 personajes distintos de 64x64 pixels, 5 sombras de 64x32 y un montón de marcadores en pantalla. La GBA sólo tiene 32 KB de VRAM para sprites, y aún así sobra bastante.

Imagen
En esta imagen todos los gráficos menos el fondo están formados por sprites de 16 colores.

Pensad por ejemplo en el Street Fighter Alpha 3 de la PS1, que tiene 2 MB de RAM y 1 MB de VRAM. Si un personaje ocupara tanta memoria como decís, sería imposible ejecutar el juego sin acceder al CD durante las batallas.

La idea es que en la VRAM sólo se cargue lo que se muestra en pantalla, mientras que en memoria principal se almacenen todos los gráficos, como si fuera una caché. Y si 16 colores por sprite se quedan cortos, no debería haber problema en usar 2 imágenes de 16 colores o directamente imágenes de 256. Con las 32 MB de RAM de la PSP debería sobrar espacio.

Eso es e el caso de que se use una paleta de colores!! pero si no se usa? que es en la mayoría de homebrew... en mi caso gasto SDL la cual NO usa una paleta de colores por lo tanto al menos para SDL, LUA y todo lo que pongas cargarImagen("nombreimagen") se suele gastar la imagen sin paleta de colores por eso ocupa tanto.


Está claro que en la VRAM la imagen se va a guardar en la profundidad de color que soporte el hardware (supongo que en la PSP será de 24 bits), aunque la imagen en RAM o en disco tenga una profundidad inferior. Por eso insisto en cargar en la VRAM sólo lo que se muestre en pantalla.

En SDL se puede trabajar con paletas de 8 bit mediante las funciones SDL_SetPalette y se pueden cargar imágenes de 256 colores desde la RAM mediante SDL_CreateRGBSurfaceFrom.

PiratePila, perdón por el offtopic.
mira en la imagen que has mostrado... la verdad es que... XD deja mucho que desear además de que la imagen de sombra ya que es la misma solo se debe de cargar una vez igual que la de hablar y eso... pero el problema está en que en la gba, corrigeme si me equivoco, la memoria del cartucho es como una memoria ram pero en la PSP la memoria ram es ram y la vram vram... seguramente estarás gastando una API o trabajarás directamente con el hardware de GBA pero en nuestro caso queremos que los juegos sean facilemente portables para eso usamos una capa de abstracción la SDL ( que no abstrae mucho la verdad )... pero bueno el caso es que SDL guarda las imagenes de una determinada manera... sin gastar paletas ni nada así que sería función del programador generar el escenario con tiles y scroll para gastar menos memoria.

por lo que dice PiratePila yo he estado buscando tambien diseñadores y he encontrado alguno pero además tengo pensado gastar los sprites del animayhem... si quieres puedes gastarlos tambien supongo xD si no se enfadan los creadores
PiratePila está baneado por "crearse clones para trollear"
saulotmalo escribió:por lo que dice PiratePila yo he estado buscando tambien diseñadores y he encontrado alguno pero además tengo pensado gastar los sprites del animayhem... si quieres puedes gastarlos tambien supongo xD si no se enfadan los creadores


¿ Que sprites son esos ?

Aclaramelo por que no entiendo lo que quieres decir. XD
mira en la imagen que has mostrado... la verdad es que... deja mucho que desear

Lo sé [decaio]. No soy ningún grafista profesional ni mucho menos :Ð. Pero la ponía como ejemplo de que trabajar con sprites de 16 colores no es tan difícil. Si un patán haciendo sprites como yo puede hacerlo, no creo que alguien que entienda un poco tenga mayores problemas.

la gba, corrigeme si me equivoco, la memoria del cartucho es como una memoria ram pero en la PSP la memoria ram es ram y la vram vram

La RAM de la PSP es igual de grande que el máximo espacio disponible en un cartucho de GBA, y tiene una velocidad de acceso mucho mayor. Si la PSP si puede emular una GBA, ¿por qué no va a poder mostrar los mismos gráficos con la misma o mayor velocidad?

el caso es que SDL guarda las imagenes de una determinada manera... sin gastar paletas ni nada

Mediante SDL_CreateRGBSurfaceFrom puedes establecer el formato que te apetezca para las imágenes. Y si estableces que las imágenes sean de 256 colores se crea una paleta de colores asociada a la imagen. La duda que tengo ahora mismo es si SDL soporta imágenes de 16 colores.
PiratePila escribió:
¿ Que sprites son esos ?

Aclaramelo por que no entiendo lo que quieres decir. XD


es un juego que salió para psp homebrew tiene las imagenes en el conjunto que reparten y tal...


chano voy a postear en un foro donde se guardan las imagenes tengo curiosidad yo creo que siempre están en ram y se meten en vram al blitear... pero me estás haciendo dudar
PiratePila está baneado por "crearse clones para trollear"
saulotmalo escribió:es un juego que salió para psp homebrew tiene las imagenes en el conjunto que reparten y tal...


Sigo sin entenderte macho. ¿ Es un homebrew de PSP que te permite crear sprites ?
es un juego de lucha, oks? lo que pasa que usa sprites ripeados... así que yo he pensado en usar los mismos que el ha usado ya que los tiene en una carpeta y tal, ok?
PiratePila está baneado por "crearse clones para trollear"
Vale, pero a mi no me sirven ya que quiero hacer personajes concretos de la serie Fate/stay night.

Si alguien me puede ayudar a hacerlos que lo diga. ;)
Precisamente los sprites que usa el juego Animayhem son de 16 colores, aunque en la carpeta están guardados en formato PNG.

El archivo adjunto contiene los sprites de Naruto en formato BMP de 16 colores. Los 73 sprites ocupan menos de 90 KB:

Adjuntos

Chano Marrano escribió:Precisamente los sprites que usa el juego Animayhem son de 16 colores, aunque en la carpeta están guardados en formato PNG.

El archivo adjunto contiene los sprites de Naruto en formato BMP de 16 colores:


eso ya lo se es porque estarán paletizados en nds pero ahora explicale a la SDL que es de 16 colores.. además para que el blit sea rápido es mejor transformarlo a la profundidad de la pantalla (aunque esto se puede hacer al vuelo para ahorrar memoria )
Si pones las imágenes a 256 colores ocupan unos 232 KB. SDL sí que soporta imágenes de 256 colores de forma nativa, por lo que te evitas problemas y sigue habiendo espacio de sobra.
pero el problema es que tengo que decidir si tener más memoria o más tiempo de cálculo, eso lo entiendes? a no ser que cree la superficie de pantalla tambien a 256 pero entonces si quiero tener imagenes con más resolución de colores ( las realizadas por mis diseñadores) ya no puedo... en fin es una putada por cualquier lado, está claro que hay trucos para reducir el tamaño pero memoria no sobra.
¿Estás seguro de que no se pueden usar imágenes de 256 colores en una superficie de pantalla de mayor profundidad de color sin pérdida de rendimiento?

Estaría de miedo que crearas un ejemplo rápido en el que se midan los tiempos de carga de la misma imagen en profundidad de color de 24 bits y luego de 8 bits. Supongo que la función SDL_LoadBMP soporta los dos tipos de imágenes, aunque como nunca he trabajado con SDL no puedo estar seguro de si se puede hacer o de si supone una pérdida de rendimiento.
a ver si puedo esta noche y hago un ejemplo y así salimos de dudas, mi teoría es que se perderá un tiempo transformando la superficie.

un saludo
He hecho un pequeño benchmark para demostrar que el uso de imágenes de 256 colores en fondos de pantalla de 24 bits con SDL no afecta demasiado al rendimiento. SDL también soporta la carga de imágenes de 16 colores, pero su carga es demasiado lenta.

La demo consiste en pegar en la pantalla imágenes de distinta profundidad de color varias veces y medir el tiempo transcurrido con la función SDL_GetTicks. El código debería compilar sin problemas en la última versión de Dev-C++. Los resultados obtenidos en un AMD 64 3800+ X2 en modo software y en modo ventana son los siguientes:

Imágenes de 16 colores: 24488
Imágenes de 256 colores: 7602
Imágenes de 24 bits: 6581

Según los resultados, sólo hay un 15 por ciento de pérdida de rendimiento al usar imágenes de 256 colores. Saulotmalo, a ver si puedes probar el ejemplo en PSP para salir de dudas:

Adjuntos

PiratePila está baneado por "crearse clones para trollear"
Me parece que estais discutiendo por algo sin mucha importancia. He visto los sprites de NDS pero yo no quería darle ese enfoque al juego, así a lo "Jump Super Star" si no mas bien a lo Street Fighter. A ver si consigo que alguien me heche una mano haciendo sprites. Mañana y todo este fin de semana me pondre a leer tutoriales, a ver si puedo hacer algun sprites ya. XD
cuando usamos una superficie de 16 bits todos son penalizados y contra mayor profundidad mayor penalización:

Imagen de 16 colores Tiempo usado: 430059
Imagen de 256 colores Tiempo usado: 470349
Imagen de 24 bits Tiempo usado: 1172591

cuando usamos una de 8 bits:

Imagen de 16 colores Tiempo usado: 812720
Imagen de 256 colores Tiempo usado: 592069
Imagen de 24 bits Tiempo usado: 1313851


el codigo usado ha sido :

#include <pspkernel.h>

#include <pspdebug.h>

#include <pspctrl.h>

#include <pspdisplay.h>

#include <psppower.h>

#include <psprtc.h>

#include <png.h>

#include <SDL.h>

#include <stdlib.h>

#include <stdio.h>

#include <time.h>

#include <string>

#include <list>

#include <iostream>

#include <fstream>
//malo
#include <SDL.h>

#define IMG_4BIT 0
#define IMG_8BIT 1
#define IMG_24BIT 2


PSP_MODULE_INFO("Test", 0, 1, 1);

PSP_MAIN_THREAD_ATTR(THREAD_ATTR_USER | THREAD_ATTR_VFPU);

static bool isrunning = true;

static int curWindow = 1;

int exit_callback(int arg1, int arg2, void *common) {

   isrunning = false;

   sceKernelExitGame();

   return 0;

}



// Callback thread

int CallbackThread(SceSize args, void *argp) {

   int cbid;

   

   cbid = sceKernelCreateCallback("Exit Callback", exit_callback, NULL);

   sceKernelRegisterExitCallback(cbid);

   

   sceKernelSleepThreadCB();

   

   return 0;

}



// Sets up the callback thread and returns its thread id

int SetupCallbacks(void) {

   int thid = 0;

   

   thid = sceKernelCreateThread("update_thread", CallbackThread, 0x11, 0xFA0, 0, 0);

   if(thid >= 0)

   {

      sceKernelStartThread(thid, 0, 0);

   }

   

   return thid;

}


int bench(int profundidadBmp, unsigned int bucles, SDL_Surface *pantalla, FILE *fichero)
{
    int i;
    Uint32 inicio, fin;
   
    SDL_Surface *bmp, *imagen;
    SDL_Rect dstrect;
   
    // Inicializar el contador:
    inicio = SDL_GetTicks();
   
     // Ejecutar el número de bucles indicados por la variable bucles:
    for(i = 0; i < bucles; i++)
    {
        // Cargar el BMP:
        if(profundidadBmp == IMG_4BIT)
            bmp = SDL_LoadBMP("imagen4.bmp");
        else if(profundidadBmp == IMG_8BIT)
            bmp = SDL_LoadBMP("imagen8.bmp");
        else if(profundidadBmp == IMG_24BIT)
            bmp = SDL_LoadBMP("imagen24.bmp");
        else
        {
           fprintf(stderr, "Profundidad de BMP desconocida.\n");
           return 1;
        }
       
        if (bmp == NULL)
        {
           fprintf(stderr, "Problema: %s\n", SDL_GetError());
           return 1;
        }
   
        // Convertir la imagen al formato de la pantalla:
        imagen = SDL_DisplayFormat(bmp);
        SDL_FreeSurface(bmp);
        if(imagen == NULL)
        {
           fprintf(stderr, "Problema: %s\n", SDL_GetError());
           return 1;
        }
   
        // Pegar la imagen en pantalla:
        dstrect.x = i % 480;
        dstrect.y = i % 272;
        dstrect.w = imagen->w;
        dstrect.h = imagen->h;
        if(SDL_BlitSurface(imagen, NULL, pantalla, &dstrect) < 0)
        {
           SDL_FreeSurface(imagen);
           fprintf(stderr, "Problema: %s\n", SDL_GetError());
           return 1;
        }
        SDL_FreeSurface(imagen);
   
        // Actualizar la pantalla:
        SDL_UpdateRects(pantalla, 1, &dstrect);
    }
   
    // Finalizar el contador:
    fin = SDL_GetTicks();
   
    // Imprimir el resultado en el fichero resultado.txt:
    fprintf(fichero, "Tiempo usado: %d\n", fin - inicio);
   
    return 0;
}

int main(int argc, char *argv[])
{
    int error;
    SDL_Surface *pantalla;
    FILE *fichero;

    // Inicializar SDL:
    if(SDL_Init(SDL_INIT_VIDEO) < 0)
    {
       fprintf(stderr, "Problema: %s\n", SDL_GetError());
       return 1;
    }

    // Inicializar el modo de video:
    pantalla = SDL_SetVideoMode(480, 272, 8, SDL_SWSURFACE);
    if(pantalla == NULL)
    {
       fprintf(stderr, "Problema: %s\n", SDL_GetError());
       return 1;
    }
   
    pspDebugScreenInit();

    SetupCallbacks();
   
    // Crear el fichero resultado.txt:
    fichero = fopen("resultado.txt", "w");
   
    // Ejecutar el bench:
    fprintf(fichero, "Imagen de 16 colores      ");
    error = bench(IMG_4BIT, 5000, pantalla, fichero);
    if(error)
        return 1;
   
    fprintf(fichero, "Imagen de 256 colores     ");
    error = bench(IMG_8BIT, 5000, pantalla, fichero);
    if(error)
        return 1;
       
    fprintf(fichero, "Imagen de 24 bits         ");
    error = bench(IMG_24BIT, 5000, pantalla, fichero);
    if(error)
        return 1;
             
    // Cerrar el fichero resultado.txt:   
    fclose(fichero);
   
    return 0;
}


41 respuestas