Tutorial programacion Megadrive - Basico

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.

Es que mas que un port del juego, es un "engine", una forma de cargar imagenes a la vram de forma optimizada, en bloques.

Pero intentare armar algo util, y lo subire un dia que tenga tiempo

Como hago una animacion a partir de parte algo asi:

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

En el imagensis solo puedes cargar una imagen a la vez, asi que con muchisimo ingenio

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.

En relidad no existen las animaciones. Las creas tu a mano, a partir de diferentes sprites.Como dije el Imagenesis solo permite una imagen a la vez, o sea que tendrias que hacer un archivo binario distinto por cada frame de animacion (ryu_patada_frame1.img,yu_patada_frame2.img,yu_patada_frame3.img...etc)

Por eso aconsejaba usar sprites como codigo, asi puedes recurrir a mas trucos para cargar varios sprites de una vez, pero los trucos te los tienes q inventar tu.

El mio es hacer una imagen grande, con los sprites en un orden concreto (de Y a X) y luego separar el codigo a "mano"

Para sprites ve a http://sdb.drshnaps.com/y para fondos a http://www.vgmaps.com/

Sobre tu peticion del sprite de ryu, lleva mucho tiempo, ya que habria que reducirlo un poco de tamaño,y aun asi quedaria en 8x12 tiles, cuando el tamaño maximo de un sprite es 4x4, o sea que se necesitarian 6 sprites por cuadro de animacion.

Aun recortand, la animacion de ryu en reposo serian unos 5 cuadros, o sea, unos 30 sprites diferentes, por solo 1 segundo de animacion....

Valla, buena suerte en portar el III Strike a Megadrive

Si fuera mas temprano te intentaria hacer el codigo, pero son las 4, asi q solo te dejo un bmp echo a 16 colores (joder, si que me costo optimizarlo! puff)



Y el primer sprite trabajado para poder ser convertido en imagenesis. Aqui es donde como te dije, depende del ingenio de cada uno, yo siempre hago una imagen de 32 de alto, por lo que necesite de largo con todos los tiles en linea 1 a 1

Piensa que el imagenesis transforma los tiles en modo sprite de Y a X, o sea de arriba hacia abajo, no de izquierda a derecha como en el modo normal

siento el trabajo que te as tomado en optimizar la imagen, pero he debido explicarme mal, yo no quiero hacer ningun porte todabia, demasiado tengo con intentar entender el codigo. Lo de Ryu lo puse como ejemplo, preguntaba que como hago para usar una secuencia de imagenes y crear asi una animacion, debe estar explicado en la tercera parte del tutorial, pero yo no entiendo el codigo, no se que parte del codigo es la que escoge los sprites de la imagen grande, ni el codigo que tendria que usar si quiero que cada frame de mi animacion sea una imagen independiente.

Lo del ejemplo de Ruy fue por eprovechar secuencias de frames de animacion que se encuentran facil en internet y creo que usadas principalmente para mugen.

Con la carga de binarios estoy trabajando ahora, creo que podre solucionar el error solo, a ver si me voy metiendo en materia proque me veo mas torpe....

siento el trabajo que te as tomado en optimizar la imagen, pero he debido explicarme mal, yo no quiero hacer ningun porte todabia, demasiado tengo con intentar entender el codigo. Lo de Ryu lo puse como ejemplo, preguntaba que como hago para usar una secuencia de imagenes y crear asi una animacion, debe estar explicado en la tercera parte del tutorial, pero yo no entiendo el codigo, no se que parte del codigo es la que escoge los sprites de la imagen grande, ni el codigo que tendria que usar si quiero que cada frame de mi animacion sea una imagen independiente.

Lo del ejemplo de Ruy fue por eprovechar secuencias de frames de animacion que se encuentran facil en internet y creo que usadas principalmente para mugen.

Con la carga de binarios estoy trabajando ahora, creo que podre solucionar el error solo, a ver si me voy metiendo en materia proque me veo mas torpe....

OK, esta noche, promesa te creo un codigo simple, con los binarios e imagenes en bmp separadas, y el codigo todo explicado, paso a paso dentro del mismo codigo en forma de acotacion, asi podes comprender mejor lo de la animacion

Con la carga de binarios estoy trabajando ahora, creo que podre solucionar el error solo, a ver si me voy metiendo en materia proque me veo mas torpe....

Que dices hombre! torpe somos todos, o tu crees que el codigo me sale a la primera? claro, que ahora lo basico lo hago de memoria, pero cuando se complica la cosa, tambien termino tirando del prueba y error...

Pero yo es que ademas de torpe soy pesado y te a caido la grande, ejejeje

Estoy liado como la carga de binarios,y el sonic me sale mal:



El codigo es simplemente el de tu 2.bex con binarios.

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

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



Drawtilesinc 256,0,20,40,8


x=160

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



suelo_pal:
DATAINT $0EA0,$0EA0,$00EE,$004A,$0EEE,$0040,$00E0,$00A0
DATAINT $0EAE,$00AE,$0000,$0004,$0000,$0000,$0000,$0000


sonic_pal:
DATAINT $0E6E,$0A00,$0E44,$004A,$04AE,$0EEE,$0EAA,$0000
DATAINT $0004,$004E,$0000,$0000,$0000,$0000,$0000,$0000


sonic:
datafile sonic.img,BIN

suelo:
datafile suelo.img,BIN

saludos!!

theelf aver si te curras algun cargador de roms para megacd , ¿se podria hacer algo asi? porque el streets of rage1 del sega arcade collection de megacd lo vuelca entero en la ram y ocupa 8mb.

theelf aver si te curras algun cargador de roms para megacd , ¿se podria hacer algo asi? porque el streets of rage1 del sega arcade collection de megacd lo vuelca entero en la ram y ocupa 8mb.

Eso estaría muy bien. Podrías tener practicamente el catalogo entero de megadrive en un sólo cd.

Precisamente me estaba preguntando si sería fácil "portar" el código de ese "metal slug" al mega cd. Mayormente porque estaría impresionante meterle la música original.

Si, en cierto modo, programar para megadrive es un galimatías, programar para mega cd tiene que ser una odisea. He leído cosillas en un foro de la genesis y comentan que es complicado por todo el tema del buffer, bus de datos y tal.

Leyéndo por google, comentan que el basiegaxorz también sirve para compilar en mega cd, así que supongo que mi primera pregunta ya está respondida

Genial idea, Theelf! hacia tiempo que queria hacer un tutorial en español y en condiciones del basiegaxorz.

P.D: Esto no tendria que ir mejor en desarrollo?

Saludos!

Buenas, pues traigo un ejemplo de animacion de sprites, sensillo al maximo, totalmente explicado, paso a paso en el mismo codigo

http://rapidshare.com/files/343142509/Ejemplo_Mario.zip

Si, en cierto modo, programar para megadrive es un galimatías, programar para mega cd tiene que ser una odisea. He leído cosillas en un foro de la genesis y comentan que es complicado por todo el tema del buffer, bus de datos y tal.

Programar para MegaCD es ...mmm.... dificil? creeme, primero domina bien megadrive antes de programar para un complemento, que agrega memoria, otro procesador, y complica todo al extremo....

Precisamente me estaba preguntando si sería fácil "portar" el código de ese "metal slug" al mega cd. Mayormente porque estaría impresionante meterle la música original.

En realidad lo estoy programando tanto para MD como para MegaCD por las pistas de audio

theelf aver si te curras algun cargador de roms para megacd , ¿se podria hacer algo asi? porque el streets of rage1 del sega arcade collection de megacd lo vuelca entero en la ram y ocupa 8mb.

Que yo sepa la Megadrive tiene 64kb de ram, y la Mega CD aporta 768 Kb adicionales. Asi que se podria cargar cualquier juego que estuviera hasta 6mb. El problema es la dificultad de programar eso, creeme, si fuera tan facil ya existiria.
Hace uno o dos años, discuti esto mismo en un foro de gente muy experta en la programacion de Megadrive, y llegamos a la misma conclusion de que seria posible, pero que seria muy dificil

Lo ideal seria que este proyecto, pudiera aprobechar las capacidades de la MegaCD, porque justamente hace eso que dicen, pero con solo los 64k de la megadrive
http://www.retrodev.com/transfer.html

Sobre la compilacion que comentas, los juegos fueron reprogramados para MegaCD. No son simples roms de megadrives cargadas en memoria.

Me pego una semana fuera del foro y vengo y me encuentro esto!!!
Theelf eres mi nuevo idolo.

Voy a ponerme encuanto me levante, que ahora estoy cansado, pero veo que la cosa va tomando forma, y 20 años despues podremos cargar cosas nuevas en nuestra mega.

un puntazo a tu favor y muchas gracias por este tuto.

Un saludo

Theelf a ver si me puede hacer el favor de revisarme el codigo, lo he mirado de cabo a rabo un monton de veces y no se donde meto la pata, parece como si el imagenesis no me diera bien el orden de las tiles, y me salen mezclados unos sprites con otro de la animacion.

http://rapidshare.com/files/343436623/p ... n.rar.html

Justo ahora me voy a abrir mi tienda, me llevo el codigo y te lo reviso, esta noche a eso de las 9 me conecto y te digo que pasa.

No creas que no le he dado vueltas, anoche me acoste a las 4 liado haciendo una animacion despues del codigo anotado que subiste, y hoy tambien he estado unas horas y ya lo he dado por imposible. Es que como te dije soy muy torpe, tampoco quiero que creas que abandono a las primeras de cambio y me es mal facil que me hagan las cosas, estaria angañandome ami mismo.

Genial idea, Theelf! hacia tiempo que queria hacer un tutorial en español y en condiciones del basiegaxorz.

P.D: Esto no tendria que ir mejor en desarrollo?

Gracias. Pues la verdad que vendria que este tutorial apareciera tambien en desarrollo, pero me gustaria que estiviera en los dos foros.

Si se puede hacer, yo encantado

No creas que no le he dado vueltas, anoche me acoste a las 4 liado haciendo una animacion despues del codigo anotado que subiste, y hoy tambien he estado unas horas y ya lo he dado por imposible. Es que como te dije soy muy torpe, tampoco quiero que creas que abandono a las primeras de cambio y me es mal facil que me hagan las cosas, estaria angañandome ami mismo.

No tranqui no pasa nada, hasta que se aprende es normal que no salga nada. Pero una vez que le agarras la mano, sale solo...

No se en tu caso, pero yo llevo mas de 20 años programando, C, ASM, etc, y tengo una buena base. Cuando agarro un lenguaje nuevo, aunque me cuesta un poco, ya se la logica.

Sobre tu ejemplo, pues yo vi un bmp del fondo, y otro de 4 sprites con numeros del 1 al 4, de 16 tiles cada uno

Pues, no se porque tu hicistes en el codigo, que cargara 5 sprites de 12 tiles cada uno.... pues nada, revisa el codigo que te arregle que esta bien

http://rapidshare.com/files/343531220/arreglar.zip

Mirror
http://www.mediafire.com/file/lxhzxqydgmu/arreglar.zip


Oye, si estas interesado en programar para MD, y te gustaria un ejemplo mas elaborado, dime lo que necesitas, pasame los sprites, fondos ...etc, y yo lo hago, y te lo explico linea a linea, no hay problema, solo tienes que darme algun tiempo.

Me cago en la puta, lo que a pasado es que anoche estaba animado 5 sprites de 12 tiles, y hoy hice 4 sprites nuevos de 4x4 tile y estube trabajando con ese codigo, pero al subirlo he subido la version anterior del archivo. Voy a ver que as subido. Gracias!

Me cago en la puta, lo que a pasado es que anoche estaba animado 5 sprites de 12 tiles, y hoy hice 4 sprites nuevos de 4x4 tile y estube trabajando con ese codigo, pero al subirlo he subido la version anterior del archivo. Voy a ver que as subido. Gracias!

Ok, yo me quedo un rato mas online, si ves que tienes algo, postea y lo leo

Pues ya esta solucionado, resulta que era una opcion del imagenesis que tenia mal seleccionada

Drawing in the X direction first, then in the Y
Drawing in the Y direction first, then in the X (sprite)

Tenia la primera y parece que tenita que tener la segunda.


Lo que estoy aprendiendo....


Saludos

Lo que estoy aprendiendo....

Pues yo tambien estoy aprendiendo, acabo de recompilar mi demo de tiles del MS para MegaCD, y aunque tenia mis dudas de como lograr ciertos aspectostodo, por suerte todo salio correctamente.


Ahora me estoy volviendo loco buscando algun emulador de MegaCD que emule el CD a 1x, porque si no, estoy obligado a gastar un CD por cada prueba que necesito comprobar.....

Yo diría que el Kega tiene la opción de emular a 1x/2x/4x y 8x. Prueba a ver...

Yo diría que el Kega tiene la opción de emular a 1x/2x/4x y 8x. Prueba a ver...

Al menos en la ultima version no lo he visto,probare con las antiguas.Gracias

Options/setconfig/sega cd/readahead

Options/setconfig/sega cd/readahead

Tenes razon, que patata que soy.... ahora solo me queda probar el Kega y la MegaCD a ver si hay alguna diferencia... espero que no, que gastar CDs no es my hobby favorito...

Tengo una pregunta.

Lo que intenté hacer fue el primer ejemplo: un fondo estático con un sprite -no animado- creado por mi mismo.

Cargué el fondo original (tal y como estaba en tu ejemplo, sin pasar a binario), pasé el sprite por el imagenesis (pillé el sprite de sonic, lo borré, y a base de rayajos en el paint creé un sprite churrasquero, e hice todo lo que había que hacer con el imagenesis). El problema es que al escribir el código me daba un error concrétamente en esta linea:

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

En la primera linea se supone que tienes que añadir un sprite y entre paréntesis poner las tiles que tiene de alto y ancho (esto no era modificable, supongo, porque tenía exactamente el mismo tamaño que el sprite de sonic. El nombre, obviamente, si que lo modifiqué. El problema venía con la linea siguiente. Me daba un error y no podía compilar.

Cuál sería el orden correcto a la hora de colocarlo? palettes espacio nombre del archivo barra baja pal y luego los números (número de paleta, cero porque queremos todos los colores, y dieciséis porque es la capacidad de la paleta). Dónde está el error?

Cuál sería el orden correcto a la hora de colocarlo? palettes espacio nombre del archivo barra baja pal y luego los números (número de paleta, cero porque queremos todos los colores, y dieciséis porque es la capacidad de la paleta). Dónde está el error?

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

En realidad no veo el error en ningun lado, dejastes un espacio antes de "pallettes"? es lo unico que se me ocurre.

Ah lo de poner "_pal" es cosa mia, para que se indentifique mejor, y sepa a simple vista la paleta de que sprite es. Podes ponerle el nombre que quieras a la paleta

Si seguis teniendo problemas, y usas MSN, si te interesa podes mandarme un MP con tu email, asi te agrego

muy bueno el tutorial , me has dado varias ideas... espero sacar algo de tiempo tras los exámenes de febrero...

Por cierto , sube los ejemplos a otro sitio RS es horroroso, no hace mas que ponerme continuamente el cartel de intentelo mas tarde

theelf escribió:Ah lo de poner "_pal" es cosa mia, para que se indentifique mejor, y sepa a simple vista la paleta de que sprite es. Podes ponerle el nombre que quieras a la paleta

Si que dejé el espacio. Lo que hice fue copiar tu código, y sustituir los datos de sonic (el nombre) por los de mi archivo.

Entonces, el orden sería palettes espacio y luego el nombre del archivo, no? quizá ahí esté el error.

Voy a empezar a trapichear, modificando cosas, y probando, que seguro que así me sale...

No uso msn, pero te seguiré dando la brasa por aquí

Por cierto , sube los ejemplos a otro sitio RS es horroroso, no hace mas que ponerme continuamente el cartel de intentelo mas tarde

Si allguien quiere hacer mirros encantado, si no ya vere si tengo tiempo un dia de estos. El mejor seria http://www.mediafire.com porque no tiene espera para bajar.

Si que dejé el espacio. Lo que hice fue copiar tu código, y sustituir los datos de sonic (el nombre) por los de mi archivo.

Entonces, el orden sería palettes espacio y luego el nombre del archivo, no? quizá ahí esté el error.

Voy a empezar a trapichear, modificando cosas, y probando, que seguro que así me sale...

No uso msn, pero te seguiré dando la brasa por aquí

Si pallettes espacio, y nombre del archivo


Si por ejemplo tenemos un sprite del mario de 32x32 pixeles seria algo asi:

impresionante tu proyecto de conversion del metal slug . yo gracias al tuto he conseguido cargar mi primer fondo,un tablero de HeroQuest, bien! y ya tengo dudas existenciales es que son 1000 tiles con digamos resolucion 40x25 y lo que nose es como tengo que tratar la imagen o hacerla de cero para trabajar los tiles y para que ocupando la pantalla completa no suponga mas de 1000 tiles(tengo el paint shop pro), lo cual se me convierte en una paradoja espaceotemporal ke flipo xDDD pq si kiero pantalla completa para un fondo digamos 320x224 que es 40x28 que son 1120 tiles y estamos limitados a 1088,como ahorro tiles ?
he leido algo, como que un mismo tile lo podriamos poner por toda la pantalla 320x224 y solo ocuparia en memoria el espacio de un tile,o no? bueno esque con eso estoy mas liao que la pata de un romano con eso y como adaptar los colores tambien, haber si me puedo bajar la demo tecnica del fondo ese que adaptaste haber si me aclaro pq el RR ese es mas plasta que yo

impresionante tu proyecto de conversion del metal slug . yo gracias al tuto he conseguido cargar mi primer fondo,un tablero de HeroQuest, bien! y ya tengo dudas existenciales es que son 1000 tiles con digamos resolucion 40x25 y lo que nose es como tengo que tratar la imagen o hacerla de cero para trabajar los tiles y para que ocupando la pantalla completa no suponga mas de 1000 tiles(tengo el paint shop pro), lo cual se me convierte en una paradoja espaceotemporal ke flipo xDDD pq si kiero pantalla completa para un fondo digamos 320x224 que es 40x28 que son 1120 tiles y estamos limitados a 1088,como ahorro tiles ?
he leido algo, como que un mismo tile lo podriamos poner por toda la pantalla 320x224 y solo ocuparia en memoria el espacio de un tile,o no? bueno esque con eso estoy mas liao que la pata de un romano con eso y como adaptar los colores tambien, haber si me puedo bajar la demo tecnica del fondo ese que adaptaste haber si me aclaro pq el RR ese es mas plasta que yo

Hola kkdelavk , muchisimas gracias por leer mi tutorial! si cargas una imagen de 320x224 ya no te queda practicamente memoria para nada mas es una megadrive! solo tiene 64k de video!

jaja, la verdad es esa. La realidad es otra, existe un metodo de cargar imagenes que se llama "por mapas", o sea, se hace un mapa de tiles repetidos en la imagen, asi no se duplican en memoria, y la megadrive luego ordena en tiempo real.
Asi con 400-500 tiles, puedes hacer un escenario completo, lo que te deja otros 500-700 para persoanjes, enemigos..etc

Justamente es mi proximo tutorial, si esperas uno o dos dias, lo tienes colgado

Para dar animos, solamente usando las enseñanzas de los tutoriales que ya colge, mas los dos que me faltan (mapas y scroll) en teoria,se podria hacer un RPG simple, o un juego de naves simplon.... animos, esperen unos dias a los tutos que faltan y no se desanimen!! ja

Asi q diganme, que prefieren que enseñe a programar, un juego de naves o un RPG?

Sobre la demo tecnica del Metal Slug, es mas complicado de lo que enseñe aun (pero no tanto? )

Un vídeo o gif en movimiento de ese Metal Slug de MD, por DIOSSSSS!!!! xD

Un vídeo o gif en movimiento de ese Metal Slug de MD, por DIOSSSSS!!!! xD

mmm.. es muy incomodo de hacer eso, mejor en estos dias, le doy mas o menos forma al codigo, y cuelgo una rom jugable (con jugable se entiende a mover el personaje por el nivel o menos..jaja)

Es que a mi mas que portar el juego, me interesaba ver de programar un engine que cargara un nivel de metalslug en la memoria de la Megadrive.

Pero si les hace ilusion, escojo algun punto del codigo donde funcione , compilo,y subo la rom

theelf escribió:Pero si les hace ilusion, escojo algun punto del codigo donde funcione

HACE, HACE!!

HACE, HACE!!

Ok, primero termino la tercera parte del tutorial, y cuando lo tenga listo, preparo el codigo del "metal slug" (que aclaro, es un demo tecnica, para que luego no me cuelgen si ven que no es el juego..jaja)


Mi interes por poner un escenario del metal slug en Megadrive, es este:

-Maximos tiles Megadrive en vram=1343 (incluye escenario+sprites)

-Tiles que tiene el escenario del Metal Slug=16800 aproximadamente
-Tiles usados por sprites en el mismo escenario=8000 aproximadamente

O sea, que hay que meter unos 25000 tiles aprox en 1343.................... ya veran porque me pico la curiosidad de ver que podia hacer.....

En realidad la NeoGeo tampoco los puede cargar todos en vram, pero ya es otra historia... porque los cartuchos de NeoGeo no son comparables a los de Megadrive/SNES..etc

A mi ya me salió lo que estaba intentando. Supongo que puse un número de más, o no puse el nombre correctamente.

El caso es que se veía mi dibujo, pero desfigurado, por lo que, probablemente, el problema vendría del imagenesis.

Ya que estáis comentando cosas del metal slug, y las limitaciones de la megadrive, aprovecho para hacer unas preguntas:

Si, en teoría, 80 sprites es el límite máximo que puede mostrar la consola, que ocurriría si subimos la frecuencia de su procesador? He leído en foros americanos que la megadrive es facilmente overclockeable (a 10/12 e incluso a 17mhz), y me interesaría saber que es lo que pasaría con el límite de sprites.

Lo que comenta la gente es que desaparecen las ralentizaciones, pero no comentan nada de los parpadeos (lo que pasaba en el mega turrican cuando explotaba el segundo jefe, y disparabas a la vez), por lo que estaría bien saber si esto último también se solventa con el overclock.

En la neo geo nunca he visto parpadeos (380 sprites podía mover la muy cerda), pero si ralentizaciones (en la saga metal slug, mayormente, y en el blazing star). Si overclockeamos en nebula, los juegos van a fullspeed sin ningún tipo de slowdown.

P.D: Yo también tengo ganas de ver esa demo técnica

A mi ya me salió lo que estaba intentando. Supongo que puse un número de más, o no puse el nombre correctamente.

El caso es que se veía mi dibujo, pero desfigurado, por lo que, probablemente, el problema vendría del imagenesis.

Ya que estáis comentando cosas del metal slug, y las limitaciones de la megadrive, aprovecho para hacer unas preguntas:

Si, en teoría, 80 sprites es el límite máximo que puede mostrar la consola, que ocurriría si subimos la frecuencia de su procesador? He leído en foros americanos que la megadrive es facilmente overclockeable (a 10/12 e incluso a 17mhz), y me interesaría saber que es lo que pasaría con el límite de sprites.

Lo que comenta la gente es que desaparecen las ralentizaciones, pero no comentan nada de los parpadeos (lo que pasaba en el mega turrican cuando explotaba el segundo jefe, y disparabas a la vez), por lo que estaría bien saber si esto último también se solventa con el overclock.

En la neo geo nunca he visto parpadeos (380 sprites podía mover la muy cerda), pero si ralentizaciones (en la saga metal slug, mayormente, y en el blazing star). Si overclockeamos en nebula, los juegos van a fullspeed sin ningún tipo de slowdown.

P.D: Yo también tengo ganas de ver esa demo técnica

No soy experto en el hardware de la Megadrive, pero por lo que se, aumentar la velocidad al procesador no va a darte mas sprites, ya que es una limitacion del hardware de video. En todo caso, lo que pasaria seria que tendrias mas velocidad para moverlos.

Si seria *posible*, aumentando la vram de la megadrive, de 64k a 128k. Es un mod no muy complicado.Pero el codigo que programaras solo serviria para tu MD, no tiene sentido.

De nuevo, desde mi ignorancia, el maximo de cada sprite es 32x32, si la MD puede mover 80 a la vez... pues sumemos.. 320x224=10x7 sprites de 32x32=70 sprites

O sea que si sumamos todos los sprites, podemos llenar la pantalla y nos sobrarian 10 sprites. No creo que la limitacion de los sprites sea un problema, si no tanto la problematica de programar y de la rom, para cargar/descargar sprites de la ram a la vram cuando se necesiten, repito, desde mi desconocimiento exacto del hardware.

Lo mas normal es cargar todos los sprites en vram, tanto los visibles como los que no, para que sea mas facil de programar y mas rapido para la consola al momento de visualizarlos. En ese caso, la NeoGeo lleva ventaja claro.

No se bien a que le llamas parpadeos, me imagino que te refieres a cuando se descarga un sprite de memoria, ese tiempo que la MD se toma en pasarlo de la rom a la ram, y luego a la vram.

O cuando no da la vram, y momentaneamente se descargan sprites o tiles de la vram (pasaba mucho en NES)

Por ejemplo la SNES tiene mas capacidad para mover sprites, pero por el otro lado, menos resolucion, lo que es logico, porque en realidad lo que hicieron fue darle menos resolucion de pantalla, para lograr una mejor soltura para mostrar graficos.

En MD se podria usar una resolucion menor, para evitar muchos de los problemas que mencionas (paradeos por ejemplo). El SF2 es un ejemplo en el que la megadrive usa 256x224

O se puede recurrir al interlaced, para generar tiles el doble de grandes, sin gasto extra de vram...

otro que se apunta a la peticion de ver ese metal slug.

Me he puesto a ver si consigo mostrar el sprite pero no me funciona. Te dejo la parte del código que supongo que es la interesante:



Me compila bien, pero al ponerlo en el emulador no sale el sprite:



El sprite que uso es este:



Lástima que no tenga mucho tiempo que dedicarle a esto, ya que me gusta y quiero aprenderlo. Pero bueno, me voy poniendo poco a poco según vaya pudiendo.

Me he puesto a ver si consigo mostrar el sprite pero no me funciona. Te dejo la parte del código que supongo que es la interesante:

Primero, no se porque despues de cada sentencia pones ":" pero es incorrecto

Segundo, el tamaño maximo de los sprites en megadrive es de 32x32 o sea 4x4 tiles.

personaje = addsprite(4,6):

Es incorrecto ya que el tamaño maximo es de 4x4 tiles o sea, deveria ser algo asi

personajeA = addsprite(4,4)
personajeB = addsprite(2,4)

Te reescribo el codigo, ya que la mayoria de el estaba incorrecto, espero esto aclare tus dudas




Si el codigo no se copia bien, aqui puedes bajarlo

http://www.mediafire.com/file/g1znottk21i/ejemplo%20Chon27.bex

Esta completo, con personaje y un fondo en codigo basic, como tu sprite me hizo recordar al kung fu de nes, le puse un fondo acorde

Para que el codigo fuera mas liviano, hice el fondo de 8x5 tiles y lo repeti, para simular un piso.

EL codigo esta listo para copiar y pegar, y compilar

theelf escribió:De nuevo, desde mi ignorancia, el maximo de cada sprite es 32x32, si la MD puede mover 80 a la vez... pues sumemos.. 320x224=10x7 sprites de 32x32=70 sprites

O sea que si sumamos todos los sprites, podemos llenar la pantalla y nos sobrarian 10 sprites. No creo que la limitacion de los sprites sea un problema, si no tanto la problematica de programar y de la rom, para cargar/descargar sprites de la ram a la vram cuando se necesiten, repito, desde mi desconocimiento exacto del hardware.

No se bien a que le llamas parpadeos, me imagino que te refieres a cuando se descarga un sprite de memoria, ese tiempo que la MD se toma en pasarlo de la rom a la ram, y luego a la vram.

Bueno, no sé si también pasaba en hardware real, pero en Gunstar heroes (vía emulador), cuando ciertos objetos explotan y hay muchos sprites en pantalla, se puede observar como parte de las explosiones desaparecen. En el megaturrican pasa exactamente igual. Tampoco es que moleste mucho, o sea un problema grave.

Ambos son juegos del 93. En cartuchos parecidos como el Batman and robin, esto no pasa. Además de esto, diría que éste último es el juego de md en el que más bichejos aparecen en pantalla (sin contar streets of rage, pero estos estaban menos animados, y si que había alguna ralentización).

Ese batman and robin podría servir como "engine" para hacer algo tipo metal slug. Los escenarios no son tan "artísticos" ni con tantos detalles como el juego de snk, pero la calidad general, cantidad de sprites y acción, me recuerda muchísimo a ese juego.

Gracias por la explicación, tenía esa duda desde hace bastante tiempo.

Es que en realidad que a menos que tengas el codigo fuente, no sirve de mucho fijarse en los juegos.

A medida que vas aprogramando, y vas mejorando el codigo, te das cuenta de como solucionar muchos de estos problemas.

El problema con la programacion casera en cualquier consola suele ser que las utilidades de programacion, no son tan avanzadas como las que usaban los desarrolladores en su epoca, y que ademas, esas personas se les pagaba para programar aquello, y uno, pues lo hace en su tiempo libre como hobby... asi q no se puede esperar incluso, hoy en el 2010 lograr lo que en el 92....

Un punto a tener en cuenta,a mi parecer,en especial en lo referente a relentizaciones, es que se programa en un hardware diferente o superior a la consola (un devkit)...y se hacen pruebas en cartuchos con buena rom...... pero luego el juego final lo montan en china, con las roms mas baratas y cutres...

En cuanto a material casero se refiere, lo más gordo que he visto es el patch que le pusieron al mk2, al cual le hicieron un montón de modificaciones.

También está el pier solar y sucedaneos, pero esos supongo que si que tendrán un devkit oficial, al igual que los de tectoy. Y ya es raro que estos últimos no hayan hecho cosas parecidas al metal slug aprovechando juegos ya hechos (como ya hicieron con wonderboy y demás, en el que se limitaron a cambiar el nombre del juego, y el sprite ).

Actualize la guia con el Tutorial 4, que se llama MAPAS. Todo aquel que este interesado en seguir programando para MD, tiene que comprender al 100% los Mapas,y su programacion, ya que son fundamentales para el Tutorial 6, que se llamara "Scroll" (creo q varios lo esperan he?¿ jaja)

(el 5 sera algo asi como "fake Scroll" que tambien es muy util)

También está el pier solar y sucedaneos, pero esos supongo que si que tendrán un devkit oficial, al igual que los de tectoy. Y ya es raro que estos últimos no hayan hecho cosas parecidas al metal slug aprovechando juegos ya hechos (como ya hicieron con wonderboy y demás, en el que se limitaron a cambiar el nombre del juego, y el sprite ).

Tuve la suerte de hablar con los desarrolladores del Pier Solar, cuando aun no se llamaba Pier Soalr, si no Tavern RPG y realmente no tenian ningun devkit ni nada oficial, si no que fue echo a mano, como la mayoria de los juegos de MD, si no recuerdo mal en C y ASM

Sobre lo que habeis estado poniendo unos comentarios atras yo he echo cuentas y no netiendo porque la MD tiene capacidad para manejar solo y 80 sprites.

Mis cuentas:

64Kbis Vram = 64x1024 = 65536 bytes X 8 = 524288 Bit.

Aparte, 1pixel tengo entnedido que ocupa 4bit para una paleta de 16 colores luego un tile ocupa 64x4 =256bit

524288/256 =2048 Tiles, esto ya lo veo un dato contradictorio a lo que se dice aqui, y a demas si dividimos entre tamaño maximo de sprite (4x4tiles), 2048/16 = 128, los mismo 128 sprites maximos que pone la Snes en pantalla.

¿Cual es la explicacion?

Oye theelf, gracias por tu ayuda, aún no he tenido un rato para probarlo, pero te aseguro que voy a intentar seguir todos tus tutoriales (mientras pueda), pero cuando las circustancias me lo permitan.

Sólo quería asegurarme de agradecer tu esfuerzo en ayudarnos desinteresadamente, ya que no sé cuando podré poner en práctica lo último que me has dicho. Pero lo haré, y cuando tenga más dudas volveré a preguntar.

Gracias y enhorabuena por este gran tema.

Oye theelf, gracias por tu ayuda, aún no he tenido un rato para probarlo, pero te aseguro que voy a intentar seguir todos tus tutoriales (mientras pueda), pero cuando las circustancias me lo permitan.

Sólo quería asegurarme de agradecer tu esfuerzo en ayudarnos desinteresadamente, ya que no sé cuando podré poner en práctica lo último que me has dicho. Pero lo haré, y cuando tenga más dudas volveré a preguntar.

Gracias y enhorabuena por este gran tema.

Gracias, es realmente agradable saber que interesa el tema.Pregunta lo que, y cuando quieras, es un placer responder.

Mis cuentas:

64Kbis Vram = 64x1024 = 65536 bytes X 8 = 524288 Bit.

Aparte, 1pixel tengo entnedido que ocupa 4bit para una paleta de 16 colores luego un tile ocupa 64x4 =256bit

524288/256 =2048 Tiles, esto ya lo veo un dato contradictorio a lo que se dice aqui, y a demas si dividimos entre tamaño maximo de sprite (4x4tiles), 2048/16 = 128, los mismo 128 sprites maximos que pone la Snes en pantalla.

¿Cual es la explicacion?

Lo siento no se bien cuales son tus cuentas, pero te adjunto un mapa de la vram de la megadrive, que te conteste a ti mismo en el Trabajo de tiles, tea cuerdas?

Scroll B = $E000 - $FFFF [8192 Bytes]
Scroll A = $C000 - $DFFF [8192 Bytes]
Patterns (Tiles 1520-1535) = $BE00 - $BFFF [1856 Bytes]
Window = $B000 - $BDFF [2240 Bytes]
Patterns (Tiles 1396-1407) = $AE80 - $AFFF [384 Bytes]
Sprite = $AC00 - $AE7F [640 Bytes]
H Scroll = $A800 - $ABFF [1024 Bytes]
Patterns (Tiles 0-1343) = $0000 - $A7FF [43008 Bytes]

Como veras le queda util de los 64k, 42k, despues de destinar parte de la vram a otras tareas.

Los 128 sprites de la SNES, es marqueting, no los puede mover fluidos ni de coña . Otra cosa, ten en cuenta que la resolucion de la SNES es 256x224,un 20% menos que los 320x224 de la MD.

Coño, he hecho casi las mismas cuentas sin acordarme que hace algo mas de un mes me salto la misma duda, y claro he obtenido la misma respuesta, ejejej
Theelf, si no me lo dices no me acuerdo.

Sam30 escribió:Me puede confirmar alguien si mis calculos son correctos:

SNES Vram 65536 bytes - 544 bytes como tabla de direccion de tiles "OAM" = 64992 bytes
32 bytes por tile = 4 bits por píxel; 8x8 = 64 pixel x 4bit = 256bit = 32bytes

64992 / 32 = 2031 tiles.

theelf escribió:Los 128 sprites de la SNES, es marqueting, no los puede mover fluidos ni de coña . Otra cosa, ten en cuenta que la resolucion de la SNES es 256x224,un 20% menos que los 320x224 de la MD.

Estás completamente seguro de lo primero? o sea, hay algún ejemplo que lo demuestre?

He visto ralentizaciones en bastantes juegos de snes, pero claro, no tengo un "contador de sprites"

Y ya que has programado para ambas, y aprovechando que ahora mismo le estoy dando caña al Final fight de mega cd, me gustaría saber si éste último no puede superar el límite de 80 sprites a la vez en pantalla. He mirado en un montón de sitios, y no hay nada al respecto, así que supongo que no podrá con más.

Este cuarto tutorial es bastante más sencillo. Cuando tenga un poco de tiempo intentaré hacer algo interesante

Gracias por los tutos, una vez más.

Creia que hoy nadie mas escribia aqui.

Yo estoy haciendo una animacion con un personaje de 10x8 tiles, he usado 6 sprites y tengo 12 cuadros de animacion.Si lo logro me llebara algunos dias.

Los 12 cuadros de animacion los tengo en una unica imagen de 744x80 pixel, si lo hago mediante la forma simple veo mas o menos clara la forma de cargar los tiles de cada sprite. He hecho un matriz en un folio para ver mejor a cada sprite las tiles que les corresponde.

Teniendo en cuenta que las tiles se leen de arriba abajo y de izquierda a derecha, entonces si tengo una imagen de 10x8 tiles, el sprite A(2x4) tendria las tiles 0,1,10,11,20,21,30,31. El sprite B(4x4) tendria 2,3,4,5,12,13,14,15,22,23,24,25,32,33,34,35. Y asi hasta el sprite F.

Si lo hago mediante carga de binarios, al cargar archivo.img,bin como le digo que tiles de ese archibo quiero que cargue para cada sprite??
Tengo que usar una imagen para cada uno de los 72 sprites que componen la animación completa?

Si lo hago mediante carga de binarios, al cargar archivo.img,bin como le digo que tiles de ese archibo quiero que cargue para cada sprite??
Tengo que usar una imagen para cada uno de los 72 sprites que componen la animación completa?

Si, y por ende, una paleta por cada uno.. vamos, incomodo, por eso recomendaba los sprites cargarlos como codigo basic

Lamentablemente el imagenesis no es muy bueno, y tiene muchas limitaciones

Teniendo en cuenta que las tiles se leen de arriba abajo y de izquierda a derecha, entonces si tengo una imagen de 10x8 tiles, el sprite A(2x4) tendria las tiles 0,1,10,11,20,21,30,31. El sprite B(4x4) tendria 2,3,4,5,12,13,14,15,22,23,24,25,32,33,34,35. Y asi hasta el sprite F.

Bueno, me perdi con los numeros, pero justamente ese trabajo de chinos es lo que hago yo... no queda otra, es una consola de los 80.... y como te dije, el imagenesis, realmente tiene muchas limitaciones

No se que sprite estaras haciendo, pero me viene a la mente el del Battletoads de SNES jajaj




En serio, por eso, veo mas factible, programar un RPG, que es lo que etoy haciendo hace meses.

Sprites de 32x32 como maximo, y como mucho algun jefe brutalmente gigantesco, que en realidad es el fondo, con algunos sprites moviles (lease manos, fuego de la boca...etc)

Es mas, viendo que hay gente con ganas aqui, cuando termine el tutorial, enseñare a programar un RPG, y pondre el codigo basico... nada del otro mundo, pero al menos, sera un punto de partida para muchos... espero! jajaja

Eres un máquina!!!!! ... me encanta la idea del RPG

Un RPG? eso lo veo complicadisimo si se le quiere dar la profundidad argumental que el juego requiere, harian falta montones de dialogos, interacciones entre personajes, cientos de variables para que no sea tremendamente lineal. Ami me resulta mas atractivo un juego de lucha, pero me pregunto como sera la rutina para que el contrincante responda con coherencia a mis patadas y puñetazos, y a la ves sea posible ganarle, porque si digo:

Si juegador1= puñetado bajo, entoncen cubirse abajo
Si jugador1= no cubirse, entonces patada fuerte.
si jugardor1= 2 tile de distancia, entonces patada larga
si jugardor1= 1 tile de distancia, entonces puñetazo corto larga...

No correria el riesgo de crear un adversario rutirario, cobarde (a cada ataque mio cubriendose), y a la vez casi imposible de ganar?

por eso lo que mas atractivo me parece seria un juego de naves de las tipicas que el enemigo siempre aparece por el mismo lado de la pantalla, muy arcade y divetido


Pero por ahora no estoy haciendo nada de eso, mi animacion es un goku haciendo una onda vital, solo son ejercicios para equivocarme mucho y aprender mas.

Ami tambien me gustaria saber si estas seguro de que los 128 sprites de la Snes es o no marqueting