Tutorial programacion Megadrive - Basico

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