Trabajo tiles megadrive

Buen curro, y la imagen queda bastante fiel al original, pero imagino que en el momento que se quiera animar el fondo todo se va al garete o me equivoco?

por otra parte seria interesante hacer la misma imagen pero con la super nintendo para ver hasta donde puede llegar en el tema de los tiles, si esta mas cerca que mega drive o de neo geo.

salu2

Genial, qeu currada te has pegado macho. Según lo que muestras, una cosa muy parecida al last blade podría ser viable, si es que la cantidad de información que debe pasar por el bus, no es demasiada (animación de los personasjes + la animación compleja de todo el escenario, etc). Kuego está la pega de los sprites extras que soponen las magias, y otras historias, como la sombra, o si se levanta algo de polvo cuando un personaje cae, que tambien necesita de sprites extras...

En teoría, la CPU de la megadrive podría ser lo suficientemente potente para manejarlo todo, pero problema está quizás en como viaja la información.


...Gran trabajo, repito. Muy instructivo


EDIT:

Buen curro, y la imagen queda bastante fiel al original, pero imagino que en el momento que se quiera animar el fondo todo se va al garete o me equivoco?

No si no se sobrepasa el limite de 966 tiles que quedaban despues de crear a los personajes. El usó 960, así que de hecho, le sobraban 6... el problema es si hay capacida para sustituir todos los tiles necesarios al mismo tiempo, para animar ese escenario. Es una cuestión del bus de la consola, y en ultima instancia, de la cpu.

interesante información, gracias por compartirla

Supongo que ya lo has visto, pero por si acaso, échale un ojo a un video que hicieron para ver como cambia los tiles de la vram la megadrive:
http://www.youtube.com/watch?v=SPF5qrgvGYg

No estoy muy deacuerdo con la explicación de que la capacidad de la rom fuera la única causa de que los juegos no conserven todos los frames ni el tamaño de la versión original, ya que el espacio en la ram y vram es bastante limitadora, y la velocidad de la cpu te limitaría el nº de frames a intercambiar por segundo.

Buen curro, y la imagen queda bastante fiel al original, pero imagino que en el momento que se quiera animar el fondo todo se va al garete o me equivoco?

En realidad, si te fijas, en la imagen de NeoGeo hay varios tipos de fuegos. Pero en mi imagen, para ahorrar tiles el fuego el el mismo en varias partes. Asi que animar el fuego, seria relativamente facil, y sin demasiado gastos de tiles.
Ademas se podria complementar la animacion con un cabio de paleta para el fuego (amarillo por naranja, naranja por rojo, rojo por naranja, naranja por amarillo...por ejemplo)

Aqui te marco los fuegos repetidos, para que veas que con pocos tiles, podria animar gran parte del escenario

Kuego está la pega de los sprites extras que soponen las magias, y otras historias, como la sombra, o si se levanta algo de polvo cuando un personaje cae, que tambien necesita de sprites extras...

Habria que buscar alternativas o prescindir de efectos no muy importantes.En caso de las magias, ya se cuenta con eso. Fijate que Lee por ejemplo solo usa 70 tiles, pero yo le cuento con 110.

En caso de un luchador que ocupara muchos tiles, una posible solucion seria recortar un poco aqui y alli en sus magias, o en el momento de estas, como se saven cuando seran,descargar algo de memoria

No estoy muy deacuerdo con la explicación de que la capacidad de la rom fuera la única causa de que los juegos no conserven todos los frames ni el tamaño de la versión original, ya que el espacio en la ram y vram es bastante limitadora, y la velocidad de la cpu te limitaría el nº de frames a intercambiar por segundo.

Bastente no, limitadisima diria yo. Justamente por eso todo este trabajo. Yo podria cargar los 960 tiles para el trozo que se ve en pantalla, y dejar el fondo tal cual NeoGeo, y a medida que se hace el scroll, ir creando dinamicamente el trozo de escenario que falta.
Pero ahi me topo con el CPU de la megadrive, supongo que ya es demasiada carga.

Una pregunta, ¿no tienes tileado y repetido el suelo? Esa parte también podrías trucarla para que se repitiera, la mitad inferior izquierda hasta el centro es prácticamente igual, así supongo que salvarías más vram para otros sprites. Sino, yo intentaría recrear todo el fondo de forma que se repitiera el máximo nº de tiles (vale quedaría más cutre, pero tendrías espacio para otras cosas y quizás pudieras moverlo más rápido). De mover el escenario en megadrive no tengo mucha idea, pero creo que con un poco de optimización sí que debería de moverlo sin muchos problemas.

Una pregunta, ¿no tienes tileado y repetido el suelo? Esa parte también podrías trucarla para que se repitiera, la mitad inferior izquierda hasta el centro es prácticamente igual, así supongo que salvarías más vram para otros sprites. Sino, yo intentaría recrear todo el fondo de forma que se repitiera el máximo nº de tiles (vale quedaría más cutre, pero tendrías espacio para otras cosas y quizás pudieras moverlo más rápido). De mover el escenario en megadrive no tengo mucha idea, pero creo que con un poco de optimización sí que debería de moverlo sin muchos problemas.

En realidad el suelo, no deven ser mas de 50 tiles repetidos hasta el cansancio en realidad, casi todo esta repetido 2 o 3 veces minimo

el escenario asi como esta se puede mover perfectamente en megadrive

Lo de recrear el fondo, es aun mas trabajo que lo que hice aun. Yo basicamente fui buscando patrones, repitiendolos, y dejando de un solo color algunas zonas. Pero rehacer un escenario, es un trabajo muy laborioso, digamos, que tendrian que pagarme para perder tantas horas... aunque si se hiciera de comienzo, tal vez podria dejarse en 500-600 tiles aprox, aunque no se veria tan fiel a la NeoGeo

theelf escribió:Lo de recrear el fondo, es aun mas trabajo que lo que hice aun. Yo basicamente fui buscando patrones, repitiendolos, y dejando de un solo color algunas zonas. Pero rehacer un escenario, es un trabajo muy laborioso, digamos, que tendrian que pagarme para perder tantas horas... aunque si se hiciera de comienzo, tal vez podria dejarse en 500-600 tiles aprox, aunque no se veria tan fiel a la NeoGeo

Dejarlo en 500/600 tiles es innecesario, no necesitas ahorrar tanto, porque las animaciones del escenario no creo que ocupen el deficit de tiles... bueno, tu sabrás a lo que me refiero. Los personajes, tampoco van a hacerlo. Ahorrar tanto en tiles si podría ser si quieres meter personajes enormes, pero no es el caso.

Dejarlo en 500/600 tiles es innecesario, no necesitas ahorrar tanto, porque las animaciones del escenario no creo que ocupen el deficit de tiles... bueno, tu sabrás a lo que me refiero. Los personajes, tampoco van a hacerlo. Ahorrar tanto en tiles si podría ser si quieres meter personajes enormes, pero no es el caso.

Bueno, un ahorro de tiles ayudaria en cuanto al tamaño del juego. Si lo programas para megacd no importa, en cambio si solo se dispone de 512kb la cosa cambia. Pero si, para las pruebas que hago, tienes razon,es innecesario trabajar tanto la imagen, por eso parti de una captura de NeoGeo y no de 0

Creo que cada tile son aprox 20 bytes, asi que si se pueden ahorrar 300 tiles son 6.5kb! wow, te da suficiente espacio para instalar el Crysis

vaia currazo tio! felicidades

una cosa: para compilar esto cómo lo haces? programas en assembler?

vaia currazo tio! felicidades

una cosa: para compilar esto cómo lo haces? programas en assembler?

Gracias. No esta programado en basic (aunq no me creas)

theelf escribió:

vaia currazo tio! felicidades

una cosa: para compilar esto cómo lo haces? programas en assembler?

Gracias. No esta programado en basic (aunq no me creas)

¿pero para ejecutarlo en megadrive cómo lo haces? tendrás que compilarlo a partir de asembler no?

Supongo que habrá usado Basiegaxorz.

Supongo que habrá usado Basiegaxorz.

Si efectivamente. Basiegaxorz compila para 68k del megadrive

Supongo que ya deve haber algun tutorial en elotrolado de basiegaxorz no?

andoba escribió:Supongo que habrá usado Basiegaxorz.

ok, gracias. no sabía de la existencia de este compilador


aquí un enlace a la página con info

Enhorabuena por el trabajo theelf. Menudo currazo. Gracias a tu esfuerzo logramos entender un poco mejor como funcionan nuestras queridas y ya viejas amigas

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, supongo que ya lo sabras, pero para optimizar gráficos, prueba a usar imagenesis (descarga en la misma pagina de devster), no sólo te adapta los gráficos, sino que elimina algunos repetidos. Con esto la faena no está del todo hecha, pero almenos ahorras mucho tiempo, aunque esta aplicacion tiene sus defectillos. Saludos!

Theelf, supongo que ya lo sabras, pero para optimizar gráficos, prueba a usar imagenesis (descarga en la misma pagina de devster), no sólo te adapta los gráficos, sino que elimina algunos repetidos. Con esto la faena no está del todo hecha, pero almenos ahorras mucho tiempo, aunque esta aplicacion tiene sus defectillos. Saludos!

En realidad uso imagenesis para convertir las imagenes en formato binario. El imagenesis lo que hace es buscar los tiles iguales, y ahorrarte el trabajo de hacerlo a mano en codigo. Del trabajo de photoshop no te salva nadie....

En todo caso, gracias por el dato.Se que deve haber programas super utiles, de los que no conosco existencia..

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.

Perdona, no habia visto tu pregunta. La Megadrive tiene tambien 64k de memoria, pero esta claro, que no se puede usar la vram unicamente para almacenar tiles, te escribo aqui una parte del codigo, para que veas el uso de la vram desglosado

(antes que nada aclaro, que no tenia bien claro el uso exacto de la memoria, y me ayudaron en el foro de basiegaorxz, para no darme todo el credito )

Default VRAM Map

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]

Lo mismo pasara en SNES. Pero ten en cuenta, que devido a la menor resolucion de la SNES, 256x224, para mostrar "lo mismo" necesita de menos tiles...

Los caracteres iniciales que comentas los debe colocar el lenguaje, pq de entrada la MD no los tiene. Lo mismo con el memory map de la vram, se puede seleccionar, mediante registros, donde colocar o no colocar cada cosa; con lo cual se pueden ganar o perder spacio para tiles. Pero no se si se podrá hacer con este lenguaje.

Me parece que ya comentaste que la MD se puede poner a 256 de resolución horizontal, ?no?

2 preguntas:

- Una vez tienes los tiles por separados como te lo montas para crear el mapa que los coloca en el orden correcto?

- Y el sonido? Como piensas hacerlo? Hay alguna utilidad que transforme el sonido a 'formato' MD?

theelf escribió:

Default VRAM Map

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]

Lo mismo pasara en SNES. Pero ten en cuenta, que devido a la menor resolucion de la SNES, 256x224, para mostrar "lo mismo" necesita de menos tiles...

ahora entiendo que estaba equivocado pero no tengo conocimientos para entender bien lo que me pones, yo creia que todo lo que se ve en pantalla estaba formado por tiles, pero a ver si lo he entendido bien:

2x8192bytes para dos scroll ( ¿se refiere a los planos de scroll parallax tipicos de las 16bit para crear efecto de profundidad?) ¿solo dos?
1856bytes Patterns ¿eso es el fondo de pantalla?
que es Window?
384bytes Patterns,
H Scroll?
Patterns (Tiles 0-1343) = $0000 - $A7FF 43008 Bytes ¿esto es lo que queda de memoria para tiles, no??

Estas maquinas que condiciones ponen a la hora de administrar la Vram?? Si no se ocupan los 1856bytes para por ejemplo Patterns, ¿se puede usar esa memoria para otra cosa?
como cuando en algun jefe final de fase se usaba el "truco" de quitar el fondo ¿dispondremos de 58 tiles mas? Y si no tenemos fondo tampoco tiene sentido tener scroll luego habra capacidad para otras 512 tiles mas, no?

Gracias.

Hola, ante todo, feliz navidad a todos!!

Bueno, a ver si puedo contestar alguna spreguntas, que yo tampoco soy programador de Sega

2 preguntas:

- Una vez tienes los tiles por separados como te lo montas para crear el mapa que los coloca en el orden correcto?

Una vez tengo los tiles, eso ya depende de lo que estes programando.



En caso de tener los tiles ordenados de x a y, en codigo los ordenas automaticamente, por ejemplo

i=128
for y=0 to 27
for x=0 to 39
drawtile i,x,y
i++
next
next

En caso de haber usado imagenesis para generar un mapa de tiles, usas otro codigo, para leer y ordenadar desde el mapa

For Y=0 to 27
For X=0 to 79
readint Map(X,Y)
Next X
Next Y

En caso de tener los tiles por separado, porque prefieres hacerlo a mano, se genera un array de tiles, por ejemplo

map_level0:
DATAINT 44,48,44,48,44,48,44,48,44,48,44,48,44,48,44,48,44,48,44,48,44,48,44,48
DATAINT 52,56,52,56,52,56,52,56,52,56,52,56,52,56,52,56,52,56,52,56,52,56,52,56
DATAINT 44,48,44,48,44,48,44,48,44,48,44,48,44,48,44,48,44,48,44,48,44,48,44,48
DATAINT 52,56,52,56,52,56,52,56,52,56,52,56,52,56,52,56,52,56,52,56,52,56,52,56
DATAINT ......

Aqui lo que se le indica es que en los pixeles 0 a 7 de x, use el tile 44, en los pixeles 8 a 15 use el 48..etc

Este es el mejor metodo para hacer juegos RPG, porque piensa que estos juegos repiten hasta el cansancio los mismos tiles una y otra vez... jaja

- Y el sonido? Como piensas hacerlo? Hay alguna utilidad que transforme el sonido a 'formato' MD?

Sobre el sonido, lamentablemente no se pueden usar samples, asi que habria que transformar la musica a codigo.
Yo tengo una patata en vez de oido, y ensima soy nulo con la musica pero te puedo dar 3 soluciones a tu pregunta

1) Compones musica mediante codigo, la mejor opcion ya que ocupa muy poco (la que usan los juegos de MD) pero la calidad no es alta,a menos que seas musico...
2)Usar algun programa como TFM Music Maker, y transformar MOD a musica de MD (ocupan mucho, pero es facil)
3) Compilar para MegaCD y cargar pistas de CD-audio (Lo mejor!! ya que es le mejor formato para distribuir un juego... quien no tiene gravadora de CD?.. )

Te subo mi ejemplo del nivel de LB2 con musica de fondo. La musica la converti con TFM y el sample es uno de los que vienen de ejemplo.

http://rapidshare.com/files/325803191/ejemplo_con_musica.zip

Como no entiendo mucho de musica, conversiones etc...espero respondiera a tu duda correctamente, si no, pido ayuda a algun forero entendido del tema...

2x8192bytes para dos scroll ( ¿se refiere a los planos de scroll parallax tipicos de las 16bit para crear efecto de profundidad?) ¿solo dos?
1856bytes Patterns ¿eso es el fondo de pantalla?
que es Window?
384bytes Patterns,
H Scroll?
Patterns (Tiles 0-1343) = $0000 - $A7FF 43008 Bytes ¿esto es lo que queda de memoria para tiles, no??

Estas maquinas que condiciones ponen a la hora de administrar la Vram?? Si no se ocupan los 1856bytes para por ejemplo Patterns, ¿se puede usar esa memoria para otra cosa?
como cuando en algun jefe final de fase se usaba el "truco" de quitar el fondo ¿dispondremos de 58 tiles mas? Y si no tenemos fondo tampoco tiene sentido tener scroll luego habra capacidad para otras 512 tiles mas, no?

Cuantas preguntas tecnicas. A ver si respondo correctamente, si no, espero alguien me corrija.

Primero vamos primero a entender, que es lo que puede mostrar el VDP de megadrive


La MD puede mostrar 3 capas a la vez, el PLANO A, el PLANO B, y el PLANO Window. Seguro con esta imagen entenderas el uso de los planos



Aqui seguro abra gente en discordia, ya que muchisimos juegos de MD, muestran mas de 2 planos de scroll, a lo que respondo que es imposible. Simplemente son trucos con sprites.

El plano Window, no permite scroll, y devido a los problemas que tiene con tiles transparentes, no se suele usar por ejemplo en juegos de pelea.

La necesidad de uso de vram, es que se tiene que almacenar los datos, de scroll, planos, window, etc en la vram.

Por lo que se el cpu 68000 no puede escribir ni leer directamente en el VDP.Asi que se necesita almacenar todos los datos en vram.




Sobretu pregunta, en teoria los tiles se pueden escribir en cualquier parte de la memoria. Si no use usa un dato, en teoria se podria escribir tiles en el. A ver, en MD se han usado los mil y un trucos para saltarse limitaciones, pero muchas de esas tecnicas de programacion, se escapan de mis conocimientos.

Espero haber sido de ayuda!

No me doy credito en los graficos, ya que use los de un tutorial que tengo en el PC, simplemente los traduje al castellano y modifique para ser mas explicativos

Si creo que lo suyo es tener todo el nivel dibujado en bitmap y una utilidad que busque los tiles -> genere el archivo de titles no repetidos, genere la(s) paleta(s) y genere el mapa de titles. Tengo que pensar como crear super-structuras para que la MD pueda con todo eso, y las zonas de colisión... Lo jodido es que ese mapa ocupa más que los gráficos...

Respecto al sonido, yo tampoco entiendo mucho; pero estamos aquí para aprender... ¿no?

Si creo que lo suyo es tener todo el nivel dibujado en bitmap y una utilidad que busque los tiles -> genere el archivo de titles no repetidos, genere la(s) paleta(s) y genere el mapa de titles. Tengo que pensar como crear super-structuras para que la MD pueda con todo eso, y las zonas de colisión... Lo jodido es que ese mapa ocupa más que los gráficos...

Respecto al sonido, yo tampoco entiendo mucho; pero estamos aquí para aprender... ¿no?

En realidad, la unica manera que existe de optimizar, es tirarse horas en el Photoshop/Paint shop pro/Gimp... armando el escenario a base de tiles, y logrando el efecto de que en ralidad, estas viendo una sola imagen.

Luego el imagenesis se encarga de buscar los trozos de 8x8 pixeles repetidos, generar el mapa y la paleta.

El tema es que muchas veces, aunque no lo parezca,hacer un array a mano, te ahorra trabajo.

Total cortando una imagen en "trozos" de 32x32 pixeles (16 tiles) te da un array de 10x7, y si es un escenario por ejemplo de un RPG de grandes dimensiones, como mucho seria de 20x28, lo que solo tendrias q hacer un array de 560 "trozos"

Claro que en estos tiempos, todo ese trabajo asusta, porque con RPG maker, puedes hacer lo mismo en 10 minutos.... pero claro, no es lo mismo programar, teniendo en mente unas caracteristicas minimas de por ejemplo un PC P3 de 500mhz con 128mb (que en estas epocas es mierda..), que hacerlo para 8mhz y 64kb...jajajaja

Muchas gracias tio por tomarte la molestia del pedazo de explicacion, ahora tengo los concetos mas claros.

Me pregunto yo desde hace unos dias... ¿Porque los tiles son de 8x8?. Si fueran de 2x2, que es el minimo tamaño de un supuesto tile, a la hora de buscar patrones repetido en una imagen saldrian mas tiles repetidos y se ahorraria mucha Vram.

Asi echandole imaginacion supongo que podria ser, porque sino cada tile seria de 4bitx4 (2x2) = 16bit por tile, muy poca informacion a mover en cada ciclo de relog y el procesador al estar de brazos cruzados el resto del tiempo perderia mucho rendimiento (aunque 16bit es precisamente el ancho de palabra que usan estos procesadores y mi explicacion no me cuadra...

Me ha dejado a cuadros el TFM Music Maker. Necesito un turorial para tontos...

A ver si acierto:
- Cada canción del programa es un canal de los 4 disponibles.
- Falta programar el PSG para los efectos de sonido. ¿Como?

Muchas gracias tio por tomarte la molestia del pedazo de explicacion, ahora tengo los concetos mas claros.

De nada! es un placer

Me pregunto yo desde hace unos dias... ¿Porque los tiles son de 8x8?. Si fueran de 2x2, que es el minimo tamaño de un supuesto tile, a la hora de buscar patrones repetido en una imagen saldrian mas tiles repetidos y se ahorraria mucha Vram

DIOS!! nooo!! si ya trabajar una imagen 8x8 es un infierno, en 2x2 se volveria loco cualquiera!!

Ademas, no te olvides que es necesario guardar el "sitio" (no los datos) de cada tile en memoria, asi que asi por arriba, calculo 17920 tiles en pantalla... me parece que lo que ahorramos por un lado, lo gastamos por otro..?¿ y ensima se complica trabajar con las imagenes de sobremanera.

Fijate la dificultad a la hora de programar "unidades" pequeñas, que el los SONIC por ejemplo, esta formado por "tiles" de 64x64. En realidad programaron arrays de 8x8 tiles.
Asi se puede representar un nivel entero con menor trabajo que si tienes que hacer un array de tiles normales de 8x8.


(la imagen esta a un 50%)

Como estoy vago , en la imagen solo hice una reseña de las 3 primeras lineas de tiles. Asi que el array seria

1 0 3 4 5 6 3 4 0 0 3 4 0 0 0
2 0 7 8 0 0 7 8 0 0 7 8 0 0 0
8 9 3 4 0 0 0 0 B C 0 0 B C 0

Y a su vez, 64x64 pixel "tile" dividido en 8x8 tiles reales, o sea otro array
(ahora estoy mas vago, y solo hago la primera linea )

1 2 1 1 2 1 1 2 1 1 2 1

puff... con tiles de 2x2 solo me queda pensar en los tamaños de los array....

Ademas de eso, no puedo dar otra explicacion de porque son 8x8. Si alguien lo save con exactitud, espero se una a la discucion

Me ha dejado a cuadros el TFM Music Maker. Necesito un turorial para tontos...

A ver si acierto:
- Cada canción del programa es un canal de los 4 disponibles.
- Falta programar el PSG para los efectos de sonido. ¿Como?

Yo en lo que es sonido, nulo. Los unicos conocimientos que tengo, son los de su epoca, cuando haciamos mod para concursos de PC mania y eso..jaja, pero ya hace muchos años

Que yo sepa, el TFM trabaja con un sistema similar al mod, que disponia de 4 canales para instrumentos. En realidad, una cancion esta formada por 4 canales de diferentes instrumentos.

Un archivo mod, o de TFM tambien, tiene una cabezera con los instrumentos pregrabados. Despues esta la velocidad a los que se reproducen estos efectos pregrabados, para dar tonos mas altos o bajos,asi se genera todas las notas musicales.

Asi que basicamente, volvemos a los array , lo que un tile es al grafico, el mod lo es al sonido. Un array de sonidos pregrabados, con diferentes propiedades.

Ahor, en la megadrive, una musica en TFM ocupa uno de los canales, asi que no hya problema en activar otro canal para los samples

Falta programar el PSG para los efectos de sonido. ¿Como?

Esto no termine de entender. No se bien que me preguntas. Lo que dices es si se puede reproducir samples ademas de la musica? claro por supuesto.

2x2 me parece demasiado pequeño. Los capas A,B,W triplicarian su tamaño y ocuparian gran parte de la VRAM. Para aprovechar al 100% la memoria y la electrónica se necesita el uso de números redondos en binario (2^n), en las targetas gráficas actuales pasa lo mismo, 8x8 me parece un número ni demasiado grande ni demasiado pequeño (8*4bytes=32bytes=16words=8longs=2^n).

Sonido

Me explico, por lo que estoy leyendo:
La MD tiene 2 chips de sonido el Yamaha YM2612 Frequency Modulation (FM) y el Texas Instruments SN76489 Programmable Sound Generator (PSG). El PSG tiene 4 canales de 'baja calidad', supongo que se debe usar para 'la caja de ritmos'. El FM tiene 6 canales de 'alta calidad' con 4 instrumentos cada uno, o 5 si el 6to se utiliza para PCM. Los canales FM son sólo de 8bits y eso resulta ser una gran limitación a la hora de componer. El canal PCM no va acompañado de ningún timer y eso parece ser un buen problema, así que no se si los juegos desisten de usar el PCM para efectos de sonido y usan algunos canales de FM para tal proposito o no.

Soy una nulidad en sonido, así que puedo estar diciendo tonterias muy tontas.

Entonces faltaria saber si es mejor usar el FM o el PCM para efectos de sonido. Saber como programar el PSG, y como convertir ficheros de 'ondas de sonido', ¿no?

alucinante ver de froma tan ilustrada como se llena gran parte de la pantalla con tan poca memoria, ¿Hoy dia se usa algo de esto en juegos 2D para PC??
bueno no hago mas preguntas que voy a estar unos dias fuera y no voy a poder contestar, y asi te dejo descansar un poco que menuda currada ejejej

Ya no se programa asi.En realidad, se perdio los buenos habitos de programacion. Ya ni siquiera se optimiza, porque el hardware es mas eocnomico que el software en estos dias...




Yo tampoco estoy muy puesto con el tema del audio. Te comento lo que hago yo, a ver si te ayuda.

Basicamente en el codigo activo el PSG y cargo un "driver" que permite leer musica TFM en un archivo binario, convertidas con el TFM music maker. En realidad, no se si se pasa por el PSG o a travez del chip yamaha la musica, ya que como nunca me intereso la parte del audio, no revise el codigo del driver.

Lo unico que se es que la musica suena muy bien, y me quedan 3 canales libres para musica o samples.


Por mis limitados conocimientos, puedo decirte que el chip YM2612 de la MD, dispone de 6 canales, de los cuales nunca se usan mas de 5, y el sexto queda libre.
El canal numero 6, se puede usar para reproducir samples.

Pero no estoy muy puesto con audio, y como siempre programo con megacd en mente, tampoco me puse mucho a por el tema.

OK! gracias por tus indicaciones.

En BASIC tb hay un ‘driver’? En el MDKit hay un código llamado ‘driver´, pero en BASIC se podría haber embebido en el lenguaje.

MegaCD
El principal problema es que la velocidad de los datos baja a 150 KB/s punta en vez de los casi 4MB/s constantes. El VDP puede con unos 700KB/s (aprox.), así que si vas a hacer una conversión de un juego de neogeo... no se que es peor o mejor... Después tb surge el tema de la latencia de giro del lector de CD, por lo que deberías avanzarte a las peticiones de datos.

Sobre el nivel que has mostrado, creo que algo chulo que se podría hacer es, separar en 2 planos las llamas de la casa y generar efectos raster para las llamas (los buffers de scrolling a nivel de línea) además del cambio de paleta que has mencionado. La MD es inferior en casi todo a neogeo, pero no en efectos raster, aprovechémoslo.
Ya puestos también se podría hacer un scroll paralax con el suelo, usando el mismo método raster.

Muy chulo! A ver si nos muestras algo más.

Buen trabajo, yo flipo...
Se un poco de programacion en c++, casi nada. Mola ver que investigais y no dejais que estas tecnicas mueran del todo.
Los programadores de hoy en dia harian bien en seguir la antigua disciplina de optimizar el codigo al maximo (se que es una cuestion de tiempo, posiblemente no puedan porque no lo tienen), veriamos juegos mejores con el hard que hay ahora.
Mas aun, no es solo un problema del ambito de la programación, ya casi en ningun ambito se toma el cuidado que se tenia antes como referencia. Lo se por experiencia.

spege escribió:Buen trabajo, yo flipo...
Se un poco de programacion en c++, casi nada. Mola ver que investigais y no dejais que estas tecnicas mueran del todo.
Los programadores de hoy en dia harian bien en seguir la antigua disciplina de optimizar el codigo al maximo (se que es una cuestion de tiempo, posiblemente no puedan porque no lo tienen), veriamos juegos mejores con el hard que hay ahora.
Mas aun, no es solo un problema del ambito de la programación, ya casi en ningun ambito se toma el cuidado que se tenia antes como referencia. Lo se por experiencia.

Totalmente cierto.
Poca gente programa como antes, los compiladores son muy flexibles, se pueden hacer declaraciones en cualquier parte del código...hay muy poco análisis o ninguno del proyecto antes de programar y muy poco tiempo, demasiada presión por parte del jefe, superior o director de proyecto... mucho ansia por cobrar cuanto antes y se acabó. En fins, nos equipovamos de profesión.

sgonzalez escribió:Totalmente cierto.
Poca gente programa como antes, los compiladores son muy flexibles, se pueden hacer declaraciones en cualquier parte del código...hay muy poco análisis o ninguno del proyecto antes de programar y muy poco tiempo, demasiada presión por parte del jefe, superior o director de proyecto... mucho ansia por cobrar cuanto antes y se acabó. En fins, nos equipovamos de profesión.

Bueno, es que ahora los juegos son mas complejos, así que las "indicaciones" son mas complejas también. En tiempos de megadrive, ¿cuanta gente se dedicaba a la labor de programar?(y me refiero unica y exclusivamente a tocar el codigo), ¿y ahora?, me da que la desproporción ha descompensado todavía mas esto.

Ralph escribió:

sgonzalez escribió:Totalmente cierto.
Poca gente programa como antes, los compiladores son muy flexibles, se pueden hacer declaraciones en cualquier parte del código...hay muy poco análisis o ninguno del proyecto antes de programar y muy poco tiempo, demasiada presión por parte del jefe, superior o director de proyecto... mucho ansia por cobrar cuanto antes y se acabó. En fins, nos equipovamos de profesión.

Bueno, es que ahora los juegos son mas complejos, así que las "indicaciones" son mas complejas también. En tiempos de megadrive, ¿cuanta gente se dedicaba a la labor de programar?(y me refiero unica y exclusivamente a tocar el codigo), ¿y ahora?, me da que la desproporción ha descompensado todavía mas esto.

Bueno, me refería en general no en el mundo videojueguil .

En todos los programas de la actualidad (pcs, apples, etcs.) pienso que probablemente en los buenos juegos del mundo consolero es donde más optimizado esté el código, quiero pensar en Uncharted 2 o por ejemplo GT5, claro que....sus millones y sus 5 años en desarrollo se han llevado...y eso no está al alcance de cualquiera. En x360 no sé cual sería el ejemplo idóneo.

Saludetes

Bueno, me refería en general no en el mundo videojueguil .

En todos los programas de la actualidad (pcs, apples, etcs.) pienso que probablemente en los buenos juegos del mundo consolero es donde más optimizado esté el código, quiero pensar en Uncharted 2 o por ejemplo GT5, claro que....sus millones y sus 5 años en desarrollo se han llevado...y eso no está al alcance de cualquiera. En x360 no sé cual sería el ejemplo idóneo.

Tendrias que ver la Apple Mac Classic. Yo aun la conservo despues de 20 años de comprada en perfecto estado.

Con un increible procesador Motorola 68000 a 8mhz, 1mb ram, y 40mb de disco duro, carga el sistema System 6 en menos de 10 segundos!! totalmente grafico claro...

...lo mejor... carga el photoshop 1.0 en nada, 5-8 segundos, el word, y excel, tambien como mucho en 5 segundos...

El system 6 estaba programado 100% en assembler. Fue el ultimo sistema operativo de apple en estar programado al 100% en assembler.... otras epocas



Aui se demustra el poder de 8mhz y 1mb ram............ si se programa bien


y esta captura es de una Mac con 512kb de Ram...


Incluso microsoft programaba bien... Windows 3.0 640kb ram



Volviendo al tema de las consolas, estos dias estoy muy ocupado, pero apenas pasen las fiestas, pondre algunos ejemplos mas de programacion. Mi idea es hacer algun mini tutorial de programacion, pero no solo de codigo, si no general, para MD/MCD... claro, si interesa a la gente...

theelf escribió:Volviendo al tema de las consolas, estos dias estoy muy ocupado, pero apenas pasen las fiestas, pondre algunos ejemplos mas de programacion. Mi idea es hacer algun mini tutorial de programacion, pero no solo de codigo, si no general, para MD/MCD... claro, si interesa a la gente...

No lo dudes, yo siempre he trasteado con el basic de msx, y (mucho) mas tarde, aunque no es lo mismo, y debido a la cercanía, también hice cosas con div 2. Vamos, que no me supone un infierno meterme de lleno en estas cosas.


Si necesitas un cable para organizarte con el tutorial, cuenta conmigo.

OK, gracias por el interes. Luego de las fiestas, cuando tenga mas tiempo,me ire preparando algo.

Mi idea es hacer algo bien echo, para que incluso alguien con conocimientos bajos/nulos de programacion, pueda lograr algo "real" (el "hola mundo", es muy chulo, pero lo que todo el mundo quiere es mover un sprite sobre un fondo... )

Vale, ya me contarás como tienes pensado hacerlo, a ver si te puedo echar un cable con documentación, redacción, etc...

theelf escribió:OK, gracias por el interes. Luego de las fiestas, cuando tenga mas tiempo,me ire preparando algo.

Mi idea es hacer algo bien echo, para que incluso alguien con conocimientos bajos/nulos de programacion, pueda lograr algo "real" (el "hola mundo", es muy chulo, pero lo que todo el mundo quiere es mover un sprite sobre un fondo... )

Animo con eso, yo lo cogere con los brazos abiertos

Animo con eso, yo lo cogere con los brazos abiertos

Gracias, hoy con el frio de la feria de reyes (si a los que tenemos tienda nos toca trabajar ) me agarre una flor de gripe, asi queme pasare el fin de semana en la cama, y seguramente podre hacer bastante de la guia jaja a ver si la semana que viene tengo algo echo

Gracias por el interes!

theelf escribió:

Bueno, me refería en general no en el mundo videojueguil .

En todos los programas de la actualidad (pcs, apples, etcs.) pienso que probablemente en los buenos juegos del mundo consolero es donde más optimizado esté el código, quiero pensar en Uncharted 2 o por ejemplo GT5, claro que....sus millones y sus 5 años en desarrollo se han llevado...y eso no está al alcance de cualquiera. En x360 no sé cual sería el ejemplo idóneo.

Tendrias que ver la Apple Mac Classic. Yo aun la conservo despues de 20 años de comprada en perfecto estado.

Con un increible procesador Motorola 68000 a 8mhz, 1mb ram, y 40mb de disco duro, carga el sistema System 6 en menos de 10 segundos!! totalmente grafico claro...

...lo mejor... carga el photoshop 1.0 en nada, 5-8 segundos, el word, y excel, tambien como mucho en 5 segundos...

El system 6 estaba programado 100% en assembler. Fue el ultimo sistema operativo de apple en estar programado al 100% en assembler.... otras epocas



Aui se demustra el poder de 8mhz y 1mb ram............ si se programa bien


y esta captura es de una Mac con 512kb de Ram...


Incluso microsoft programaba bien... Windows 3.0 640kb ram



Volviendo al tema de las consolas, estos dias estoy muy ocupado, pero apenas pasen las fiestas, pondre algunos ejemplos mas de programacion. Mi idea es hacer algun mini tutorial de programacion, pero no solo de codigo, si no general, para MD/MCD... claro, si interesa a la gente...

Qué Nvidia un apple mac classic. No sabía eso de que el S.O. estaba escrito en ensamblador. Evidentemente el código estará super optimizado para el hardware. Creo que debido a la gran multitud de dispositivos disponibles en la actualidad es prácticamente imposible optimizar tanto el código, a no ser que sea un desarrollo completamente cerrado y no muy grande.
El apple mac fue un adelantado a su tiempo en casi todos los aspectos, por ejemplo en el uso de una CPU de 16/32 bits como el 68000. Cuándo el Mac apareció todavía no existía el Amstrad CPC (8 bitero total ).

Estaría genial eso que dices theelf de publicar un tutorial para programar en MD/MCD, te estaríamos muy agradecidos.
Un saludo y feliz año

Pues nenes, yo me voy a meter con el tema de programacion de NES.

Hace años me meti en ello, pero poco saque en claro.

Hoy en día hay mas tutoriales y ayuda y creo que voy a volver a cojerlo.

Si todo sale bien, me gustaria hacer tambien un tutorial sobre lo mismo, pero claro, en NES, ufff, es mas complicado a mi modo de ver, pero a ver que puedo sacar en claro.

ues nenes, yo me voy a meter con el tema de programacion de NES.

Hace años me meti en ello, pero poco saque en claro.

Hoy en día hay mas tutoriales y ayuda y creo que voy a volver a cojerlo.

Si todo sale bien, me gustaria hacer tambien un tutorial sobre lo mismo, pero claro, en NES, ufff, es mas complicado a mi modo de ver, pero a ver que puedo sacar en claro.

En realidad ahora mi poco tiempo libre lo dedico a la programacion en megadrive, pero hace unos cuantos años atras (10-12), habia aprendido a programar para NES.

Llege a hacer un juego de naves en NES, basico,injugable (pero vistoso porque use muchos graficos), pero al menos compilo, y fue util a mis conocimientos.

Si ves que te vuelves a trabar, tal vez pueda darte algunas direcciones, si me acuerdo despues de tantos años... claro

theelf escribió:

ues nenes, yo me voy a meter con el tema de programacion de NES.

Hace años me meti en ello, pero poco saque en claro.

Hoy en día hay mas tutoriales y ayuda y creo que voy a volver a cojerlo.

Si todo sale bien, me gustaria hacer tambien un tutorial sobre lo mismo, pero claro, en NES, ufff, es mas complicado a mi modo de ver, pero a ver que puedo sacar en claro.

En realidad ahora mi poco tiempo libre lo dedico a la programacion en megadrive, pero hace unos cuantos años atras (10-12), habia aprendido a programar para NES.

Llege a hacer un juego de naves en NES, basico,injugable (pero vistoso porque use muchos graficos), pero al menos compilo, y fue util a mis conocimientos.

Si ves que te vuelves a trabar, tal vez pueda darte algunas direcciones, si me acuerdo despues de tantos años... claro

Wow, no tendras la rom por ahí o el codigo fuente para aprender.

Podia colgarla en RetroNES. Ademas, allí muchisima gente esta interesada en aprender a programar para la NES. Hubiese estado bien que escribieses algun pequeño tutorial para luego colgarlo en la página. ¿Que te parece?

Wow, no tendras la rom por ahí o el codigo fuente para aprender.

Podia colgarla en RetroNES. Ademas, allí muchisima gente esta interesada en aprender a programar para la NES. Hubiese estado bien que escribieses algun pequeño tutorial para luego colgarlo en la página. ¿Que te parece?

ya hace tiempo, lo habre borrado todo, aunque buscare en CDs antiguos a ver si hay algo. En todo caso, cuando termine el tutorial de megadrive, me pondre con la NES, a ver que me acuerdo, y si es suficiente, hago un tutorial

Visto que puede haber gente interesada en estas cosas, de las consolas clasicas se programar en mayor o menor medida,para la Megadrive, MegaCD,NES, SNES y NeoGeo, aunque solo me gusta para MD y megaCD.

La NES es una consola que le tengo mucho afecto, y realmente, me dan ganas de volver a leerme los tutoriales, ya te dire algo

theelf escribió:

Wow, no tendras la rom por ahí o el codigo fuente para aprender.

Podia colgarla en RetroNES. Ademas, allí muchisima gente esta interesada en aprender a programar para la NES. Hubiese estado bien que escribieses algun pequeño tutorial para luego colgarlo en la página. ¿Que te parece?

ya hace tiempo, lo habre borrado todo, aunque buscare en CDs antiguos a ver si hay algo. En todo caso, cuando termine el tutorial de megadrive, me pondre con la NES, a ver que me acuerdo, y si es suficiente, hago un tutorial

Visto que puede haber gente interesada en estas cosas, de las consolas clasicas se programar en mayor o menor medida,para la Megadrive, MegaCD,NES, SNES y NeoGeo, aunque solo me gusta para MD y megaCD.

La NES es una consola que le tengo mucho afecto, y realmente, me dan ganas de volver a leerme los tutoriales, ya te dire algo

Bua tio, no sabes lo de feliz que nos harias a muchos.

En el foro de RetroNES estuvimos hace ya muchos años hablando de programar algo en NES. Me puse a investigar pero poco saque en claro, mas alla de utilizar erramientas que facilitaban el trabajo para programar en NES pero sin conseguir nada.

Estuvimos incluso comentando el portar el Super Mario World de SNES a la NES, empezando con el primer nivel aunque sea. Aunque creo que ya estabamos disparando algo alto, yo me motive y me puse a pasar sprites del SMW de SNES al formato de NES, esto es, que tuviesen 4 colores. Poco mas.

Bua tio, no sabes lo de feliz que nos harias a muchos.

En el foro de RetroNES estuvimos hace ya muchos años hablando de programar algo en NES. Me puse a investigar pero poco saque en claro, mas alla de utilizar erramientas que facilitaban el trabajo para programar en NES pero sin conseguir nada.

Estuvimos incluso comentando el portar el Super Mario World de SNES a la NES, empezando con el primer nivel aunque sea. Aunque creo que ya estabamos disparando algo alto, yo me motive y me puse a pasar sprites del SMW de SNES al formato de NES, esto es, que tuviesen 4 colores. Poco mas.

Antes que nada, sabes programar en ASM (ensamblador)? digo porque si voy a hacer algun tutorial de NES, no voy a enseñar ASM, y por descontado no entenderas el tutorial, no es algo q se pueda ir aprendiendo sobre la marcha

A mi la NES me gusta muchisimo, pero no quisiera hacer algun mini tutorial, y q nadie lo entienda.

theelf, cualquier aporte que hagas en castellano sera de muchisima ayuda.

Si puedes hacer el esfuerzo, un mini tutorial o lo que quieras, mucha gente te sera agradecida y muchos estaremos al tanto para poder usarlo.