Tutorial programacion Megadrive - Basico

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...

Bueno, una cosa es hacer un juego, y otra algunas bases para un codigo. Lo primero te lleba años, lo segundo una semana

Sobre lo que dices de un juego de pelea, el engine es increiblemente mas complicado que cualquier RPG.
Programar movimientos, cajas de colision, inteligencia artificial...etc etc a buenos fps, es una tarea muy complicada, diria casi imposible para una sola persona.

Sobre 128 sprites de la snes,por mi experiencia, una cosa es el papel y otra la realidad.

Para que usaras los sprites? si es para fondo, usas tiles, que son mas simples de dibujar.

Los quieres para personajes, objetos...etc dibujarlos no es mayor problema, mas teniendo en cuenta que la snes usa 256x224 contra los 320x224 de la MD.

El problema viene que hacer con esos sprites. Moverlos no es tan intensivo para la CPU, asi que podra moverlos + o - bien.

Lo que es intensivo es todo lo relacionado con colisiones, porque calcular cajas de colisiones, distancias...etc necesita de mucho CPU, y ahi es donde la SNES comienza a flojear.

Yo diria que la SNES, tiene capacidad grafica para mostrar mucho, pero le falta la velocidad suficiente para los calculos de fondo. Asi que en realidad de poco sirve

Tambien es cuestion de programacion, la SNES tiene un procesador de 16bits, pero un bus de 8bits, asi que si si usas opcodes de 16bits, necesitaras el doble de proceso por cada uno, por eso muchas veces la optiumizacion del codigo usando registros de 8bits ayuda, pero complica todo.


Esta claro que depende de gran manera de la programacion, ya que la SNES tiene procesadores de apoyo a la CPU de donde se puede tirar tambien.

que tal un engine para un juego de coches del tipo road fighter? dividmos la pantalla en 3 partes, en el centro la carretera y a los lados los decorados y luego solo hay que poner unos cuantos sprites de coches que se muevan aleatoriamente.

que tal un engine para un juego de coches del tipo road fighter? dividmos la pantalla en 3 partes, en el centro la carretera y a los lados los decorados y luego solo hay que poner unos cuantos sprites de coches que se muevan aleatoriamente.

Si es en linea recta, se puede simular un scroll con sprites, y listo. Sa tiene curvas, imagino que seria mas facil crear un mapa gigante, con la carretera y hacer scroll.

Pero para hacer scroll en un mapa de mas de 64x64 tiles (512x512 pixeles) no es tan facil, bueno... es facil, pero requiere mas conocimientos que los tutoriales existentes.

Esta semana estare bastante ocupado con el trabajo, pero intentare poner un tutorial nuevo, creo q sera el de "Falso scroll", y con esos conocimientos, podriamos hacer un road fight simple

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

Para los que me comentaron que les interesaria ver el engine del Metal Slug para Megadrive, pues no tuve tiempo de ordenarlo, asi q agarre lo poco q tenia organizado (medio nivel),lo compile, y agrege al personaje principal, asi al menos se ve mas completo... aunque solo camina..jaja

Compile para megadrive como Rom, y para MegaCD como ISO+Mp3. Para el port a MegaCD me tuve que romper la cabeza... porque el CD es mas lento que la rom.....

Me acuerdo que John Torrijas, comento en un post lo mucho que ocupa un juego en basiegaxorz, bueno, pues esta rom tiene varios sprites de animacion del personaje, algunos graficos que estan y no se ven (estuve perro de quitarlos de la rom..), mas medio nivel entero.. y ocupa 180kb sin comprimir.. no creo q este tan mal





Compilado para Megadrive - sin musica
http://rapidshare.com/files/346782860/Demo_tecnica_MS_Megadrive_-_TheElf.zip

Compilado para MegaCD - Con musica hace mas gracia..
http://rapidshare.com/files/346782167/Demo_tecnica_MS_MegaCD_-_TheElf.zip

Si a alguien le interesa, comento algunas datos tecnicos..

ah agrego, que basicamnete en el codigo no hay nada mas de lo visto en los 4 tutoriales que escribi, no hay codigo raro ni dificil.
Esto se puede lograr con los tutotiales basicos que di.

Oye.. pues está muy bien

theelf escribió:Compilado para Megadrive - sin musica
http://rapidshare.com/files/346782860/Demo_tecnica_MS_Megadrive_-_TheElf.zip

Eres mi puto héroe, tío.
Abre una cuenta Paypal para donaciones para llevar este proyecto a su fin jejejje

hombreimaginario escribió:

theelf escribió:Compilado para Megadrive - sin musica
http://rapidshare.com/files/346782860/Demo_tecnica_MS_Megadrive_-_TheElf.zip

Eres mi puto héroe, tío.
Abre una cuenta Paypal para donaciones para llevar este proyecto a su fin jejejje

Pues si, estaria de p.m. un metal slug en megadrive.

theelf, tío, me FLIPA ver el Metal Slug moviéndose en Mega!!!

tenemos que darle la vida de nuevo aquella maravilla negra de sega

tenemos que darle la vida de nuevo aquella maravilla negra de sega

Es lo que intentaremos con este tutorial jjeje

theelf, tío, me FLIPA ver el Metal Slug moviéndose en Mega!!!

Gracias, a mi tambien!!

Tengo una semana bastante ocupada con trabajo, pero primero intentare seguir el tutorial.

Cuando termine con el tutorial, me dedicare algun tiempo con el metal slug a ver que puedo hacer.

Estimo con los conocimientos que tengo, podria hacer un port del juego. Pero la realidad es, que no creo q una sola persona pueda logarlo la verdad...

Se necesitaria de varios programadores, de un nivel similar, que trabajaran juntos.


Por lo pronto, el martes o miercoles, colgare la quinta y sexta parte del tutorial, que las tengo mas o menos listas.

Con las explicaciones y ejemplos de estos dos tutoriales, cualquiera podria hacer algo similar a la rom del metal slug que colge....

Animo con eso metal slug, es una maravilla, as logrado que no se note mucho la carancia de colores.

Puedo hacer una critica?? Me resulta que las piernas del tio van demasiado rapido para lo que avanzan, y si te sobra algun sprite cuando este acabado estaria bien ponerle sombre al muñeco para que no parezca que va flotando.


Si aprendo algo en condiciones en este tutorial y aun no as acabado el metal slug, yo me presto a ayudarte, por ejemplo me podias encargar la programacion de algunas animacion de ciertos enemigos. Igual podemos montar un pequeño equipo de programacion para acelerar el proceso. por aqui abra gente que controle foto show, musica para algun saple, y demas.

Animo con eso metal slug, es una maravilla, as logrado que no se note mucho la carancia de colores.

Si te digo que en el fondo... solo hay 16 colores a la vez? que me dices?
jaja, es verdad,solo 16 nada mas, y no saves el trabajo que me dio crear una paleta adaptativa, trabajar pixel a pixel para lograr simular colores..etc

Incluir mas colores, significaria agregar tiles.

Puedo hacer una critica?? Me resulta que las piernas del tio van demasiado rapido para lo que avanzan, y si te sobra algun sprite cuando este acabado estaria bien ponerle sombre al muñeco para que no parezca que va flotando.

En realidad no aplique ninguna logica a la animacion del personaje. Agarre unos cuantos cuadros de animacion y los junte. No medi tiempos ni nada, deje al azar hacer su trabajo...jaja

Aqui te dejo el archivo de imagen que hice para la animacion



Lo de los sprites, es un tema trabajoso, ya que solo me sobran entre 200 y 350 tiles despues de cargar el fondo. Asi que hay que trabajar muy bien las animaciones, para no poner tiles repetidos..etc

Imaginate, si en un frame, tienes dos tiles sin nada, los pierdes, en cambio, lo que habria que hacer seria un codigo separado por cada uno, y unirlos al final.... y asi te ahorras dos tiles...

Ya me entenderas el trabajo que es eso.....

Hola theelf, tengo algunas preguntas:
1 Si quiero mostrar una resolucion mas pequeña como 256X224 ocupando toda la pantalla, como lo hago?
2 Puedo cargar un fondo con mas de una paleta? en plan 2, 3 o las 4?. El imagenesis tiene la opcion de 30 colores optimizado. Me imagino que combinando "plano A" + "Plano B", se podria hacer?
Lo del tema de que cuando se juntan muchos sprites algunos se borran, suele ser por juntarse demasidos sprites en la misma linea.
La megadrive no se cuantos Sprites puede mostrar en la misma linea de los 80 que tiene de maximo. Esto es lo que pone en la Wiki de la Snes:
128, 32 max per line; up to 64x64 pixels

Saludos.

Hola gradius, respondo a tus preguntas lo mejor que puedo...

1 No puedes cambiar la resolucion usando Basic. Pero supongo que si usando ensamblador, se me ocurre esta linea de codigo

ASM "move.w #$8C00,($C00004)"

ponela al principio del codigo, y deveria cambiarte a 256x224. Decime si funciona, ya que ahora estoy en el portatil de mi mujer y no tengo el basiegaxorz a mano

2 Si puedes. Hasta 31 colores, aunque no se suele usar a menudo.
Tambien puedes dividir la pantalla en varias zonas y cargar diferentes paletas, en realidad puedes hacer lo q quieras con las 4 paletas de 15 colores.

Usar menos colores, suele ayudar a reducir el uso de tiles, por eso, en mi demo del Metal Slug opte por ese camino.

3 Sobre los sprites, depende si usas 320x224 o 256x224

Que yo sepa el VDP deja de dibujar sprites, cuando alcanza los 80 en 320 y 64 en 256, tanto sea en pantalla como fuera de ella.
Se pueden dibujar 20 sprites por scanline, o 16 en 256x224

En 256x224 al tener menos carga grafica, puedes liberar vram para dibujar en offscreen


No se si me explique bien, cualquier cosa dime

Un trabajo realmente bueno, theelf, especialmente lo de la paleta de colores. Esto confirma mi teoría de que si el que programa es bueno, las limitaciones de hardware quedan en un segundo plano.

Ya que habláis de sprites en pantalla, yo creo que el problema está cuando se muestran demasiados sprites por linea. Esto se puede ver, sobre todo en megaturrican y gunstar heroes, cuando explotan los enemigos (desaparecen sprites). Si están más "repartidos", no ocurre esto.

Por cierto, tal cual está el código, cuantos enemigos podrías poner - simultaneamente - en pantalla?

theelf, podrías poner las demos del metal slug en otro sitio de descargas? Intenté descargarlas ayer y hoy pero rapidshare tiene por costumbre mandarme a tomar por saco.

the_imp escribió:theelf, podrías poner las demos del metal slug en otro sitio de descargas? Intenté descargarlas ayer y hoy pero rapidshare tiene por costumbre mandarme a tomar por saco.

+111111...1111...1111...111

theelf, podrías poner las demos del metal slug en otro sitio de descargas? Intenté descargarlas ayer y hoy pero rapidshare tiene por costumbre mandarme a tomar por saco.

Como no señor

Para MegaCD - Con musica en formato ISO+Mp3
http://www.mediafire.com/file/uuxyn0mjezg/Demo_tecnica_MS_MegaCD_-_TheElf.zip

Para Megadrive en formato Rom
http://www.mediafire.com/file/knmm45mdy2w/Demo_tecnica_MS_Megadrive_-_TheElf

Por cierto, tal cual está el código, cuantos enemigos podrías poner - simultaneamente - en pantalla?

No lo se bien, matematicamente quedaria memoria en la VRAM para 3 o 4 enemigos como mucho. Asi que teniendo en cuenta que la mayoria de los enemigos que aparecen, son clones entre si, diria que se podria logar mas o menos, el mismo numeros de enemigos que en NeoGeo


Ah por cierto, confirmo el comando de ensamblador que ayer dije de memoria

ASM "move.w #$8C00,($C00004)"

..pone el VDP en 256x224... para los que esten interesados en hacer ports de Super Nintendo 1:1 jaja

theelf escribió:

theelf, podrías poner las demos del metal slug en otro sitio de descargas? Intenté descargarlas ayer y hoy pero rapidshare tiene por costumbre mandarme a tomar por saco.

Como no señor

Mil gracias caballero

Realmente lo de poder compilar para megacd tiene su punto.

theelf escribió:No lo se bien, matematicamente quedaria memoria en la VRAM para 3 o 4 enemigos como mucho. Asi que teniendo en cuenta que la mayoria de los enemigos que aparecen, son clones entre si, diria que se podria logar mas o menos, el mismo numeros de enemigos que en NeoGeo

Pues, si es así, podría quedar algo realmente bueno.

Supongo que las mayores pérdidas estarían en la animación de los escenarios, músicas (aquí tiene ventaja el mega cd) y animación de los jefes finales. Aunque para estos últimos podríamos "hacer que se hiciese de noche" para que el 90% de las tiles estuviesen dedicadas a su animación.

Al final, el gran problema es lo que ya comentaste: demasiado curro para una sola persona.

Un trabajo increible theelf seguire este grandisimo tutorial

Gracias por la repuesta. La cosa es que el otro dia estaba intentando cargar una imagen, pero con 15 colores no quedaba muy bien que digamos, asi que le di a la opcion "30 color, 4bpp, 2 planes, 8X8 pixels, optimized" y consegui que lo cargara todo, pero realmente lo estaba cargando como si fueran dos fondos distintos y por eso no se mostraba todo a la vez. Lo que hacia era cargar primero una parte y cuando cargaba la segunda parte de la imagen, la cargaba encima.
Lo de la resolucion lo comentaba porque para hacer 4 tonterias con imagenes de Nes, Master System o la Super nintendo pues como que no necesito tanta resolucion. Asi puedo usar la memoria y todos los tiles que me "ahorro" para otra cosa.

Gracias por la repuesta. La cosa es que el otro dia estaba intentando cargar una imagen, pero con 15 colores no quedaba muy bien que digamos, asi que le di a la opcion "30 color, 4bpp, 2 planes, 8X8 pixels, optimized" y consegui que lo cargara todo, pero realmente lo estaba cargando como si fueran dos fondos distintos y por eso no se mostraba todo a la vez. Lo que hacia era cargar primero una parte y cuando cargaba la segunda parte de la imagen, la cargaba encima.
Lo de la resolucion lo comentaba porque para hacer 4 tonterias con imagenes de Nes, Master System o la Super nintendo pues como que no necesito tanta resolucion. Asi puedo usar la memoria y todos los tiles que me "ahorro" para otra cosa.

Gracias por tu interes. Veo que te ha salido bien de lo cargar una imagen en 30 colores.
Igualmente me apunto este tema para hacer un tutorial, sobre imagenes en dos planos.

Basicamente la megadrive solo puede cargar 16 colores por plano, igual que la SNES, asi que para generar mas colores,por ejemplo en un fondo, es necesario simularlo cargando varios planos.

Depende en que, usar 256x224 ayuda, y mucho, especialmente en juegos rapidos, como los de naves.Tambien, es cierto, que el poder usar esta resolucion, es una ventaja si se quieren importar graficos de juegos de SNES

Tengo preparado ya el tutorial de scroll, a ver si no tengo mucho trabajo hoy, y esta noche puedo colgarlo

realmente admirable tu trabajo, aun no he tenido tiempo para ponerlo en practica, pero de este fin de semana no pasa. sigue asi, que de aqui puede salir algo muy grande
por cierto, una pasada el metal slug, como decia un forero paginas atras, cuando hay dedicacion, las limitaciones de hardware quedan en un segundo plano.

Despues de varios dias, en los que por suerte tuve bastante trabjo, pude tener un dia de tranquilidad y programe dos ejemplos de scroll.

El primero es muy simple, pero vistoso. Consta de un plano de scroll fijo, y uno de fondo movil

El segundo, tambien simple, consta de dos planos de scroll moviles independientes.

Como explico en el tutorial, no se olviden de que el tamaño maximo de una imagen para hacer scroll es de 512x512, asi que cada uno tendra que ingeniarselas para lograr hacer scroll en una imagen de mas tamaño.

Espero con ansias las soluciones que logren a esta limitacion de hardware de la Megadrive por lo pronto, yo ya encontre varias...

theelf escribió:Basicamente la megadrive solo puede cargar 16 colores por plano, igual que la SNES, asi que para generar mas colores,por ejemplo en un fondo, es necesario simularlo cargando varios planos.

¿Se podían sacar más colores con los efectos de sombras y luces, verdad?

¿Se podían sacar más colores con los efectos de sombras y luces, verdad?

Tecnicamente? no. Solo se pueden mostrar 16 colores por plano....

la realidad? si existen varias tecnicas para lograr mas colores. Una es la que comentas de sombras/luces, creo que se pueden obtener unos 183 colores.

El problema, es que no es un efecto de hadrware, asi que tendras q programarlo tu a mano.

Una tecnica mas sensilla, es el cambio de paleta.Tu ojo no es tan rapido, asi que si intercalas las paletas en cada cuadro de animacion, tendras el efecto de mas colores.

Claro que eso conlleva un uso mas intensivo del procesador, asi que tendrias q optimizar mucho el codigo

La otra, es que programes en bloques de tiles de determinado tamaño, con una paleta propia, y cuando esten fuera de pantalla, y este otro por entrar, cambies la paleta.

O sea no tendras mas colores, pero por segundo tendras muchos cambios, asi q tambien engañarias al ojo ...

No se si me explico bien..

theelf escribió:

¿Se podían sacar más colores con los efectos de sombras y luces, verdad?

Tecnicamente? no. Solo se pueden mostrar 16 colores por plano....

la realidad? si existen varias tecnicas para lograr mas colores. Una es la que comentas de sombras/luces, creo que se pueden obtener unos 183 colores.

El problema, es que no es un efecto de hadrware, asi que tendras q programarlo tu a mano.

Una tecnica mas sensilla, es el cambio de paleta.Tu ojo no es tan rapido, asi que si intercalas las paletas en cada cuadro de animacion, tendras el efecto de mas colores.

Claro que eso conlleva un uso mas intensivo del procesador, asi que tendrias q optimizar mucho el codigo

La otra, es que programes en bloques de tiles de determinado tamaño, con una paleta propia, y cuando esten fuera de pantalla, y este otro por entrar, cambies la paleta.

O sea no tendras mas colores, pero por segundo tendras muchos cambios, asi q tambien engañarias al ojo ...

No se si me explico bien..

Perfectamente, 16 colores por plano son los que entiende el vdp.

El cambio de paleta para hacer animaciones o sacar más colores es de los trucos más viejos de la demoscene.

La verdad es que no tengo muy claro como funcionan a la hora de la verdad los efectos de shadow/highlight en la megadrive, viendo el Ranger-X/EX-Ranza parece que se generen justo antes de mandar la imagen al display, es decir no parece que toque las paletas ni los datos en memoria, si no más bien que se definen rectángulos de la pantalla a los que se sube/baja el brillo en la señal generada, de forma similar a los "raster effects" de neo-geo.

Pero vamos todo esto es un "supositorio" mio, puede que no funcionen asi.

a verdad es que no tengo muy claro como funcionan a la hora de la verdad los efectos de shadow/highlight en la megadrive, viendo el Ranger-X/EX-Ranza parece que se generen justo antes de mandar la imagen al display, es decir no parece que toque las paletas ni los datos en memoria, si no más bien que se definen rectángulos de la pantalla a los que se sube/baja el brillo en la señal generada, de forma similar a los "raster effects" de neo-geo.

Pero vamos todo esto es un "supositorio" mio, puede que no funcionen asi.

Los modos shadow/highlight, son bastantes complejos de programar, no se si podre explicarme bien

El modo shadow/highlight, se activa/desactiva usando uno de los registros del VDP, el 12 concretamente

Primero hay que entender los dos planos de scroll el A y el B, que son LP y NP respectivamente. LP es low priority, y el NP es normal priority.

Basicamente cualquier tile en el plano B NP se vera sobre uno de LP del plano A

Si se usan tiles LP en los dos planos, lo que pasara es que en cada ciclo, uno se "superpondra al otro" , generando las sombras
A eso se le suman los sprites.


Luego esta el metodo de rasterizacion, que se activa usando el interruptor H (hint). Basicamente cada linea horizontal es dibujada por el VDP entre los cilos. Si se carga una nueva paleta en el Hint 10, es parte de la pantalla se vera con una nueva paleta.

Lo que pasa es que hay que hacerlo muy rapido, ya que el 68k de la MD, solo tiene 16 ciclos antes que el retraso horizontal termine, y la nueva linea se comienze a dibujar.

Basicamente es como si hicieras el cambio de paleta antes q se termine de dibujar la pantalla, entonces te queda cortada, cada una con una paleta diferente



Me imagino que no me explique bien, y cometi algunos fallos, seguramente algun forero mas experto que yo pueda explicartelo mejor...

ando haciendo cábalas sobre el tema de las paletas, tengo una idea sobre un proyecto que era para otro sistema y queria probar una cosilla en megadrive... La idea es básicamente hacer una pasillo largo donde en base a la "iluminación" cambiara la paleta de colores del personaje y simulara esa iluminación, por ejemplo en espacios oscuros todo grises , si la luz es rojiza todo rojos , etc ...

¿Seria posible cambiarle en medio de la ejecución la paleta a un sprite o a varios sin necesidad de tocar mas cosas? , es decir definimos zonas en el mapa en las que la paleta es 0, 1 , 2 o 3 en función de lo que nos interese y otra cosa , ¿es posible determinar en el codigo todas las paletas que nos interesen e ir intercambiandolas en memoria (siempre con el limite de las 4 antes mencionadas) conforme nos interese?...

Vamos esto es a largo plazo ... aun estoy peleandome con los sprites xDDDD

PD: Si compilamos para 32x, cosa que el basiegaxorz deja (mirar TOOLS-OPTIONS-TARGET) , ¿nos quitamos la limitacion de colores por estar compilados para este sistema?

¿Seria posible cambiarle en medio de la ejecución la paleta a un sprite o a varios sin necesidad de tocar mas cosas? , es decir definimos zonas en el mapa en las que la paleta es 0, 1 , 2 o 3 en función de lo que nos interese y otra cosa , ¿es posible determinar en el codigo todas las paletas que nos interesen e ir intercambiandolas en memoria (siempre con el limite de las 4 antes mencionadas) conforme nos interese?...

Por supuesto, en realidad el truco esta en hacer paletas muy similares, para ir intercambiandolas, asi da la sensacion de mas colores.

Fijate en mi demo del metal Slug, en realidad el fondo solo tiene 16 colores, pero voy cambiando los colores de la paleta a medida que necesito un nuevo color.

ando haciendo cábalas sobre el tema de las paletas, tengo una idea sobre un proyecto que era para otro sistema y queria probar una cosilla en megadrive... La idea es básicamente hacer una pasillo largo donde en base a la "iluminación" cambiara la paleta de colores del personaje y simulara esa iluminación, por ejemplo en espacios oscuros todo grises , si la luz es rojiza todo rojos , etc ...

Para hacer eso, te aconsejo, que leas la ayuda del basiegaxorz, y te fijes en dos comandos muy utiles para lo que comentas, BRIGHTEN y DARKEN

Command_BRIGHTEN:
Syntax: Brighten <palette>, <color entry>, <increment>, <delay>, <count>
Description: Increases the color intensity of a single color entry. <palette> and <color entry> define which color entry to brighten. <increment> is a color code. <increment> is what the routine uses to increase the intensity. For example, if the color code of a defined entry was gray (0x040404), and the brighten command is used with an increment of 0x000002, then the resulting color after one loop will be 0x040406. <delay> is the number of 16.67 ms to delay each time the entry is incremented (Same delay as the Sleep command). <count> is the number of times to brighten the entry. One unit of <count> is equal to one increment.
Back to the ABC Command Index

Command_DARKEN:
Syntax: Darken <palette>, <color entry>, <decrement>, <delay>, <count>
Description: Decreases the color intensity of a single color entry. <palette> and <color entry> define which color entry to brighten. <decrement> is a color code. <decrement> is what the routine uses to decrease the intensity. For example, if the color code of a defined entry was gray (0x040404), and the darken command is used with an decrement of 0x000002, then the resulting color after one loop will be 0x040406. <delay> is the number of 16.67 ms to delay each time the entry is decremented (Same delay as the Sleep command). <count> is the number of times to brighten the entry. One unit of <count> is equal to one decrement.

En realidad es justo lo que tu buscas no?

PD: Si compilamos para 32x, cosa que el basiegaxorz deja (mirar TOOLS-OPTIONS-TARGET) , ¿nos quitamos la limitacion de colores por estar compilados para este sistema?

Si, pero te aconsejo que para comenzar primero programes para megadrive, y dejes de lado la 32x y la MegaCD.

Una vez que te manejes bien con el codigo para MD, es fundamental a mi gusto, poder compilar para MegaCD, especialmente por tres razones:
1) Es mas facil grabar un CD q hacer un cartucho, y muchisima gente tiene MegaCD
2) Dispones de espacio casi-ilimitado y pistas de audio
3) Esta perfectamente emulada en cantidad de sistemas, y se puede usar ISO+Mp3

Pero la 32x poca gente la tiene, y no esta realmente bien emulada en muchos sistemas, y mas alla de los colores, no presenta mucha mas ventajas para un programador novato.

Es mi opinion claro!!

por favor ... rapidshare es desesperante... que alguien suba los ejemplos a otro server... necesito los ejemplos de codigo y es imposible , llevo cerca de 15 intentos para descargarmelo...

Si alguien pusiera un pack con todo lo que se ha subido a megaupload o similar se lo agradeceria en exceso...

Cuales necesitas? los ultimos dos? te subo los dos a mediafire


http://www.mediafire.com/file/wj4nqvngzvx/Ejemplos%20scroll.zip


Espero mediafire te funcione bien

Interesante, para hacer hacks o roms propias, continua con este hilo, que lo veo bastante interesante

por favor ... rapidshare es desesperante... que alguien suba los ejemplos a otro server... necesito los ejemplos de codigo y es imposible , llevo cerca de 15 intentos para descargarmelo...

Si alguien pusiera un pack con todo lo que se ha subido a megaupload o similar se lo agradeceria en exceso...

Mira para que te sea mas facil, subi todos los ejemplos hasta la fecha en un solo archivo

http://www.mediafire.com/file/5kmizzqmljr/Todos%20los%20ejemplos%20hasta%2014-2-2010.zip

A todos los que rapidshare le funcione bien, prefiero que lo bajen de ahi, asi me da puntos

Muchas gracias por la ayuda , en unos dias a ver si puedo postear alguna cosilla

Bueno, viendo tanta discucion de NeoGeo y que justo estoy preparando el tutorial de scroll estatico,me dio por probar si la MD le daria para poder hacer el efecto del segundo nivel del Blazing Star, el de las columnas en 3D.

No antes comentar que tuve bastantes problemas con este codigo, ya que no lograba optimizarlo para que no se pusiera lento de muerte... pero al final entre una tarde entera de lucha con el codigo, y la ayuda de un exelente programador que conozco, se logro...

Bueno, aqui esta el rom del efecto, mas optimizado que antes, pero no tanto como quisiera, o como lo lograria un buen programador con tiempo...

Solo se usa 16 colores, y atencion, solo 533 tiles! solo el 40% de la VRAM de la Megadrive!! o sea, increible, ademas del efecto, se podria poner cantidad de sprites en pantalla sin saturar a la MD..

http://www.mediafire.com/file/2dzenwzmqyz/Scroll%20estatico.zip

impresionante!

¡¡Eres un "mostruo" tío!!

ACOJONANTE



EDITO: tras el orgasmo inicial, ya en plan sereno, de verdad que estas cositas visualmente tan impresionante animan a trastear la programación de megadrive. Te lo estás currando muchísimo. Ahora, que a pantalla completa en el Kega "cantaban" un poquito algunos tiles En serio, te ha quedado de escándalo.

theelf escribió:Bueno, viendo tanta discucion de NeoGeo y que justo estoy preparando el tutorial de scroll estatico,me dio por probar si la MD le daria para poder hacer el efecto del segundo nivel del Blazing Star, el de las columnas en 3D.

No antes comentar que tuve bastantes problemas con este codigo, ya que no lograba optimizarlo para que no se pusiera lento de muerte... pero al final entre una tarde entera de lucha con el codigo, y la ayuda de un exelente programador que conozco, se logro...

Bueno, aqui esta el rom del efecto, mas optimizado que antes, pero no tanto como quisiera, o como lo lograria un buen programador con tiempo...

Solo se usa 16 colores, y atencion, solo 533 tiles! solo el 40% de la VRAM de la Megadrive!! o sea, increible, ademas del efecto, se podria poner cantidad de sprites en pantalla sin saturar a la MD..

http://www.mediafire.com/file/2dzenwzmqyz/Scroll%20estatico.zip

¡Impresionante!

No tengo mucho mas que agregar mas que lo que dijeron otros compañeros.
Siempre y cuando el tiempo y las ganas te lo permitan no dejes de compartir estos ejemplos con nosotros. Ya que a muchos no resultan muy interesantes.

Gracias y un saludo

Acabo de probarlo en el picodrive de la dingoo y va muy bien, bastante impresionate, felicitaciones por el curro.

Acabo de probarlo en el picodrive de la dingoo y va muy bien, bastante impresionate, felicitaciones por el curro.

Gracias, me viene bien saver que el codigo q armo funciona en la dingoo


En otro hilo, me preguntaron sobre si la NeoGeo podria funcionar como una Megadrive, y esta es la respuesta que le di, la pongo repetida aqui, ya que puede ser util

Que yo sepa, a diferencia de los demas sistemas de la epoca, la neogeo no
trabaja con mapas de tiles, solamente con sprites.

las preguntas son:



Como funciona la Megadrive?: Pues basicamente puede hacer mapas de tiles
para los dos scrolls, y hasta 80 sprites en pantalla de un maximo de 32x32
tiles.

Que es un mapa de tiles? pues en base a pequeñas imagenes de 8x8 se pueden generar escenarios mas complejos repitiendolas

Aqui te hice un ejemplo, un contra muy simple con apenas 48 tiles.



Fijate como logre hacer un escenario completo con pocos tiles

Como funciona la NeoGeo?: Pues la NeoGeo solo puede representar graficos mediante sprites. Carece de la propiedad de generar mapas de tiles.
Por otro lado, los sprites pueden tener 16x512 pixeles maximo, asi que basicamente, teniendo en cuenta que tiene una resolucion de 304x224, la NeoGeo arma un nivel a base de franjas de 16x224 pixeles

Te capture un ejemplo del Metal Slug, para q veas como la NeoGeo dibuja la pantalla




Si calculamos cuantos pequeños tiles de 8x8 existen en esa pantalla es tan facil como esta cuenta:

304x224/64=1064


O sea, el ejemplo del contra necesito de 48 tiles para llenar una pantalla, mientras que la NeoGeo necesito de 1064 para la misma funcion.

Al ser franjas de solo 16 pixeles de ancho, no existe practicamente donde buscar trozos repetidos para poder ahorrar memoria, ademas que no se pueden hacer mapas en esprites.

La ventaja de la NeoGeo es obvia, permite mostar escenarios muchisimos mas complejos, ya que no necesita de andar repitiendo "tiles", pero por otro lado, es terriblemente ineficiente del punto de vista de gasto de memoria.

Para la Megadrive seria imposible lograr lo mismo que la NeoGeo, ya que si se llena toda una pantalla, se gasta toda la VRAM de la Megadrive, lo que no dejaria espacio para sprites.

Basicamente lo que yo hice, para poder saltarme este problema, y poder mostrar un escenario del Metal Slug lo mas fiel posible al original en Megadrive, es hacer que la Megadrive carge trozos de pantalla en vez de generar un mapa de tiles, justo como trabaja la NeoGeo. En vez de franjas 16x224 hice franjas de 176x224 para asi poder tener mas rango para buscar tiles repetidos.


Añado, otra pregunta.. es posible que la NeoGeo pudiera hacer un Sonic? aunque la respuesta parece de risa, teniendo en cuenta la diferencia entre las dos maquinas, realmente plantea una duda valida, ya que mientras la Megadrive puede generar todo el escenario y cargarlo en memoria, la NeoGeo tendria que ir cargandolo en tiempo real.....
seria tan rapida la NeoGeo como para aguantar la velocidad del Sonic????

theelf, acabo de probar el scroll y me ha dejado alucinado. Por un lado, por lo bien que se ve y lo fluido que va teniendo en cuenta que no es más que un "ejercicio de programación", y por otro porque en realidad sólo tenga 16 colores. Espectacular. Empieza a plantearte poner un blog sobre esto y aceptar donaciones que si con eso conseguimos un Metal Slug en Mega Drive, yo dono xD

theelf escribió:la NeoGeo tendria que ir cargandolo en tiempo real.....
seria tan rapida la NeoGeo como para aguantar la velocidad del Sonic????

Imaginemos que del Sonic sí... pero entonces del Sonic 2?? xD

theelf escribió:Bueno, viendo tanta discucion de NeoGeo y que justo estoy preparando el tutorial de scroll estatico,me dio por probar si la MD le daria para poder hacer el efecto del segundo nivel del Blazing Star, el de las columnas en 3D.

No antes comentar que tuve bastantes problemas con este codigo, ya que no lograba optimizarlo para que no se pusiera lento de muerte... pero al final entre una tarde entera de lucha con el codigo, y la ayuda de un exelente programador que conozco, se logro...

Bueno, aqui esta el rom del efecto, mas optimizado que antes, pero no tanto como quisiera, o como lo lograria un buen programador con tiempo...

Solo se usa 16 colores, y atencion, solo 533 tiles! solo el 40% de la VRAM de la Megadrive!! o sea, increible, ademas del efecto, se podria poner cantidad de sprites en pantalla sin saturar a la MD..

http://www.mediafire.com/file/2dzenwzmqyz/Scroll%20estatico.zip

Eres un máquina tio

Lo del sonic deberia de decirlo uno q sepa programar en neogeo digo yo , vamos lo lógico es pensar que si.

¡Impresionante!

No tengo mucho mas que agregar mas que lo que dijeron otros compañeros.
Siempre y cuando el tiempo y las ganas te lo permitan no dejes de compartir estos ejemplos con nosotros. Ya que a muchos no resultan muy interesantes.

Gracias, pues este fin de semana viene otro tutorial q lo tengo ya a medio hacer

theelf, acabo de probar el scroll y me ha dejado alucinado. Por un lado, por lo bien que se ve y lo fluido que va teniendo en cuenta que no es más que un "ejercicio de programación", y por otro porque en realidad sólo tenga 16 colores. Espectacular. Empieza a plantearte poner un blog sobre esto y aceptar donaciones que si con eso conseguimos un Metal Slug en Mega Drive, yo dono xD

Bueno, primero, muchas gracias. Segundo, lo del blog desde la primera vez q lo dijistes le estoy dando vueltas en la cabeza.

Personalmente tengo poco tiempo, pero me gustaria muchisimo poder avanzar con mis proyectos. El problema, es que realmente, estoy programando un juego RPG para la Megadrive, y trato de destinar mi tiempo a ese juego. Estos ultimos dos meses lo deje un poco de lado, por el tutorial, pero no es mi idea.

Lo del sonic deberia de decirlo uno q sepa programar en neogeo digo yo , vamos lo lógico es pensar que si.

Opino lo mismo. Programe un tiempo para NG, pero ya me he olvidado de mucho lastima.

Si tuviera que apostar, diria que en principio no, pero, el mismo no vale para "se puede hacer el segundo nivel del Blazing Star en Megadrive?" jajaja, y esta claro que se podria, todo depende del programador.

El principal lastre de NeoGeo es que para hacer un escenario del Sonic, el gasto de memoria seria enorme.

El ejemplo del escenario del contra es muy bueno, porque en esa captura el escenario queda bastante aceptable pero cuando se está jugando y evidentemente no pudiendo estar apreciando tanto los detalles del escenario no se crea una sensación de continua repetición de partes del escenario.

Los enlaces de mediafire no me van, ¿ soy el único ?

Estoy buscando en algo en que pasar el tiempo y podia ser esto.
Haber si te animas y explicas mas, pero de manera facil.

Un saludo y animo.

Estoy buscando en algo en que pasar el tiempo y podia ser esto.
Haber si te animas y explicas mas, pero de manera facil.

Un saludo y animo.

No se me ocurre realmente como explicarlo mas facil, en realidad Basiegaxorz es facil desde 0.

Pero si necesitas alguna explicacion en concreto, o tienes algo en mente y necesitas un ejemplo explicado, pidemelo que encantado lo hago

Hola!
Hace tiempo que conozco y uso basiegaxorz, incluso hace unos años hice un curso de programacion en basic e hice algunos juegos sencillos que luego porté a megadrive. Actualmente quiero hacer una especie de rom/recopilacion de estos juegos con las versiones retocadas, en quanto lo termine o tenga algo decentillo lo posteo, y si el tiempo tambien me lo permite, jeje.

Bueno, despues de la tocho/presentacion ahí va mi duda, Theelf tengo un pequeño problema, como bien comenté en el foro de devster, a la hora de intentar cargar un mapa grande me da errores gráficos. Verás, cargo una pequeña porcion y no hay problema al hacer scroll, en cambio cuando cargo un mapa mayor al ejecutar el código en el emulador solo se ven los sprites deshordenados. Qual puede ser el problema? o mejor dicho, de qué manera se cargan mapas mayores a 64 tiles? Gracias de antemano!

Hola abokys, un placer conocerte y espero puedas llevar todos tus proyectos a buen puerto!!

Al grano, como sabras, el tamaño maximo de un mapa es de 64x64 tiles o sea 512x512 pixeles

Para solucionar este problema, Mairtrus del foro de basiegzorxz creo un codigo muy bueno, echale un ojo, y lo discutimos

http://www.fileden.com/files/2007/11/30/1616239/scroll.zip

Soluciona el problema que planteas, ya que permite cargar mapas de cualquier tamaño, mientras no tengan mas de 1343 tiles, o sea la vram de la Megadrive

Te adjunto aqui un ejemplo echo por mi, con un "nivel" de mi juego RPG, fijate, que el mapa es de exactamente 1024x224 pixeles, o sea el doble de lo q permite la megadrive

http://rapidshare.com/files/354634008/scroll2.zip

Entre los dos, podras darte cuenta que cambiar para poder hacer mapas mas grandes

suerte!

EDITO: En el segundo codigo, el q tiene el grafico mio, me olvide de cambiar una cosa, donde dice

Const #Rightboundary = 399

Cambialo por

Const #Rightboundary = 704

Disculpa, se me escapo

Ya dí con la solucion. Se me pasaron algunas cosas al parecer importantes. Gracias por la ayuda, Theelf. Que este tutorial no decaiga!