[GC] Juego de accion 2D en desarrollo

Buena suerte con el proyecto.

A nivel grafico supongo que no será mucho, pero puede llegar a ser muy entretenido.

hola, en que lo has hecho? liberarás el código?

Hola KFR esta de puta madre solo te queda recortar un poco al prota y sera un juegazo mantennos informados de como lo llevas por que me encantaria probarlo en mi cubo
Un saludo
Kaltorak.

Hola
Tras estar estudiando programacion (antes solo tenia los conocimientos aprendidos de forma autodidacta) voy a revisar todo el codigo y cambiar muchas cosas, porque antes no sabia usar de forma muy "correcta" los punteros, arrays, etc.. y ahora creo que podre conseguir hacer un codigo mucho mas depuro ademas de solventar algunos problemas.

En cuanto tenga el motor del juego preparado para comenzar a hacer pantallas y demas, liberare el codigo para que quien quiera me ayude a mejorarlo o quien quiera saque su propio juego, siempre que diga de quien era originalmente el codigo fuente.

Gracias

PD: Esta hecho en C con algo de C++ y las librerias viejas de LibOGC por lo que quiero ponerme a mirar como usar las nuevas dado que seguramente me solventarian el problema grafico que se ve en el prota...esos pixels blancos que quedan como el culo

PD2: Y el nivel grafico sera similar al del prota y no al del escenario hecho por codigo directamente, dado que eso solo es para probar el motor de colisiones, gravedad... y ademas, para probar la creacion de graficos de esa forma que es muy trabajosa y no queda mu...currada.

Como mola! Usas esas librerías de VIDEO_GetVideoMode?

Ya hace su tiempito de que empece este proyecto pero por culpa de proyectos y examenes, no me habia vuelto a poner en serio a ello.
Hoy en clase ya que no hacemos ya na de na me he puesto a intentar arreglar el problema que tenia...

El personaje detectaba la colision solo con la primera plataforma y el resto las traspasaba. Tras probar a cambiar una cosa que no parecia muy correcta, de repente si detectaba la colision con todas...menos con la primera xD

Tras comerme el tarro al de 5 minutos me he dado cuenta que si quitaba la parte de codigo relacionada con la deteccion del final de las plataformas (para caerse si se sobrepasa el borde) el prota podia "pisar" todas, con lo que he partido de ahi para arreglar el tema.

Y porfin al de 20 minutos he conseguido que el personaje pueda "pisar" todas las plataformas y que se pueda "caer" de todas ellas tambien.

La cosa entonces ya marcha porque ese el problema que tenia entre manos.

Ahora solome falta depurarlo todo lo mas que pueda o tenga ganas y pulir los disparos, apuntar...

Ire actualizando con informacion.

¿ Se sabe algo nuevo del proyecto ?

Ando haciendo los sprites del prota para ya probar el motor con el "final" o casi, ya que hasta ahora he usado sprites hechos rapidos y de diferentes tamaños, que en el fondo no me ha venido nada mal porque asi he comprobado que no hay problema alguno en meter personajes de muy diferente tamaño.

Puedo subir una captura del prota....en un rato si eso

Aqui va una captura (video 736KB) del proyecto y hoy me he metido a animar al jugador porque se me ha ocurrido hacer que al pulsar X boton el jugador apunte y al volverlo a pulsar, el jugador la baje, habiendo otro boton para disparar...mas realista vamos

http://www.megaupload.com/?d=COKQXECU

Aqui (817KB), tras un dia de trabajo, la animacion de andar ya casi final en la que se nota como se giran y mueven las piernas y brazos del prota aunque la animacion de correr aun esta en desarrollo xD que con la de andar ya me he rayado mucho. El sistema de movimiento del jugador ya casi esta terminado y ahora me voy a meter con los disparos que quiero hacer que al chocar contra una superficie revoten
http://www.megaupload.com/?d=FVH9X25W

Venga que ya casi lo tienes listo, buena suerte

KFR Como vas con el proyecto?

no habras dejado el proyecto de lado, no?

Pues la verdad es que si esta un cuanto de lado por varios motivos y es que ahora ando con visual basic en los estudios y tengo ganas de ponerme de nuevo con C que hay cosas que ya no recuerdo bien....ais....aparte de que teniendo ya practicamente el motor grafico (gravedad, colision con plataformas, disparos, saltos, movimiento...) practicamente terminado, se da el problema de que al ser todos los sprites en formato bmp (el que soportan de forma nativa las librerias gratuitas que hay disponibles) cuando se te ocurre la brillante y evidente idea de poner un fondo de pantalla....no es que se pete el framerate, es que no existe .
Mi idea es hacer uso en mi proyecto de las librerias png que han portado, para hacer uso de ellas con las antes nombradas de GC y asi el tamaño de los graficos, estando igualmente en 24bits, seria muy muy inferior y el framerate no se resentiria....a ver cuando me pongo porque le tengo muchisimas ganas al proyecto y tengo una cantidad de ideas y material/arts del copon pero por el momento no "soltare" nada

PD: Gracias por interesarse por el currito de un eoliano mas

KFR escribió:Mi idea es hacer uso en mi proyecto de las librerias png que han portado, para hacer uso de ellas con las antes nombradas de GC y asi el tamaño de los graficos, estando igualmente en 24bits, seria muy muy inferior y el framerate no se resentiria....a ver cuando me pongo porque le tengo muchisimas ganas al proyecto y tengo una cantidad de ideas y material/arts del copon pero por el momento no "soltare" nada

PD: Gracias por interesarse por el currito de un eoliano mas

plassh!! que es eso? el sonido de tu burbuja rompiendose xD a ver... te voy a comentar una cosa bueno en realidad varias la primera y más importante.... da igual que cargues imagenes en PNG, BMP , FRG o SLM(saulotmalo xD ). En memoria siempre ocupan lo mismo lo único que conseguirás son tiempos de carga seguramente mejores y menos espacio al distribuirlo pero cuando cargas con png lo que haces es que lo pasas a un mapa de bits en memoria así que... mala suerte por ahí no podrás optimizar.

bueno pero a ver... no está todo perdido!!! puedes cargar solamente tiles y así no pierdes tanta memoria. Aún así creo que tu problema no está ahí ya que yo tube que lidiar hace tiempo con el mismo pero en psp.

El problema de dibujar un fondo es que tienes que redibujarlo todo cada vez... y eso cuesta mucho. te recomendaría que te mirases la técnica que he usado yo (está un par de post más abajo) en la cual simplemente pintas los recuadros manchados porque si cada vez repintas toda la escena te cargas el frame rate. Bueno suerte

Oki no sabia que al fin y al cabo terminaria ocupando lo mismo con lo que como bien apuntas, por ahi poca ostia podre optimizar...malo

Ya mirare mañana a ver como lo has hecho tu dado que la idea que propones de "refrescar" unicamente el area "manchada" es tentador y seguramente la forma mas optimizada y a largo e incluso corto plazo, practica.

Gracias

PD: Entonces (es que desconozco este tema dado que todo lo aprendido en cuanto a programacion de juegos es autodidacta...la programacion no dado que es lo que estudio pero temas de graficos, poca ostia se ha tocado) no habria ventaja alguna de usar graficos en png? salvo supongo evidentemente, los tiempos de carga serian inferiores...pero vamos, supongo.

Exactamente, la única ventaja de usar un formato u otro es el tiempo de carga y el tamaño de almacenamiento en disco (realemnte importante si se quiere colgar en la Web o es para plataformas limitadas).

En memoria, ya sean PNGs, BMPs, JPGs o lo que sea lo único que hay es una representación de la imagen. Lo que hacen las librerias para cargar esas imágenes es abrir esos archivos, descomprimirlos (en caso de bmp evidentemente este paso se lo salta) y meter la información de los pixels de la imagen en memoria.

La mejor optimización que puedes hacer: TILES. Redibujar todo el fondo es costoso si, y es una buena optimización para pulir el juego, pero nada comparado a tener en memoria una imagen de ¿5000x500? pixeles y estar redibujandola cada frame a dibujar en cada frame unos 200 pixeles de un tamaño infinitamente menor. Mira que en una GP2X a 250MHz dibujando tiles de 15x15 (que son 352 tiles en cada momento) consigo mas de 80fps redibujandolo todo en cada frame.

Es que en base a los ejemplos que se pueden encontrar por ahi, sobre la programacion homebrew para Gamecube, todos se basan en el redibujado de la pantalla en su totalidad y bueno, si me dices que el juego es un pong o que incluso el fondo se ha dejado en negro (color que se da en cada refresco) pues puede mantenerse un framerate estable pero en cuanto te pones a meter un personaje, plataformas y un fondo cargado (me refiero a muy ancho para el tipico shooter o beat'em up en que se ira haciendo scroll...pues todo a tomar por

Ya mirare a ver como va lo de Tiles que algo ya lei pero hace cosa de un año o asi que tengo el tema de lado. . .ais

Gracias

PD: Y una dudita aparte que igual es la chorrada del siglo pero como no he tenido tiempo para mirarlo pues sigo con la duda...se pueden usar actualmente las librerias SDL en Gamecube/Wii o hay algun proyecto para portarlas?

PD2: kbks tanta optimizacion se consigue de dibujar por tiles a redibujar todo de una, siendo el mismo "tamaño" en si? dado que el trabajo esta digamos repartido es facil deducir que si pero puesto que tienes practica por preguntar

KFR escribió:PD2: kbks tanta optimizacion se consigue de dibujar por tiles a redibujar todo de una, siendo el mismo "tamaño" en si? dado que el trabajo esta digamos repartido es facil deducir que si pero puesto que tienes practica por preguntar

te responderé yo... entre otras cosas la gran ventaja es la cache... al ser tiles caben integramente en caché por lo que no has de acceder a memoria principal y eso es muy bueno para el procesador a la hora de dibujar aún así sigue siendo lento en pantallas muy grandes

Gracias y bueno...la pantalla tampoco sera "enorme" dado que la resulucion a la que trabajare seguramente terminara siendo 640x480 que mediante el rgb de la gc no se ve nada mal...pero aun no lo tengo claro.

Ademas de la cache, con los tiles dibujas solamente los tiles que estan en la pantalla. Si pones una imagen enorme estas trabajando con una cantidad de memoria desorbitada y es la propia librería gráfica la que debe "recortar" la imagen para mostrar solamente lo que se muestra en pantalla. Es decir, no es lo mismo redibujar en cada frame un área (dividida en tiles claro) de 800x600 (en PC, por ejemplo) que una imagen de 5000x600 toda de golpe.