Tutorial programacion Megadrive - Basico

theelf escribió:Por dios, decime que no convertistes las imagenes una a una en el imagenesis...y si encontrastes un modo batch o similar... compartelo con el mundo....

malas noticias, hice eso exactamente . la mala calidad de las imagenes, es justamenete por causa de imagenesis, si ubiera usado tile molester en su lugar, se vería mucho mejor pero me llevaría 10 veces mas tiempo.
Como dato curioso, cada imagen la convertía en aprox 5 seg cada una, use 245 fotogramas y lo arme una noche muy aburrida

MateoD escribió:¿Alguien puede ayudarme en mi duda?

crei que ya solucionaste tu problema de sprites

MateoD escribió:No importa theelf, ya lo solucione, era que el sprite debía ser de 24x16 y era de 24x17 .

Que los links de dream comics están caídos y el fondo del ejemplo que me mandaste está estirado.

Saludos

MateoD

Que los links de dream comics están caídos y el fondo del ejemplo que me mandaste está estirado.

Cuando tenga tiempo vere la web

Sobre el fondo de mi ejemplo, es el mismo q tu subistes. El mismo bitmap

No veo diferencia alguna

Es porque tenes activado el use ntsc aspect en el kega fusion, desactivalo, y compara la foto del ejemplo

...

Es porque tenes activado el use ntsc aspect en el kega fusion, desactivalo, y compara la foto del ejemplo

Esa captura es con el NTSC aspect desactivado

Tu imagen es PAL, asi que yo la adapte a NTSC, recortando 8 pixeles arriba y 8 abajo, asi mantiene la misma proporcion al verse en una TV PAL

Si quieres verlo en una TV NTSC, y mantener el aspecto, pues se tiene que redimensionar la imagen, ya que el original es PAL (320x240)

Al menos asi lo entiendo yo....

Si quieres sube tu codigo asi se puede ver, auqneu creo q no voy mal encaminado

matuanime: yo uso parte del codigo de theelf por una cosa del movimiento de los aviones.

theelf: ¿no podrías mandarme el código tuyo sin recortar esos 16 pixeles?

Saludos

MateoD

theelf: ¿no podrías mandarme el código tuyo sin recortar esos 16 pixeles?

ok, aqui lo tenes, PAL 320x240

Acordate de poner el emulador en EUR, o lo veras recortado

http://www.akihabara-online.com/Megadrive/ejemplos/testPAL.zip

lo probe en emulador y anduvo, pero lo probe en la sega gopher y la pantalla empezaba a dar vueltas y vueltas y vueltas y vueltas y vueltas y vueltas y vueltas...

yo simplemente pido que me des tu ejemplo con la imagen a 320x244, solo eso.

yo simplemente pido que me des tu ejemplo con la imagen a 320x244, solo eso.

320x224 = NTSC = Primer ejemplo
320x240 = PAL = Ultimo ejemplo

320x244 = No existe

Veamos...

La imagenq ue tu subistes, tiene una resolucion de 639x479, asi que asumo que es 640x480. Eso dividido 4, da 320x240 que es PAL

Si tu imagen original era NTSC o sea 320x224, la captura la hicistes erronea. Imagino que tu "original" seria algo asi, y quedo deformado en tu captura de pantalla



Piensa que si yo veo una imagen de 640x480 asumo que es PAL, y si la captura es 640x448 asumo que es NTSC, y que se duplicaron los pixeles para que sea mas facil de ver en el foro

Es tan facil como poner esa imagen que he echo en imagenesis, y volver a hacer el fondo. Tendras que retocar algunos parametros, de tiles, posx,posy de los elementos...etc , nada, 5 minutos de trabajo

Si no te sale, pues, subeme el archivo original a 320x224

lo probe en emulador y anduvo, pero lo probe en la sega gopher y la pantalla empezaba a dar vueltas y vueltas y vueltas y vueltas y vueltas y vueltas y vueltas...

Lo acabo de probar en una Megadrive real, y funciona correcto.

Lamentablemente no tengo una gopher, pero me resulta interesante saber que es "vueltas y vueltas"

MateoD escribió:lo probe en emulador y anduvo, pero lo probe en la sega gopher y la pantalla empezaba a dar vueltas y vueltas y vueltas y vueltas y vueltas y vueltas y vueltas...

yo simplemente pido que me des tu ejemplo con la imagen a 320x244, solo eso.

Esto me recuerda a la escenita...
http://www.youtube.com/watch?v=Iw8PSN-S9-s

Esto me recuerda a la escenita...
http://www.youtube.com/watch?v=Iw8PSN-S9-s

JAJAJAJA, buenisima!!

Si habre visto esa obra de arte... pelicula

Nono, es de los simpsons, en el capi donde hay gripe que viene de japom y el reportero del helicoptero dice "el noseque de la 102 esta dando vueltas y vueltas y vueltas y vueltas..." se marea y vomita afuera del helicoptero y adivinen que pasa...

bueno, dejemos de desvirtuar el tema

MateoD escribió:lo probe en emulador y anduvo, pero lo probe en la sega gopher y la pantalla empezaba a dar vueltas y vueltas y vueltas y vueltas y vueltas y vueltas y vueltas...

yo simplemente pido que me des tu ejemplo con la imagen a 320x244, solo eso.

bueno yo lo probe en mi mp5 simil psp y directamente no carga se pone la pantalla en negro y muere. tengo que apagar y volver a prender.
lo que me llama la atencion es que el ejemplo de paletas que me subio theelf funciono perfecto

disculpen la calidad es que lo saque con el celular

Theelf mi fondo era este:

http://www.imagenes.alterengine.net/images/missilestr.bmp

Yo haría eso de cambiar simplemente el fondo, pero en tu ejemplo no es tan sencillo. Usaste algo de queseyo_map y eso no lo entendi, y ademas ese codigo de plano1 es una imagen de 256 px , se que es algo de mapa de tiles, pero no entendi como se hacía, porque el ejemplo de mapas de tiles fue borrado de rapidshare. Además, tu parte de drawtiles16 no entendi nada, porque es ASM

Tuve un poco de tiempo, asi que arregle los links. De forma momentanea los subi a mi diminio personal, hasta q pueda arreglarlos bien

Sobre de del uso de un mapa, tendras que leer los tutoriales de nuevo, ya que lo explico bien

Los 256 no son el tamaño en pixeles, si no los tiles que usa el grafico, de nuevo, en el tutorialesta el comando bien explicado

LoadTiles planoA,256,256

Es lo mismo que:

Cargar 256 tiles que ocupa el planoA en la posicion 256

Sobre el comando ASM, si no entiendes, puedes dibujar la pantalla en basic, es lo mismo, y la diferencia es minima. Tambien esta explicado en el tutorial


Cambia:

drawtiles16 lblptr&(planoA_map),0,0,40,28,256+pallette(0)+priority(1)

Por:

Dim Map(39,27) as Integer 'Creamos un mapa de 40x28 tiles

reload planoA_map 'Cargamos el mapa

For Y=0 to 27 'la imagen tiene 40x28 tiles, asi que cargamos todos los tiles, del Y=0 al 27
For X=0 to 39 'al X=0 a 39
readint Map(X,Y) 'Y leemos el mapa
Next X
Next Y

For Y=0 to 27
For X=0 to 39
DrawTile Map(X,Y)+pallette(0)+1,X,Y 'Y dibujamos una pantalla completa, leyendo el mapa,
Next X 'usando la paleta 0, y comenzando del tile 1
Next Y 'Siempre en direccion primero X luego Y

bueno yo lo probe en mi mp5 simil psp y directamente no carga se pone la pantalla en negro y muere. tengo que apagar y volver a prender.
lo que me llama la atencion es que el ejemplo de paletas que me subio theelf funciono perfecto

No tengo un mp5, pero probe las dos roms (ntsc, y pal) en mi movil, y funcionan correctas

Por referencia, mi movil tiene android y el emulador es el gensoid

miren este video de megadrive reproduciendo un videoclip psicodelico con musica super pegadisa hasta 30fps
http://www.youtube.com/watch?v=lbAxuFgQ ... u_in_order
lo que mas me intereso, es que al pareser, usa solo un bitplane, por lo que logro comprimir 3:50 de video en solo 3mb y dice que esta mal optimizado jeje

matuanime escribió:miren este video de megadrive reproduciendo un videoclip psicodelico con musica super pegadisa hasta 30fps
http://www.youtube.com/watch?v=lbAxuFgQ ... u_in_order
lo que mas me intereso, es que al pareser, usa solo un bitplane, por lo que logro comprimir 3:50 de video en solo 3mb y dice que esta mal optimizado jeje

Porque narices cambia el plano al iniciarse el supuesto "video-rom"??

Theelf, el link de dream comics del ejemplo de audio aún está roto. Probé con eso que me dijiste en el código, y se ve todo negro

Arregle el link del sonido, y aqui tienes el ejemplo programado 100% en basic

http://theelf-megadev.com/ejemplos/test%20basic.zip


Lo unico que hice fue reemplazar el codigo ASM por Basic como te dije en mi anterior post.

Agrege un disable/enable screen para que el dibujado no se haga mientras la pantalla esta visible, pero eso es opcional

SIIIII THEELF!!!!!!!!!!! MIL GRACIAS!!!!!!!!!! FUNCIONA COMO YO QUERÍA!!!!!!!! MIL GRACIAS!!!!!!!

Perdón, es que me emociono fácilmente

Saludos

MateoD

Me alegro que funcionase


que ya haz avanzado algo mas en el codigo? ya dispara?

theelf escribió: haz avanzado algo mas en el codigo? ya dispara?

sip ya dispara
me atrase bastante con el codigo por que lo reescribi completo, por que era muy complicado ampliarlo.
ahora hago todo atravez de subrutinas, porl o que si quiero agregar, cambiar o sacar algo es mucho mas simple.
ya tengo el joystick funcionando casi al 100% muevo el sprite del enemigo por programa, tambien el scroll. Y controlo el 100% de funciones hasta el momento asignadas al personaje (arriba, abajo, derecha, izquierda, disparo y pausa)
aca esta el demo
http://www.megaupload.com/?d=1A86QK1L

lo proximo que voy a hacer es:
_agregar deteccion de coliciones
_optimisar tanto paletas como tiles(en este demo ya no hay tiles libres y use las 4 paletas )
_agregar mas enemigos e implementar disparo dirigido tanto para enemigos como para jugadores
_agregar "puntaje" y "vidas"

supongo que el puntaje y las vidas seran sencillas una vez que tenga la deteccion de coliciones
espero que les guste mi trabajo y me puedan dar algunas ideas

Este es uno de los hilos que mas me gustan de EOL. Felicidades a Elf y cia. Yo estoy aprendiendo en otro lenguaje (C y SDL) pero voy curioseando por aquí, que nunca esta de mas saber cosas nuevas.

Una duda que tengo y llevo días dándole vueltas. En uno de los tutoriales Elf comenta como hacer un escenario a base de tiles. Esa parte la entiendo pero la duda es: como hacen para definir un nivel completo ? Me refiero a mapas medianos como un nivel de MarioBros o Green Hill de Sonic 1. Y ya no digamos niveles enormes como los de Sonic 3.

Meten el nivel en un gigantesco array? O lo hacen de otra forma? (entiendo que debido a la poca RAM que se disponen descomprimen datos al vuelo),

64kB es más que decente. Yo creo que lo ideal es un mapa vacío e ir añadiendo "objetos" al plano vacío, de forma que donde no haya nada no hayan datos a almacenar

socram8888 escribió:64kB es más que decente. Yo creo que lo ideal es un mapa vacío e ir añadiendo "objetos" al plano vacío, de forma que donde no haya nada no hayan datos a almacenar

si no me equivoco, asi estan programados la mayoría de juegos de nes (sin mapper) por que de otra forma dibujar en el scroll, te ocupa hasta 1kbyte de memoria, lo que resta mucho considerando que para para programa solo se disponía de 32kbyte como maximo.

por otro lado, hacer eso en megadrive, puede que no sea lo mejor, porque resta mucha velocidad al procesador (aunque los primeros juegos puede que lo hagan).supongo que la solución mas rapida, tiene que ser trabajar con arrays.

ojala algun día theelf tenga tiempo y explique como usarlo con basic

Yo la demos que hice de shinobi (en basic), tenia un array con el nivel entero y otro con todos los tiles del nivel pero guardado en la rom para no ocupar vram ni ram (los niveles del shinobi no ocupa apenas vram). Como un plano son 512x512 y la pantalla mide 320, se rellena el mapa de 512 y según hacia scroll modificaba la parte que quedaba fuera de la pantalla actualizando esete mapa con la parte siguiente que tocara del array del nivel. Para niveles muy gordos pues se usan varios arrays con cachos del nivel. Imagino que thelef haría algo así para el metal slug pero actualizando los tiles del nivel.

pocket_lucho escribió:Yo la demos que hice de shinobi (en basic), tenia un array con el nivel entero y otro con todos los tiles del nivel pero guardado en la rom para no ocupar vram ni ram (los niveles del shinobi no ocupa apenas vram). Como un plano son 512x512 y la pantalla mide 320, se rellena el mapa de 512 y según hacia scroll modificaba la parte que quedaba fuera de la pantalla actualizando esete mapa con la parte siguiente que tocara del array del nivel. Para niveles muy gordos pues se usan varios arrays con cachos del nivel. Imagino que thelef haría algo así para el metal slug pero actualizando los tiles del nivel.

En Gameboy lo que hacia era hacer varios arrays del mapa y caragarlos de ROM a RAm segun los requeria, como el Z80 solo direccionaba bancos de memora de 32kb, a la hora de compilar la rom, especificaba en que banco guardaba cada array

Una duda que tengo y llevo días dándole vueltas. En uno de los tutoriales Elf comenta como hacer un escenario a base de tiles. Esa parte la entiendo pero la duda es: como hacen para definir un nivel completo ? Me refiero a mapas medianos como un nivel de MarioBros o Green Hill de Sonic 1. Y ya no digamos niveles enormes como los de Sonic 3.

Meten el nivel en un gigantesco array? O lo hacen de otra forma? (entiendo que debido a la poca RAM que se disponen descomprimen datos al vuelo),

Hola, siento no haber contestado antes.Pocket_lucho fue bastante claro en la respuesta.

En todo caso, no hay un metodo estandar, aunque lo normal es hacer un array de tiles, con el nivel completo

Depende mucho de la complejidad del escenario, asi en el ejemplo que hice del Metal Slug, devido a la cantidad de tiles, siquiera me daba la vram para llenar los 512 pixeles de ancho del buffer, asi que redibujo en "tiras" de 64pixeles

Devido a que tiene que estar continuamente cargando, solo redibujo durante los momentos libres del procesador, al finalizar cada barrido vertical

En realidad basicamente copie la manera de trabajar de la misma NeoGeo

saludos

Una cosilla, ¿usabas una paleta para todo el nivel o la cambiabas de vez en cuando?

pocket_lucho escribió:Una cosilla, ¿usabas una paleta para todo el nivel o la cambiabas de vez en cuando?

Hola maestro, pues, en general en el demo del Metal Slug, usaba una paleta cada 192 pixeles aproximadamente, pero devido a la proximidad de los graficos, lo normal fue usar dos paletas de fondo, y una o dos asignadas para sprites.

Aunque a veces tuve que tirar de usar una de las paletas de los sprites para el fondo, por eso, eleji colores genericos y bien "intercambiables"

En otras ocaciones, con solo cambiar uno o dos colores de la paleta, era suficiente para representar las siguientes tiras de tiles, asi que justo en el momento que un color no se ve mas en pantalla, intercambio la paleta

Trate de optimizar lo mejor posible, pero bueno, no soy profesional, seguro se puede mejorar mas....


En este caso, uso 3 paletas, y me reservo la cuarta para objetos, o "extras"

Maestro no por dios, en todo caso tu Menuda curada lo que hiciste con el cambio de paletas.

Yo sigo liado con mi juego pero la cosa avanza muy bien, diría que está al 80% o así, para el retromadrid la idea es sacarlo aunque espero terminarlo para fin de año, una capturita de la pantalla de titulo ;9

Sois unos cracks chavales... madre de dios, lo que se ha perdido la escena de la snes con vosotros dos

Bueno, por ahora me centro en megadrive pero eso no quita que me interesen otros sistemas como snes o neogeo, pero como hay que empezar con algo (y la idea es hacer cosas en físico), la megadrive es el punto de partida ideal para esto. Theelf, ¿tu comentaste que hace tiempo hiciste cosas en c para snes verdad? Es que si hay la posibilidad seria interesante hacer algo sencillo o intentar portar algo. En neogeo si se usa C y ya he hecho alguna prueba (controles, capa fix y paletas, me quedé en los sprites...), la pega es el coste de fabricacion, los precios de los chicos de neodev me asustan

Recopilacion de algunas de mis 'cosillas' en basic y C:









Y las pruebas de neogeo:

Usar C en SNES tiene que ser frustrante, de un space invaders no pasas

¿Que tal va tu juego?

Bueno, la lógica del juego podría ser en c y las rutinas de carga/dibujado/movimiento/etc. en ensamblador. Por mala que sea la cpu se podrían hacer cosas interesantes, que tampoco hace falta hacer el contra 3 Juegos divertidos y muy poco exigentes que se podrían hacer pues algo del estilo pacman, donkey kong, puzzles, pang o incluso un metal gear a lo msx. Hay que ver los recursos disponibles y adecuarse, si no se puede poner 80 sprites en pantalla... pues se hace algo con 4 y sin scroll, estrujarse la cabeza como se hacia en los ordenadores de 8 bit vamos

Na, mi juego va bien, como un juego de naves era mucha faena para empezar, me puse con un remake del oh mummy de amstrad, tiene 2 partes, la parte clásica igual que la de 8 bit (que ya está terminada, es la captura de arriba) y la parte remake con gráficos nuevos, ítems nuevos, varios tipos de fases, 2 jugadores, etc. que yo diría que está al 85% (ahora mismo me falta añadir una fase de bonus, el jefe final, la intro y quitar bugs). Temas técnicos como música (fm), sonido (psg), controles, sprites, scrolls ya están solucionados. Haciendo rasters a pantalla completa con 2 jugadores, 12 enemigos y sus IAs (hay algo de búsqueda de caminos y tal) sigue funcionando a 60 fps, a lo mejor en snes iría a 30 usando C, tampoco creo que sea una desgracia. Lo más difícil sin duda ha sido programar la IA de las momias, em amstrad que enganchaban un montón, las mías funcionan prácticamente siempre A mi al menos me parece divertido como juego de puntuación a lo pacman y es 'woman friendly'.

Hay cosas que no se usar como utilizar DAC con FM, o PCM con FM pero bueno, para el próximo juego

bueno aca les pongo el codigo de deteccion de colision.
por si les sirve para su juego
ya solo me falta ponerselo a mi juego pero primero quiero terminar de optimizar las paletas



si tienen duda compilenlo que funciona de una, cualquier cosa me avisan
pd: lo quise poner como codigo y como splioler pero borra los espacios al principio por eso para que funcione le tienen que poner un espacio a cada linea al principio con esepcion de:
colision1:
lanzam:
misil:

Buenas, estoy escribiendo esto del telefono movil, asi que no puedo probar tu codigo, pero si que veo que es una colicion con sprite de 1x1

Tienes codigo de colicion para sprites de 4x4? es que busco diferentes formas que tiene cada uno de resolver el tema

theelf escribió:Buenas, estoy escribiendo esto del telefono movil, asi que no puedo probar tu codigo, pero si que veo que es una colicion con sprite de 1x1

Tienes codigo de colicion para sprites de 4x4? es que busco diferentes formas que tiene cada uno de resolver el tema

si lo unico que hay que hacer es cambiar la subrutina del final


por



ahora si usas blancos de distinto tamaño
usaría otras variables mas que serían "anchoblanco" y "altoblanco"
y quedaría asi



logicamente, antes de llamar a la subrutina, tengo que especificar el tamaño en pixels tanto para "anchoblanco" como para "altoblanco"

Hola tronkos:

Me estoy currando una versión de Metal Slug para la Nintendo NES, si, si, la de 8 bits. Tengo unos problemas con las paletas y los colores que flipais, pero por ahora simplemente estoy haciendo al personaje que se mueve de un lado para otro. Espero sacarle partido al 6505 de la NES y conseguir avances. Os dejo una demo y varias capturas, a ver que os parece.




ROM demo: http://www.megaupload.com/?d=Y47DBZLQ

Que problemas tienes con las paletas? de codigo o de diseño? en 8bits la seleccion acertada de las paletas es fundamental para que el juego luzca bien.
Yo en NES no sé, pero he hecho juegos en GBC bastante vistosos en colorido con la limitadisima paleta de la gameboy color.
Un ejemplo, esta conversion de Sonic para GBC que hice en 2001 para un concurso de programacion:


En tu caso puedes tomar como referencia el Metal Slug de NeoGeo Pocket Color, que es la conversion de SNK a un sistema limitado graficamente.

ANIMO!!

Diskover escribió:Hola tronkos:

Me estoy currando una versión de Metal Slug para la Nintendo NES, si, si, la de 8 bits. Tengo unos problemas con las paletas y los colores que flipais, pero por ahora simplemente estoy haciendo al personaje que se mueve de un lado para otro. Espero sacarle partido al 6505 de la NES y conseguir avances. Os dejo una demo y varias capturas, a ver que os parece.




ROM demo: http://www.megaupload.com/?d=Y47DBZLQ

jeje parece que theelf tiene competencia

no, enserio, que bueno sería poder ver estos juegos en clasicas de 8 o 16bits.
yo estoy viendo si es viable una conversion de cadillacs & dinosaur para megadrive (lo mas fiel posible).
pero ya hace como un mes que no escribo ni una linea de codigo.

por cierto ¿alguien sabe cual es el tamaño maximo que puede tener un cartucho de megadrive?

Los chinos me han comentado que 64 megas.

Como máximo real 256MBit. Aunque por medio de una combinación electronica+sofware se podría alcanzar 512MBit

16MBits (4Mb) y de ahi para arriba con controladores de bancos de memoria como Super SF II, Pier Solar (64MBit)

Bertop, ¿4 MB no son 32 Mbits?

pocket_lucho escribió:Bertop, ¿4 MB no son 32 Mbits?

jajajaja si,deberia repasar la tabla de multiplicar jajaja

Bunas, ya se que no viene a cuento del hilo, pero como algunos sabran estoy pasando las fiestas con mi novia en Japon, ella vive aqui.

Pues, el otro dia, fuimos a comer a la casa de una amiga de ella, y charlando de tonterias, resulto que el marido, ken, trabajaba en Sega como programador! en los 80 y 90s. Menuda sorpresa

Pues, nos pusimos a hablar y le mostre mi web y este foro, quedo asombrado de todo el movimiento. Me dijo que no tenia ni idea que alguien aun tuviera interes en la megadrive !

Moraleja, me lleve una megadrive+megacd1 que Ken ya no usaba mas, y un monton de consejos

Dijo que cuando tuviera tiempo, se daria de alta en el foro, espero q algun dia lo haga!

theelf escribió:Bunas, ya se que no viene a cuento del hilo, pero como algunos sabran estoy pasando las fiestas con mi novia en Japon, ella vive aqui.

Pues, el otro dia, fuimos a comer a la casa de una amiga de ella, y charlando de tonterias, resulto que el marido, ken, trabajaba en Sega como programador! en los 80 y 90s. Menuda sorpresa

Pues, nos pusimos a hablar y le mostre mi web y este foro, quedo asombrado de todo el movimiento. Me dijo que no tenia ni idea que alguien aun tuviera interes en la megadrive !

Moraleja, me lleve una megadrive+megacd1 que Ken ya no usaba mas, y un monton de consejos

Dijo que cuando tuviera tiempo, se daria de alta en el foro, espero q algun dia lo haga!

QUE NOTICION!!!!

Te esperamos Ken!!!

Ostras, que noticion si, le esperamos con los brazos abiertos aunque sea solo para contarnos batallitas!!

Por cierto, aprovecho para comentar que mi oh mummy está cercano a su fin y que como en el cartucho me sobra espacio (es de 64 megas y ocupo 8-12), si alguien tiene algo interesante para poner (y que no me crujan luego por copyrights) pues será bienvenido.