Tutorial programacion Megadrive - Basico

Después de leer tutoriales de ensamblador en inglés, este tutorial es... DIOS!

Supongo que será muuuuuuuuuuy complejo, pero no estaría mal aprender a animar un personaje, manejar planos de scroll, sonidos, que cuando haya una cuesta "sonic" no siga recto

Muy bueno. Desde mi humilde posición te animo a que sigas añadiendo capítulos a este tutorial.

Muchas gracias por ésto, no tiene precio así paso a paso y seguro qeu así se anima más gente de la habitual a probar cosillas. ¡Yo desde luego no lo descarto!.

Miles d gracias tio,si la gente que sabe hacer esto, le diera por hacer tutoriales, para los torpes como yo, sería como descubrir el cielo.

Un saludo.

buen trabajo compañero, muchas gracias.

Muchas gracias por poner el tutorial, cuando tenga algo de tiempo me pondré a ello ^^.

Muy buena idea, andaba buscando algo así. Siempre me ha interesado la programación y más de videojuegos, pero siempre que empezaba con algún lenguaje, me desanimaba y lo dejaba por no ver progresos. Ahora mismo estoy metido con C/C++ (principios básicos) en cuanto lo termine (o me desanime) cojo este, por no mezclar cosas. Muchas gracias.

Después de leer tutoriales de ensamblador en inglés, este tutorial es... DIOS!

Gracias, espero poder mejorarlo con el tiempo, y si los manuales de ensamblador, aunque me son utiles porque algo entiendo de ASM, son un coñazo..

Supongo que será muuuuuuuuuuy complejo, pero no estaría mal aprender a animar un personaje, manejar planos de scroll, sonidos, que cuando haya una cuesta "sonic" no siga recto

Pues, pensaba en la segunda parte ir a por planos de scroll, aunque como es un tema un poco mas complejo,tal vez tendria q partirlo en dos tutoriales, pero ahora estoy trabajando en ello.

El problema es que la programacion de scroll es mas compleja, asi que me estoy rompiendo la cabeza para simplificar el codigo al maximo

que cuando haya una cuesta "sonic" no siga recto

Esto si que es complejo, implica trabajar con un array para simular un mapa. No creo que ahora, ponerme a enseñar arrays ayude mucho a los que empiezan.

Pero creo q se puede solventar con lo aprendido hasta ahora, que seria hacer un seguimiento de la posicion del Sonic y si se cumple la condicion, mover el sprite mas arriba o abajo...

por Ejemplo algo asi

if X=>190 and X=<290 then
y++
end if

Si Sonic esta entre las posiciones X=190 y X=290 subir el sprite 1 pixel en direccion Y

Pongo el ejemplo, asi se puede ver de forma mas practica

http://rapidshare.com/files/340764531/4.zip

Aqui el codigo y la imagen para el que lo quiere hacer a mano

Creo que si esto va a crecer mucho deberíamos ponerlo en el wiki. Si theelf me da su permiso puedo hacerlo al llegar a casa, si alguien quiere hacerlo antes pues menos faena

Mil gracias Theelf por compartir tus conocimientos con los demás.
A ver si saco algo de tiempo.

Creo que si esto va a crecer mucho deberíamos ponerlo en el wiki. Si theelf me da su permiso puedo hacerlo al llegar a casa, si alguien quiere hacerlo antes pues menos faena

Por mi sin problemas, yo eso del wiki la verdad que no lo conozco mucho, asi que si lo haces tu mejor que mejor.

Esi si ten en cuenta que de seguro en estos dias, si no me sale trabajo extra en el mundo real ,ire escribiendo bastante mas

Genial el tema. Va para favoritos, y en cuanto tenga un rato en casa me pongo a intentarlo.
Gracias y ánimo para seguir con esto.

Muy interesante, dan ganas de intentarlo a pesar de no tener conocimiento en este tema.

buen tutorial , y solo queria comentar que os leais link del Basic de cabo a rabo, de hecho si llegais a aprender Basic, le trendreis media guerra ganada al Visual Basic

Gracias tio por compartir estos tutos. Como ahora tengo tiempo me pondré a mirar a ver si se puede hacer algun juego interesante. Un juego del Pega seria la ostia xD.

¡Enorme tutorial! A ver si me pongo a probar alguna cosilla. Gracias, compañero

siempre desee algo asi

muchas gracias tio esta genial!!

ahi una nota que se te ha colado aunque se da por hecho que es horizontal

NOTA: X es la resolución vertical, Y es la vertical

jaja, pues si, ya lo he arreglado gracias, y menos mal que este no era un tutorial de 3D o tambien el Z seria vertical... jajaja

A ver si tengo tiempo esta noche, y me pongo con el tutorial del scroll.

Si alguien tiene una mejor idea que el scroll para el segundo tutorial, encantado de escucharlas...!!!

theelf escribió:

Creo que si esto va a crecer mucho deberíamos ponerlo en el wiki. Si theelf me da su permiso puedo hacerlo al llegar a casa, si alguien quiere hacerlo antes pues menos faena

Por mi sin problemas, yo eso del wiki la verdad que no lo conozco mucho, asi que si lo haces tu mejor que mejor.

Esi si ten en cuenta que de seguro en estos dias, si no me sale trabajo extra en el mundo real ,ire escribiendo bastante mas

Bueno, yo no puedo asegurar que pueda hacerlo más o menos a la vez que añades el material, pero intentaré ir metiéndolo. Además, cualquier otro puede añadir lo que haga falta.

Creo que es la mejor idea para ir añadiendo todo si ha de ser más extenso.

Un saludo.

Genial el tutorial! Un gran aporte.

Saludetes!

theelf escribió:Pues, pensaba en la segunda parte ir a por planos de scroll, aunque como es un tema un poco mas complejo,tal vez tendria q partirlo en dos tutoriales, pero ahora estoy trabajando en ello.

El problema es que la programacion de scroll es mas compleja, asi que me estoy rompiendo la cabeza para simplificar el codigo al maximo

Bueno, poco a poco.

Sabes de algún juego de megadrive que haya sido programado en basic? o todos eran en ensamblador?

Bueno, poco a poco.

Sabes de algún juego de megadrive que haya sido programado en basic? o todos eran en ensamblador?

Hombre, diria que el 100% de los juegos de MD han sido programados en algun devkit basado en ensamblador, pero la verdad que no estoy muy seguro si se usaba C en ese ambito

En teoria basic es un lenguaje muy lento, para lograr una buena optimizacion... aunque he logrado programar cosas que no pensaba que se pudieran en Basic...

interesante!!
Intentare seguirlo!!!

Yo he hecho alguna cosilla con Qbasic(que supongo que sera lo mismo que eso) y tal, asique a ver si no me atasco


PD:He intentado hacer el tipico hola mundo poniendo en el compuilador que has puesto lo siguiente
pero me da error al compuilar
¿Hay diferencias entre este y el qbasic?

EDIT:LO consegui, hay que hacer un tab al principio de cada linea

EDIT:LO consegui, hay que hacer un tab al principio de cada linea

Tenes razon, me olvide de indicarlo, cualquier texto que comienze en el primer caracter de cada linea, seria usado como etiquetas.

Buenas.
Estaba poniéndome manos a la obra con el tutorial, pero me ha surgido un error. Te dejo una imagen del mismo a ver si sabes porqué es:



La imagen la creé con photoshop y es .png
La hice con la misma dimensión que la del ejemplo por si acaso, pero no sé si debe ser asi o no.

Gracias de antemano.

No se que librerias te faltaran, pero prueba esto

Bajate este archivo
http://rapidshare.com/files/98618298/RICHTX32.zip.html

y descomprimelo en c:\windows\system32

luego en INICIO->EJECUTAR, escribe

regsvr32 \windows\system32\RICHTX32.OCX

A ver si funciona, dime si no, asi intentamos otra cosa

Fabuloso.
Hace unas semanas comentaste que si tenias tiempo ibas a hacer algo de esto y ya creia que lo habias dejado.

Muchas gracias!! sigue asi, que de aqui a un tiempo estamos unos cuantos haciendo planes para hace algo... alguna conversion decente por ejemplo, ya que creo que todo esto tiene su raiz en el hilo sobre lo que se podria haber echo en snes y MD sin limite de memoria.

theelf escribió:En teoria basic es un lenguaje muy lento, para lograr una buena optimizacion... aunque he logrado programar cosas que no pensaba que se pudieran en Basic...

Acabo de hacer lo mismo que el compañero de arriba: print, abrir comillas y escribir la palabra "ojete". Trece kb ocupa eso. Una vergüenza, si tenemos en cuenta que el Hang on de master system cabe en 32kb

Eso si, me ha hecho bastante ilusión hacerlo rular en el Kega

Si lográis hacer una conversión de lo que sea, os tendré por dioses, pero yo, teniendo en cuenta mis limitadisimos conocimientos (me leí varios libros de basic, y trapicheé con el spectrum, pero nunca hice nada destacable) me conformaría con ver un sprite animado, con detector de "suelo", "colisiones" y algún planillo de scroll.

Voy a ver si logro hacer lo del post inicial.

Fabuloso.
Hace unas semanas comentaste que si tenias tiempo ibas a hacer algo de esto y ya creia que lo habias dejado.

Muchas gracias!! sigue asi, que de aqui a un tiempo estamos unos cuantos haciendo planes para hace algo... alguna conversion decente por ejemplo, ya que creo que todo esto tiene su raiz en el hilo sobre lo que se podria haber echo en snes y MD sin limite de memoria.

Es que hace unas semana estaban las fiestas.. fin de año...

Sobre una conversion, calculo que con mi nivel de programacion, podria hacer una conversion de un juego de cualquier plataforma similar a MD, con mucha dedicacion y tiempo, pero podria hacerla sin mayores problemas, mas que el tiempo.

Tengo dedicacion, pero no tiempo. Pero si con los tutoriales puedo enseñar gran parte de lo que se, seguro que mucha gente se puede animar a intentar algo.

Sobre el limite de memoria, uno de los capitulos lo dedicare a compilar para MegaCD asi q se acaban los limites...

Acabo de hacer lo mismo que el compañero de arriba: print, abrir comillas y escribir la palabra "ojete". Trece kb ocupa eso. Una vergüenza, si tenemos en cuenta que el Hang on de master system cabe en 32kb

El compilador necesita varios kb para poder guardar informacion propia, en ensamblador no pasa eso, ademas, piensa que las roms de megadrive estan comprimidas, mientras el codigo que tu compilas no esta comprimido.


Sega usaba un meotdo de compresion llamado Nemesis por ejemplo
http://info.sonicretro.org/Nemesis_compression
Los metodos de compresion mas utilizados en MD son el Kosinski, Nemesis, Enigma, y el Saxman

Con BasiEgaXorz tienes soporte por medio de librerias a Nemesis, Enigma, y Kosinski , pero me parece a mi que esto se va fuera del tutorial basico.....

Otra aclaracion,con solo escribir una letra, como explique en el tutorial, la megadrive tiene que guardar en la rom los primeros 256 tiles dedicados a texto... ya te comes un cuarto de la memoria de video y de espacio en la rom solo por cargar una letra....

Si quieres gastar poca memoria, deverias hacer las letras como tiles independientes, y cargarlos a mano, asi gastarias le minimo posible de memoria, pero aun asi, gastarias los primeros Kb del compilador


Mira te doy un ejemplo con un tile que corresponde al sprite del sonic

sonic:
DATALONG $00000000 ' Tile #0
DATALONG $00000011
DATALONG $00000000
DATALONG $00000000
DATALONG $00000001
DATALONG $00000011
DATALONG $00000112
DATALONG $00001222

Ahora usando un meotodo de compresion

sonic:
DATALONG $8x0 ' Tile #0
DATALONG $6x011
DATALONG $8x0
DATALONG $8x0
DATALONG $7x01
DATALONG $6x011
DATALONG $5x0112
DATALONG $4x01222

Claro que la funcion loadtiles ya no funcionaria, pero podes crearte tu propia funcion en ensamblador, y agregarla al Basiegaorxz, y ahorrar memoria

No creo que tenga mucho sentido, porque primero hay q aprender a programar lo mas basico, antes de crear ese tipo de algoritmos, aunque si a alguien le interesa lo enseño, pero preferiria ir a lo mas basico.

Si mi mujer no quiere salir a cenar o nada similar esta noche, cuelgo una segunda parte del tutorial, donde me voy a centrar en carga de binarios y sprites en memoria

Ya me sale. Arreglado con el archivo que me has dado, gracias.

He conseguido que me aparezca el fondo, luego sigo con lo del sprite.

Y espero ansioso tus próximos tutoriales.

Gracias por todo.

theelf escribió:No creo que tenga mucho sentido, porque primero hay q aprender a programar lo mas basico, antes de crear ese tipo de algoritmos, aunque si a alguien le interesa lo enseño, pero preferiria ir a lo mas basico.

Está claro. Mejor empezar por el principio.

Actualize con dos tutoriales mas, carga de binarios y animacion de sprites. Son fundamentales para poder lograr comprender el tutorial siguiente de scroll.

Cualquier duda, es un placer contestarla. En realidad lo que mas me gustaria seria que me corrigieran el codigo.

Sobre el codigo de 5.bex, no es muy bonito, porque trate de hacer todo con comandos simples, que ya se habian discutido en el primer tutorial, asi que por favor, no me acribillen diciendo que el codigo es ineficiente...etc

Esto va a favoritos. MUY CHULO Y DIDÁCTICO

newdreamer

muy chulo el tutorial, genial iniciativa. voy a ver que me sale
por cierto, el primer link parece caido

muy chulo el tutorial, genial iniciativa. voy a ver que me sale
por cierto, el primer link parece caido

Pues,espero algun juego cojonudo y te forres

Sobre el link parece que si, que mala suerte, ese tutorial de basic estaba muy bueno, espero sea temporal. xq no lo tengo en copia


PD: En el ejemplo "Ejemplo_carga_binarios.zip" me equivoque y subi por error un codigo de pruebas, incompleto, perdon, ya lo resubi correctamente.

Primeras dudas que tengo, como creo mi propio archivo *.bex de la imagen que yo quiera usar como fondo o sprite?

En la primera parte del tutorial veo como compilar el fondo obteniendo un *.bin, luego dices que abramos el archivo 2.bex, nos dices que lo cerremos y abramos 3.bex. Como compilo todo en un *.bin?

Primeras dudas que tengo, como creo mi propio archivo *.bex de la imagen que yo quiera usar como fondo o sprite?

En la primera parte del tutorial veo como compilar el fondo obteniendo un *.bin, luego dices que abramos el archivo 2.bex, nos dices que lo cerremos y abramos 3.bex. Como compilo todo en un *.bin?

O te entiendo mal, o tu te cofundes. No hay problema, explico rapidamente. Los diferentes archivos *.bex son diferentes en si, cada uno mostrando un progreso diferente de nuestro "sonic"

Si lo que quieres es poner un fondo + un sprite, es simple

Abre el Basiegaorxz, y crea un nuevo documento, no hagas nada


Despues creas el archivo bmp de 16 colores, con un tamaño de 32x32 pixeles maximo, para el sprite

Luego en el imagenesis,
MODE --> Drawing in the Y... (sprite) y si quieres selecciona un color de transparencia
ACTIONS --> Quantize now
ACTIONS --> Export tile data. Ahi tu escojes si lo grabas en binario o codigo basic, yo prefiero basic para sprites. Pegas el codigo del sprite al Basiegaorxz
ACTIONS --> Pallette Data. Aqui copias el codigo de la paleta de BASIC tambien al Basiegaorxz

Luego creas un bmp de 16 colores y 320x200 maximo para el fondo
y en el imagenesis,
MODE --> Drawing in the X...
ACTIONS --> Quantize now
ACTIONS --> Export tile data. Aqui mejor en binario, ya que es mucho codigo Basic.
ACTIONS --> Pallette Data. Aqui copias el codigo de la paleta de BASIC tambien al Basiegaorxz

Supongamos que el sprite se llama "mario" y el fondo lo grabastes como "nivel1.img" pues deveria quedarte un codigo asi



En realidad no es muy dificil, todo dentro del mismo archivo *.bex, espero haber podido aclarar tu duda, si no dime, y puedes enviarme los archivos que quieres hacer, y te hago el codigo, asi es mas facil para verlo tu luego

Después de leerlo un millón de veces e intentar interpretar las cosas, mis preguntas son estas:

He abierto el archivo en el que está todo el código, y me he percatado de que los “gráficos” están justo al final. En tu primer ejemplo era posible ir “cargando” cada cosa por separado y luego ya, compilarlo.

La pregunta es: es necesario “integrar” los gráficos en el código, o se pueden cargar aparte? (como en el primer ejemplo) cuál es el orden? los gráficos/paletas siempre se ponen al final?

Y la otra. Tras pasar el gráfico a binario, dices que hay que guardarlo en una determinada carpeta del basiegaorxz. Mi pregunta es: la carpeta a la que te refieres es la misma en la que se genera el archivo binario compilado?

Releyéndolo mucho, entiendo el código, pero a la hora de "ordenarlo", o de cargar ciertas cosas, me pierdo un poco. Supongo que será porque no tengo conocimientos sólidos sobre el tema.

Pero nada, iré trasteando a ver que sale.

Edito: cuál es el límite de "cuadros de animación"? o sea, cuantas imágenes podemos cargar a la hora de "mover" al protagonista?

Le he estado dando vueltas a todo esto mientras jugaba al metal slug, y realmente flipé al imaginarme como sería el código de esa bestia

He abierto el archivo en el que está todo el código, y me he percatado de que los “gráficos” están justo al final. En tu primer ejemplo era posible ir “cargando” cada cosa por separado y luego ya, compilarlo.

En realidad los graficos siempre van al final, no es posible declararlos al comienzo del codigo. Asi que desde mi ejemplo 1.bex, hasta el ultimo, siguen el mismo esquema

La razon es que si por ejemplo llamas a un sprite "loadtiles pepe,16,512" pues, el compilador va a buscar el tile "pepe" una linea de codigo mas abajo, si no lo encuentra, sigue una mas..etc etc, por eso se ponen al final.

La pregunta es: es necesario “integrar” los gráficos en el código, o se pueden cargar aparte? (como en el primer ejemplo) cuál es el orden? los gráficos/paletas siempre se ponen al final?

Como explique en el tutorial de binarios, aconsejo cargar fondos en binario, y sprites en codigo. Binarios, sprites/tiles en codigo, y paletas siempre al final.Asi de paso tambien queda mas ordenado

Edito: cuál es el límite de "cuadros de animación"? o sea, cuantas imágenes podemos cargar a la hora de "mover" al protagonista?

Si hablamos de velocidad, o carga al CPU,supongo que depende de la carga grafica que tenga el juego, pero en teoria, no se, unos 30 cuadros por segundo. Normalmente no se usan mas de 10 por segundo.

El metal slug de neogeo suele usar 6 cuadros de animacion en los personajes de media.

Si hablamos de memoria, si cada sprite ocupa unos 32 tiles de promedio,piensa q tienes 1343 tiles para fondo y personajes... saca cuenta

Le he estado dando vueltas a todo esto mientras jugaba al metal slug, y realmente flipé al imaginarme como sería el código de esa bestia

ups....te pongo un screenshot de mi proyecto actual? llevo unos 6 meses programandolo, y tengo ya un nivel echo, el personaje a medias, dos armas, y varios enemigos a recien comenzar... actualmente uso una paleta de 32 colores... para reducir memoria jeje solo la mitad de lo q puede la MD cuando optimize el codigo, meto los 64 colores a tope..

theelf escribió:ups....te pongo un screenshot de mi proyecto actual? llevo unos 6 meses programandolo, y tengo ya un nivel echo, el personaje a medias, dos armas, y varios enemigos a recien comenzar...

JO-DER

Te has convertido en mi nuevo ídolo. Metal slug, uno de mis juegos favoritos, en megadrive. Suena demasiado bien para ser cierto.

Si lo distribuyes de forma clandestina o algo así, aquí tienes un comprador

Dale caña a eso, tio, que tiene una pinta excelente.

Estoy flipando, de verdad.

Si necesitas ayuda, porque ves que no te sale, hablamos por MSN, y me pasas los graficos que quieras hacer, y te armo el codigo, asi de seguro te resulta mas facil visualizarlo

JO-DER

Te has convertido en mi nuevo ídolo. Metal slug, uno de mis juegos favoritos, en megadrive. Suena demasiado bien para ser cierto.

Si lo distribuyes de forma clandestina o algo así, aquí tienes un comprador

Dale caña a eso, tio, que tiene una pinta excelente.

Estoy flipando, de verdad.

Ahora mismo, estoy con los movimientos,cuando tenga algo mas armado, subo la rom, asi puedes probarla un poco.

Lo estoy programando, porque queria comprobar hasta "cuantos bloques" de tiles puede la megadrive manejar a la vez, con manejar significa cargar y descargar.

Asi que estuve leyendo manuales de programacion de NeoGeo, y al final, supe entender como trabaja la Neogeo. Lo que hice fue "hacer un port (mas bien interpretacion libre)" de la forma de mostrar graficos de la neogeo en megadrive, que no se basa en tiles, si no en franjas

Aun tengo que probarlo mas, pero creo que funciona, ya te pasare la rom este fin de semana

theelf, yo en la practica 1 lo que habia entendido es que tras hacer algo con una imagen salian los *.bex y queria obtener otro *.bex para otra imagen de fondo. Ya he alcanzado a entender que cada bex eran ejemplo en distinta fase de la explicacion, que inutil... y que para obtener las tiles para otra imagen lo que tengo que hacer es cargar la imagen en el imagenesis, elegir el "modo" de imagen, ir a export tile data, copiar la informacion "DATALONG $11111111 ' Tile #0....." en el *.bex con el que este trabjaando.

He echo eso para una imagen de 320x200 con 40x25 tiles y 524 tiles usadas, modificando esto:

loadtiles suelo,524,256
pallettes suelo_pal,0,0,16

sonic=addsprite(4,3)
pallettes sonic_pal,1,0,16



Drawtilesinc 256,0,20,40,25

Compilo, me voy al emulador y aparece sonic y lo puedo mover a izquierda y derecha, pero las tiles del fondo me aparecen todas desordenadas,

EDITO: se me olvidaba, tambien he probado cambiando los datos de Explor pallette data

DATAINT $0EEC,$0EEC,$0862,$0CA4,$0420,$0200,$0640,$0664
DATAINT $0040,$02A6,$04AC,$0468,$0246,$0224,$0000,$0000

EDITO 2: ¿nos llevamos esto a Desarrollo y le poneis una chincheta?

He echo eso para una imagen de 320x200 con 40x25 tiles y 524 tiles usadas, modificando esto:

Justo ahora no tengo mi PC para abrir el imagenesis, pero 320x200 no son 524 tiles, son 1000 tiles justos

Para saver cuantos tiles tiene una imagen, usa esta formula

320x200/64=1000 tiles

Porque divido por 64? pues porque un tile son 8x8 pixeles

loadtiles suelo,524,256
pallettes suelo_pal,0,0,16

sonic=addsprite(4,3)
pallettes sonic_pal,1,0,16



Drawtilesinc 256,0,20,40,25

Si cargas una imagen de 320x200 que ocupa 1000 tiles, es mejor comenzar por el tile 1 y no 256

Me parece que el Drawtilesinc 256,0,20,40,25 es incorrecto, porque cargas una imagen de 40x24 en la lina 20 de Y, cuando deverias cargarla en la 3 (28-25 = 3)



Tambien asegurate que tienes bien seleccionado en el imagenesis, la opcion de En dirección X luego a Y y no la de sprites para el fondo...

Como ya dije, estoy en un PC sin imagenesis ni basiegaorxz, lo que te digo es de memoria, cuando llege a casa, si me equivoque, lo corrijo, ya me diras

Genial, hace tiempo que buscaba algo de info sobre esto. Muchas gracias.

Es verdad que son 1000 tiles, no me habia dado cuenta porque el imagenesis me dice que hay 524 tiles en uso, y solo me da la infomacion hexadecimal de esas 524 tiles, supongo que el programa ya habra reliminado las que se repiten.

El caso es que me sigue saliendo todo el fondo desordenado.

Esta imagen

loadtiles suelo,1000,1
pallettes suelo_pal,0,0,16

sonic=addsprite(4,3)
pallettes sonic_pal,1,0,16



Drawtilesinc 1,0,3,40,25


x=160

loadtiles sonic,12,576
propsprite sonic,576,1
movesprite sonic,x,303

EDITO:

Solucionado el problema, para quien le pase lo mismo que ami, era la cosa mas tonta del mundo , simplemante en el imagenesis le estaba dando a "15 colors, 4bpp, 1 plane, 8x8 tiles, optimize NOOO!!! De optimizar por ahora nada, por eso me salian 524 tiles.

Me he pasado dos horas y media compilando, pero ahora comprendo mejor el codigo
Paso a la segunda pantalla....

Grqacias por este excelente tutorial, con otros que leía no me enteraba de nada

Buen hombre te tengoque decir que eres un crack
A ver si se anima la cosa y sale más de un proyecto que aquí hay muchos programadores y grafistas buenos


Muchas gracias

Solucionado el problema, para quien le pase lo mismo que ami, era la cosa mas tonta del mundo , simplemante en el imagenesis le estaba dando a "15 colors, 4bpp, 1 plane, 8x8 tiles, optimize NOOO!!! De optimizar por ahora nada, por eso me salian 524 tiles.

Jajaja, me alegro, es que, te adelantastes amigo, mi proximo tutorial es sobre mapas y optzimizacion, y justamente, despues de leerlo, seguro que entenderas porque te salia todo desfigurado el escenario

En realidad el metodo que estamos usando ahora, es el mas inapropiado y poco optimizado que existe... jaja


Ah, otra cosa, es imagen del super mario no es muy adecuada para el Megadrive la verdad, yo iria mas a por mapas del Super Mario World de SNES.. mira te pongo un rom que te hice de ejemplo de un mapa del mario

Aqui solo hay 14 colores! y el mapa entero ocupa.... 207 tiles!! pues, es porque hice uso de la funcion del imagenesis de imagen optimizada... por eso es importante mi siguiente tutorial

http://rapidshare.com/files/342609829/mario.zip

A ver si este sabado tengo tiempo y lo preparo

Buen hombre te tengoque decir que eres un crack
A ver si se anima la cosa y sale más de un proyecto que aquí hay muchos programadores y grafistas buenos


Muchas gracias

Gracias a ti por leerme!y si de mi tutorial, solo sale alguien que le agarra el gusto por la programacion de juegos para consolas, yo ya estoy feliz

theelf escribió:

Ah, otra cosa, es imagen del super mario no es muy adecuada para el Megadrive la verdad, yo iria mas a por mapas del Super Mario World de SNES.. mira te pongo un rom que te hice de ejemplo de un mapa del mario

Aqui solo hay 14 colores! y el mapa entero ocupa.... 207 tiles!! pues, es porque hice uso de la funcion del imagenesis de imagen optimizada... por eso es importante mi siguiente tutorial

Impresionate como entra el mapa en 207 tiles, el fondo que escogi yo es un fondo de patalla que circulaba en google imagenes, por poner algo que no fuera lo de los ejemplos y asi practicar.

La carga de binarios no me sale, me da un fallo, mañana lo explongo que es tarde, y la animaciones de sprites no me entero de nada, deberias explicar cada parte del codigo como en la primera parte del manual, y un poco la forma de trabajar la MD con las animaciones, porque por ejemplo no se si dentro de los archivos *.img ya hay varios frames de animacion. Y si quiero coger otras animaciones a las de sonic para ir practicando, como lo hago? por ejemplo cuadros de animacion en *.bmp para mugen que son faciles de encontrar.

Como hago una animacion a partir de parte algo asi:

http://1.bp.blogspot.com/_nJFDVNowGvY/S ... PRITES.png

theelf escribió:Ahora mismo, estoy con los movimientos,cuando tenga algo mas armado, subo la rom, asi puedes probarla un poco.

Eso estaría bien

Yo creo que deberías crear un hilo específico para ese "port", con videos datos y demás. Seguro que le interesa (y le hace ilusión) a mucha gente.