Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
 

Autor Hilo: TUTORIAL 1985ALTERNATIVO SOBRE PROGRAMACION EN C DE LA GAMEBOY (Leído 52136 veces)

pocket_lucho

  • T-500
  • Mensajes: 1 117
Muchas gracios Marçal! Seguro que es muy util para animar a más gente a subir más cosas! A ver si subo la parte de sram y ya teneis todo lo necesario para hacer un juego completo ;)

kalzakath

  • Visitante
Buenas Pocket, me he estado dando de cabezazos un par de horas intentando mover unos sprites por pantalla mientras hacía un marcador en Background Window, como en el ejemplo 6 del Tutorial. Después he visto el post de Marçal y digo, voy a ver cómo lo resuelve él, y me ocurre lo que adjunto, se ven los sprites pero no se ven los backgrounds.

¿Puede ser que tenga mal configurado el emulador?


EDITO: En casa con W7 me funciona bien, quizá sea problema del W8...
última modificación: 13 Enero 2015, 03:43:12 por kalzakath

anjuel

  • T-70
  • Mensajes: 108
    • The Mojon Twins
Luchooo! gracias por el tuto, gracias a él y al señor na_th_an que me ha echado una mano he podido seguirlo y entenderlo :lol:

Deseando el siguiente capítulow! O0

pocket_lucho

  • T-500
  • Mensajes: 1 117
Muchas gracias tio! La verdad es que programar la maquineta en C es bastante sencillo ;) A ver si saco un rato y añado el capítulo de la sram y fin del tutorial!

Jaji

  • Visitante
una preguntilla, sabeis si hay algun tracker que se acerque mas al sonido GB que el Milky¿?

D_Skywalk

  • T-70
  • Mensajes: 219
El otro día me dio un venazo de ponerme a trastear la gameboy y recordé algún comentario fugaz en fasebonus sobre este tutorial ¡¡ES FANTÁSTICO!! :)

En el vídeo alguno dice que el gbdk funciona igual en linux, pero claro al tener sus añitos en 64bits da problemas. He juntado varios repositorios para hacer una versión de gbdk compatible con la última ubuntu/64bits y la comparto en este paquetito: https://www.dropbox.com/s/jxw9u95xxsbgq4p/gbdk-linux-kit64_1.0.tar.bz2?dl=0

Sólo tenéis que editar el fichero devkit.sh con la ruta donde lo hayáis descomprimido y luego al ejecutarlo tendréis el entorno cargado. A parte he dejado en el primer ejercicio un compile.sh para que lo tengáis de referencia. Por supuesto para los emuladores necesitaréis tener instalado wine.

una preguntilla, sabeis si hay algun tracker que se acerque mas al sonido GB que el Milky¿?
http://www.delek.com.ar/deflemask va perfecto y es multiplataforma :)

Un Saludo y lo dicho, gracias pocket por el currele :D
--
Mi Weblog Personal
http://david.dantoine.org/

D_Skywalk

  • T-70
  • Mensajes: 219
Como en mi convivencia con los compiladores de C retro he visto muchas cosas raras he hecho unas pruebas para ver que tipo de peculiaridades tiene el gbdk...
Estas pruebas que no tienen por que ser concluyentes, pero si ayudan a alguien más pues aquí quedan  O0


Pruebas de tamaño:
Código: [Seleccionar]
  if(level == 0)
    {
          ....
    }
    else if(level == 1)
    {
          ....
    }

a esta estructura:
Código: [Seleccionar]
    switch(level)
    {
        case 0:
                ....
            break;
        case 1:
                ....
            break;
    }
El código generado es 7 bytes menor.

Curioso lo de los bucles, este for ocupa ~19bytes...
Código: [Seleccionar]
for( x = 0; x != 18; x++ )
{
    ....
}
Igual que este while...
Código: [Seleccionar]
x = 0;
while( x != 18)
{
    ....
    x++;
}
Pero un do, while ocupa 2 bytes más :?
Código: [Seleccionar]
x = 0;
do
{
    ....
    x++;
}while( x != 18);
... curioso, no?

Sin embargo, si os valiera empezar desde el valor final...
Código: [Seleccionar]
x = 18;
do
{
    ....
} while(--x);
El código generado es 4 bytes menor

Luego hay que tener cuidado por que no vale para todas las situaciones pero...
Código: [Seleccionar]
if( ScrollXCnt == 8 )
Código: [Seleccionar]
if( ScrollXCnt & 8 )El código generado es 2 bytes menor.

Esto es un clásico pero si el módulo es potencia de dos...
Código: [Seleccionar]
temp = dx % 32;
Código: [Seleccionar]
temp = dx & (32 - 1);El código generado es 10 bytes menor.

Código: [Seleccionar]
#define ANCHO 64
...
dx = dy + dz + 21 + (ANCHO * 18);
Podría parecer lo mismo que...
Código: [Seleccionar]
#define ANCHO 64
...
dx = dy + dz + (21 + (ANCHO * 18));
¡Pues no! este es 8 bytes menor. Asi que intentad agrupar las constantes.

Código: [Seleccionar]
if(dx == 0)
Código: [Seleccionar]
if(!dx)El código generado es 5 bytes menor.


Luego sin diferencias en tamaño, pero quizás pudieran necesitar unas más ciclos que otras son:
Código: [Seleccionar]
dx = dy = 0;
dz++;
...
if ((dx == 1)&&(dy == 2))
...
if (dz < 1)
...
respecto a:
Código: [Seleccionar]
dx = 0;
dy = 0;
dz = dz + 1;
...
if (dx == 1) {
  if (dy == 2) {
...
if(dz != 1) //según la doc esto seria más rápido aunque ocupe lo mismo
...

Estas son las pruebas suyas las conclusiones ;)
última modificación: 08 Junio 2015, 23:11:55 por D_Skywalk
--
Mi Weblog Personal
http://david.dantoine.org/

pocket_lucho

  • T-500
  • Mensajes: 1 117
Muy buenas pruebas! A ver si añado ciertas cosas que he aprendido, como la prioridad de los sprites que es rara de cojones...

anjuel

  • T-70
  • Mensajes: 108
    • The Mojon Twins

kalzakath

  • Visitante
Yo lo tengo parado porque en invierno programé un poquito con un portátil con w8 y no compilaba bien...

Enviado desde mi Amiga 500


jrll

  • Visitante
Yo tengo pensado ponerme en serio con este tutorial cuando termine de refinar mis conocimientos básicos de C.
A ver si ahora con el verano puedo ponerme a mirarlo con tranquilidad y, si no se me hace muy cuesta arriba, lograr hacer algo para la Game Boy.

luckpro

  • T-7T
  • Mensajes: 481
    • Lubiterum
El maravilloso mundo de los compiladores... son raros de cojones jejejeje.

En cualquier caso creo que el hecho de que ocupe menos bytes en memoria no tiene porque significar que vaya más rápido el juego, así que yo trataría de hacer el juego completo y que funcione bien y si no entra en memoria entonces buscaría este tipo de optimizaciones.

Dale caña que estamos ansiosos por ver resultados ;-)

jrll

  • Visitante
Por cierto, pocket_lucho, ¿tienes algún juego en desarrollo para Game Boy actualmente?

doragasu

  • T-600
  • Mensajes: 2 314
  • Si no está roto, ¡yo lo arreglo!
    • Kernel Hacks
No siempre es así, pero normalmente cuando ocupa menos también es más rápido. En muchas arquitecturas hacer los bucles descendentes y acabando en 0 es más rápido porque es más rápido (y ocupa menos espacio) hacer la comparación con 0, que hacerla con cualquier otro valor (utilizas la instrucción de salto condicional dependiendo del flag Z, y te ahorras la comparación con un valor específico). Algunas arquitecturas como el 68000 incluso tienen una instrucción que decrementa un registro y salta según el valor del flag Z.

D_Skywalk

  • T-70
  • Mensajes: 219
En cualquier caso creo que el hecho de que ocupe menos bytes en memoria no tiene porque significar que vaya más rápido el juego
Claro, la idea no es ir contando el byte en cada función que hagas, pero en las que son clave o donde creas que ciertas optimizaciones mejoran el gameplay, saber con que puedes "jugar" ;)

Tirando de media, un algoritmo 10 bytes menor será bastante más rápido que el largo (mismo tipo de bucle, sin unloop).

No siempre es así, pero normalmente cuando ocupa menos también es más rápido. En muchas arquitecturas hacer los bucles descendentes y acabando en 0 es más rápido porque es más rápido (y ocupa menos espacio) hacer la comparación con 0
Recuerdo las cosas raras que hacia el compilador del speccy, en este la que más me ha sorprendido ha sido lo de "!0" vs "x == 0", que haya una diferencia de 5 bytes O_O!

Me gusta optimizar mi C, por que creo que un C bien escrito tampoco está tan lejano a un ASM mediocre como el que pudiera llegar a programar yo XD

Bueno, mientras pocket se anima a seguir, voy a ver que hago con este scroll über optimizado :)
última modificación: 09 Junio 2015, 16:57:04 por D_Skywalk
--
Mi Weblog Personal
http://david.dantoine.org/