Tutorial muy básico de C para Master System

Refloto para ke no se pierda el hilo, ni lo chapen.
Continuamos ?¿

Se va avanzando poco a poco.

Gracias a @kusfo79 que me ha ayudado a adaptar las colisiones de la versión NES para que las entienda la SMS, he podido avanzar en el proyecto del port de The Banketh.

Os presento resultados, por tanto: https://www.dropbox.com/s/9k2kaxunbwrkb ... 2.sms?dl=0

Xputo escribió:Refloto para ke no se pierda el hilo, ni lo chapen.
Continuamos ?¿

Buenas!

Perdon, he andado casi 4 semanas fuera de europa. A ver si se me pasa el Jet Lag y esta semana voy preparando una nueva lección con vuestras sugerencias!

¿Sugerencias? El scroll, claro

Ya ke lo preguntas, como dije hace un tiempecillo...

Xputo escribió:Wowhohooo... muuchas gracias !!
Me lo voy a pegar un repasito del 'güeno'... ke así me evito tener
chorrocientos compiladores repartidos por el sistema.

Aporto una mejora al tuto:
Se podría comentar cada función de la biblioteca principal SMSlib.h, indicando el
uso y parámetros ke reciben cada una. Un pekeño [corto] ejemplo de su
uso estaría bien.
También explicar para ké se usa/rekiere los archivos *.rel.
Más ke nada para los ke no dominan C y son novatos en el tema.

Se podrían llevar de forma seguida con un pekeño ejemplo de cada una de las funciones.
Así kedaría redondo el tutorial y se tocan todas y cada una de las funciones de la librería.
[debería decir biblioteca, no librería... pero bueno ]

Diskover escribió:Se va avanzando poco a poco.

Gracias a @kusfo79 que me ha ayudado a adaptar las colisiones de la versión NES para que las entienda la SMS, he podido avanzar en el proyecto del port de The Banketh.

Os presento resultados, por tanto: https://www.dropbox.com/s/9k2kaxunbwrkb ... 2.sms?dl=0

Qué sensaciones te da la SMS respecto a la NES? Por ejemplo que no puedas hacer flip de los sprites pero si de los fondos?

Gammenon escribió:Qué sensaciones te da la SMS respecto a la NES? Por ejemplo que no puedas hacer flip de los sprites pero si de los fondos?

Eso sobre todo, lo cual proboca que los juegos acaben ocupando más espacio.

Otro inconveniente sería que los tiles guardan la información del color. Esto en principio os puede parecer una ventaja, pero realmente es una desventaja dado que no puedes reutilizar tiles en un mismo escenario con distintos colores, como si ocurre en NES; lo cual fuerza a que consumas más tiles y por tanto los juegos acaben ocupando otra vez más espacio.

Por ultimo está el tema de la resolución, que en SMS al ser menor, me jode parte de la pantalla y he tenido que eliminar el HUD. Ya vere como lo sustituyo. Supongo que superponiendo sprites para representar sobre todo cuanta vida te queda y que arma llevas equipada. Quizá quite lo de los puntos.

Para todo lo demás, como estoy usando un compilador CC65 que me permite programar en C en ambas consolas, por ahora no he constatado más diferencias notables.

Diskover escribió:

Gammenon escribió:Qué sensaciones te da la SMS respecto a la NES? Por ejemplo que no puedas hacer flip de los sprites pero si de los fondos?

Eso sobre todo, lo cual proboca que los juegos acaben ocupando más espacio.

Otro inconveniente sería que los tiles guardan la información del color. Esto en principio os puede parecer una ventaja, pero realmente es una desventaja dado que no puedes reutilizar tiles en un mismo escenario con distintos colores, como si ocurre en NES; lo cual fuerza a que consumas más tiles y por tanto los juegos acaben ocupando otra vez más espacio.

Por ultimo está el tema de la resolución, que en SMS al ser menor, me jode parte de la pantalla y he tenido que eliminar el HUD. Ya vere como lo sustituyo. Supongo que superponiendo sprites para representar sobre todo cuanta vida te queda y que arma llevas equipada. Quizá quite lo de los puntos.

Para todo lo demás, como estoy usando un compilador CC65 que me permite programar en C en ambas consolas, por ahora no he constatado más diferencias notables.

Si no voy mal la SMS puede tener resoluciones de 256x192, 256x224 y 256x240, esta última es la de la NES.

Lo de los tiles de sprites que no puedas girar me parece una cagada impresionante, si quieres tener 2 enemigos iguales en pantalla pero cada uno está mirando a un lado diferente tienes que tener los 2 juegos de tiles en la VRAM, no?

Gammenon escribió:Si no voy mal la SMS puede tener resoluciones de 256x192, 256x224 y 256x240, esta última es la de la NES.

Hasta donde yo se la SMS tiene resoluciones a 256 x 192 (modo de las SG1000 /SC3000) y a 248 x 192. Yo estoy trabajando con el primer modo. La NES trabaja a 256 x 240. Decidí cortar por arriba a la hora de portar los mapas.

Gammenon escribió:Lo de los tiles de sprites que no puedas girar me parece una cagada impresionante, si quieres tener 2 enemigos iguales en pantalla pero cada uno está mirando a un lado diferente tienes que tener los 2 juegos de tiles en la VRAM, no?

Exacto. A mi me parece una auténtica putada.

Y lo que comentaba antes de que los tiles guardan información de color: antes en la NES el mismo tile que usaba para representar agua, lo usaba tambien para la hierba, para arena y para la lava. Cuatro en uno.

En SMS nanai. Cada tile para su cosa.

La master tiene los modos con resolución "alta", son 3 resoluciones posibles:
"256x192 and 256x224. PAL/SECAM also supports 256x240". Los dos segundos solo funcionan en consolas con la segunda version del VDP.

Sobre el tema del color, y de los espejados, es un concepto un poco diferente. Lo del espejado de tiles de escenario tiene la ventaja de que permite hacer escenarios mucho más complejos que en la NES, y también el hecho de que no había desde el principio la limitación de 8Kb para gráficos, hacía que la falta de espejado de sprites no se notara mucho...

kusfo79 escribió:La master tiene los modos con resolución "alta", son 3 resoluciones posibles:
"256x192 and 256x224. PAL/SECAM also supports 256x240". Los dos segundos solo funcionan en consolas con la segunda version del VDP.

Sobre el tema del color, y de los espejados, es un concepto un poco diferente. Lo del espejado de tiles de escenario tiene la ventaja de que permite hacer escenarios mucho más complejos que en la NES, y también el hecho de que no había desde el principio la limitación de 8Kb para gráficos, hacía que la falta de espejado de sprites no se notara mucho...

Qué limitación es esa de los 8Kb? Aún así ya le podrían haber metido la posibilidad de hacer flip de los sprites

En los primeros juegos de NES (NROM), solo podías tener 8kb dedicados a los gráficos (CHR)

kusfo79 escribió:En los primeros juegos de NES (NROM), solo podías tener 8kb dedicados a los gráficos (CHR)

Eso era por la limitación del tamaño de la ROM? O era una cosa que arreglaron con algún mapper?

Gammenon escribió:

kusfo79 escribió:En los primeros juegos de NES (NROM), solo podías tener 8kb dedicados a los gráficos (CHR)

Eso era por la limitación del tamaño de la ROM? O era una cosa que arreglaron con algún mapper?

Se arregló luego con diferentes mappers y de diferentes formas.

De entrada la NES te permite hasta 32kb para almacenar el programa, y 8Kb para los gráficos. A lo largo de la vida util de la NES, ambas limitaciones se consiguieron solventar mediante mappers. Es un poco más complejo de explicar.

En este hilo se explica: hilo_curiosidades-de-la-nes-famicom-cuidado-56k-y-tarifas-datos_2188982

Dónde se pueden ver la imágenes DevKitSMSTutorial_Pic8.png hasta DevKitSMSTutorial_Pic16.png ?
Siguen sin aparecer en la wiki.

Otra apreciación:
En el apartado "Scroll por Hardware en Master System" donde reza

"... la mayoría de microordenadores de 8 bit no soportaban de forma nativa la realización de scroll. En esas máquinas, el scroll debía realizar-se por software, lo que en la práctica suponía repintar todo el fondo con un cierto desplazamiento cada vez que movieramos un poco el scroll. Por esta razón muchos de los juegos de estas máquinas cuentan con scrolles lentos, o con desplazamientos de 8px."

No es del todo cierto... C64 dispone de vídeo por hardware. La norma MSX está dotada
de un VDP como sistema de vídeo, y puede correr ciertos juegos de SMS.
Amstrad tiene un sistema pseudo-hardware para video, pero es un infierno de manejar
para un novato. Spectrum es otra cosa, sistema de vídeo muy sencillo para ke fuera un
ordenador barato de producir, y barato para el usuario.

El scroll lento de estos sistemas, era por desconocimiento del programador, o poca pericia.
Spectrum por ej tiene juegos con scrollers muy suaves a nivel de pixel. Otros por vagancia
o por ahorro de cálculo [y porke era más fácil] se movian a nivel de carácter.
Todos los primeros juegos programados en Basic [o con cierta parte], no pueden moverse
a nivel de pixel, copmo es lógico. Sí se puede hacer en cambio desde asm.

Xputo escribió:Dónde se pueden ver la imágenes DevKitSMSTutorial_Pic8.png hasta DevKitSMSTutorial_Pic16.png ?
Siguen sin aparecer en la wiki.

Otra apreciación:
En el apartado "Scroll por Hardware en Master System" donde reza

"... la mayoría de microordenadores de 8 bit no soportaban de forma nativa la realización de scroll. En esas máquinas, el scroll debía realizar-se por software, lo que en la práctica suponía repintar todo el fondo con un cierto desplazamiento cada vez que movieramos un poco el scroll. Por esta razón muchos de los juegos de estas máquinas cuentan con scrolles lentos, o con desplazamientos de 8px."

No es del todo cierto... C64 dispone de vídeo por hardware. La norma MSX está dotada
de un VDP como sistema de vídeo, y puede correr ciertos juegos de SMS.
Amstrad tiene un sistema pseudo-hardware para video, pero es un infierno de manejar
para un novato. Spectrum es otra cosa, sistema de vídeo muy sencillo para ke fuera un
ordenador barato de producir, y barato para el usuario.

El scroll lento de estos sistemas, era por desconocimiento del programador, o poca pericia.
Spectrum por ej tiene juegos con scrollers muy suaves a nivel de pixel. Otros por vagancia
o por ahorro de cálculo [y porke era más fácil] se movian a nivel de carácter.
Todos los primeros juegos programados en Basic [o con cierta parte], no pueden moverse
a nivel de pixel, copmo es lógico. Sí se puede hacer en cambio desde asm.

Te acabo de pasar un link con las imagenes que faltan, yo ya me voy a encargar de resubirlas aquí!

Sobre lo del scroll, ni C64 ni MSX en su primera versión disponen de scroll por hardware, por eso los scrolles suelen ser con movimiento a nivel de caracter. Lo que si que disponían es de sprites por hardware

En Amstrad si que hay un truco para hacer scroll por hardware, pero realmente yo solo lo ví en juegos ya de la última hornada (quizá me equivoco).

Incluso usando ASM, en spectrum es casi imposible un scroll por pixel a pantalla completa. Los que tienen scroll al pixel suelen tener marcadores grandes para reducir el area de pantalla, o usan por eejmplo el truco de dejar zonas de la pantalla con un color constante, que por ende no necesitan scroll (La segunda carga del Mortadelo y Filemon 2, por ejemplo)

Seguimos avanzando con la versión de The Banketh para SMS.

Añadidas colisiones parciales con enemigos: https://www.dropbox.com/s/1hqotl9kxvbyp ... 3.sms?dl=0

@Diskover
Has pensado en crear un tuto, de este estilo para la NES ?
Lo poco ke hay es bastante confuso [inglés], y en castellano no he visto nada por ahí.
O existe algo y no lo desconozco ?!

Xputo escribió:@Diskover
Has pensado en crear un tuto, de este estilo para la NES ?
Lo poco ke hay es bastante confuso [inglés], y en castellano no he visto nada por ahí.
O existe algo y no lo desconozco ?!

Por supuesto que lo he pensado... Todo se andará. Ahora mismo lo que hay está en inglés, y yo no soy un experto en programación pero puedo poner cimientos

Ya tampoco soy un experto, pero entre todos podremos reunir info en nuestro
idioma y aportar experiencias y demás.
Si te animas a ello, dame un toke, y te ayudo en lo ke pueda... ahora ke lo tengo
fresco.

Por cierto, siento que tengo el tutorial algo abandonado, pero llevo un par de meses bastante liado, pero espero retomarlo pronto.

Por otro lado, los que viváis en Barcelona o cercanías, el próximo dia 8 de Julio participaré junto a un compi en los eventos de fnacpixels'17 programando un videojuego para master en directo! Pasaros los que podáis!

Se va a grabar el evento?
Me gustaría verlo al menos en vídeo, ya ke no podré ir.
Un saludo, y trankilo por el tuto, sé ke no lo dejarás abandonado. Esperaremos ansiosos.

creo que habrá streaming de todo el evento, pero no especiamente de lo que haremos nosotros.

Si que, seguramente, tendremos un repositorio abierto de github donde iremos comiteando en directo lo que vayamos haciendo.

kusfo79 no abandones este tutorial, please.

Ando parado con el port de The Banketh para SMS aunque hay avances desde la última vez que postee. Ya tiene colisiones tanto con el escenario como con los enemigos, el menú de objetos funciona (y se lo he asignado al botón 1), el marcador contabilizando puntos y vida, e incluso el arma escupitajo ya funciona, etc...

Pero llevo semanas sin cogerlo porque existe algún tipo de error de memoria que hace que cuando paso por algun sitio, colisione con algo invisible que hace que crahsee; y por pereza lo he dejado aparcado y me he puesto a seguir enredando con la NES.

Pero prometo seguir actualizando las novedades con alguna rom.

Buenas!

Si, estuve preparando cosas de Master para lo del fnac'n pixels, y no me he puesto con esto, voy a ver si lo retomo estos días de Agosto!!

Sigo trabajando en el proyecto.
He estado estos meses con mucho trabajo y poco tiempo. Ya he implementado el sistema de colisiones con escenario, armas, objetos, etc. .

Tenéis la alpha 0.05 a vuestra disposición: https://www.dropbox.com/s/islryjkjhz143 ... 5.sms?dl=0

¿Alguien sabe si se puede fabricar esto físicamente?

Te he contestado en smspower, pero por si acaso:
- PCB's no son complicadas. Ichigo Bankai ha fabricado (y le vendió algunas a @tailsnic ) y db-elec tiene un prototipo de placa.
- Carcasas de cartucho: No hay nada. En 1985Alternativo hace tiempo que las queremos hacer, pero no lo hemos tirado adelante por que parece que el interes de momento no es muy alto....

PD: La semana que viene subiré la siguiente lección del tutorial!

kusfo79 escribió:Te he contestado en smspower, pero por si acaso:
- PCB's no son complicadas. Ichigo Bankai ha fabricado (y le vendió algunas a @tailsnic ) y db-elec tiene un prototipo de placa.
- Carcasas de cartucho: No hay nada. En 1985Alternativo hace tiempo que las queremos hacer, pero no lo hemos tirado adelante por que parece que el interes de momento no es muy alto....

PD: La semana que viene subiré la siguiente lección del tutorial!

Pues sin carcasa no hay party.

Si no lo puedo fabricar, tendré que prescindir de esta versión en el proximo crowdfunding que quiero hacer de The Banketh

Es que ni en Aliexpress hay nada

Seguro que no hay nada, por que en Smspower hace 15 años que esperan que haya carcasas....no las hay en ninguna tienda online de ningún lado del mundo

En todo caso, nosotros queremos sacar juegos de master, por lo que en un momento o otro, se harán.

Mmmm... ¿las carcasas de Mega Drive valen para Master System?

malamente...entran, pero los enganches en las pcb's tienes que hacerlos diferentes.

Es difícil sacarle a ichigobankai pcbs, ojo. Yo me lo tuve que currar, y ahí que tengo mis preciosas repros con caja en la vitrina.

Sinó, db-elec tiene colgada en su web los esquemas de las pcb's

PCB's master system

Bueno, ya he conseguido arreglar las imagenes que no se veían, y tengo la lección siguiente bastante lista, sprites con recarga!!

@kusfo79 , una duda, ¿existe algún emulador que permita saltarse el límite que tiene la MS y por lo tanto no mostrar parpadeos?.

Creo que la experiencia de juego mejoraría muchísimo. Me he puesto ahora con el Jang Pung 3, que es una maravilla, pero que petardea que da gusto.

Ahora me viene a la cabeza otra duda, ¿existe algún emulador que permita eliminar las ralentizaciones que se dan en algunos juegos?. Estoy pensando ahora en el Robocop Vs Terminator, que lo mire por donde lo mire, me parece otra obra de arte en la MS, pero que a veces se ralentiza.

Estoy emulando con Emulicious bajo Ubuntu, no se si es una buena opción o las hay mas recomendables para Linux.

Muchas gracias!.

No se si con Wine anda, pero el Kega Fusion emula master system, y tienes la posibilidad de quitar el flicker de los sprites. Lo de overclockear el procesador si que no se de ningún emulador que lo haga...

@kusfo79 , ok, a ver si lo miro mañana. Ahora ya se donde buscar y que palabra.

Un saludo.

Edit: Pues ya lo he probado, no me he podido resistir. El problema es que Kega Fusión, no me carga correctamente Jang Pung 3, es injugable. Pero he probado Double Dragon, y no parece que vea flickering, también he probado el de Robocop vs Terminator. De todas formas, me gustaría ir haciendo mas pruebas con y sin la opción marcada a ver.

Lo del overclock sería muy interesante también.

Hay vídeos por youtube de gente que overclockea la Master System.

En cuanto al parpadeo, en casos como el Double Dragon creo que es más, en la mayoría de los casos, por las prioridades de los sprites (en éste frame este sprite va delante, en éste detrás) que por el límite de sprites por línea. Creo que esto se debe a que, como en cualquier momento se puede dar el límite de sprites por línea, los sprites se van definiendo en cada frame en base a una cola circular y por eso las prioridades cambian en cada frame.

Gammenon escribió:En cuanto al parpadeo, en casos como el Double Dragon creo que es más, en la mayoría de los casos, por las prioridades de los sprites (en éste frame este sprite va delante, en éste detrás) que por el límite de sprites por línea. Creo que esto se debe a que, como en cualquier momento se puede dar el límite de sprites por línea, los sprites se van definiendo en cada frame en base a una cola circular y por eso las prioridades cambian en cada frame.

Esto que comentas se hace "a proposito", precisamente para evitar que solo se muestren los sprites más a la izquierda. Si no lo implementa el programador, habría enemigos que nunca se imprimirian, o siempre les faltaria un cacho.

kusfo79 escribió:

Gammenon escribió:En cuanto al parpadeo, en casos como el Double Dragon creo que es más, en la mayoría de los casos, por las prioridades de los sprites (en éste frame este sprite va delante, en éste detrás) que por el límite de sprites por línea. Creo que esto se debe a que, como en cualquier momento se puede dar el límite de sprites por línea, los sprites se van definiendo en cada frame en base a una cola circular y por eso las prioridades cambian en cada frame.

Esto que comentas se hace "a proposito", precisamente para evitar que solo se muestren los sprites más a la izquierda. Si no lo implementa el programador, habría enemigos que nunca se imprimirian, o siempre les faltaria un cacho.

A eso me refiero, que es el método por el cual aún con posibles parpadeos se pinta todo, sino habría cosas que nunca se pintaría o muy deficientemente

Después de muchos días con parón...añadida lección 6!

¿Donde?

Diskover escribió:¿Donde?

En el listado del primer post, la última entrada.

Si no voy mal la técnica esta de recarga se usa para el sprite principal y la carga normal para los enemigos, por ejemplo?

Depende mucho del juego, claro. Un buen ejemplo es el streets of rage. En él, hay unos cuantos tiles (de memoria creo que 12), reservados para el sprite protagonista (que tiene un cojón de animaciones). Luego, solo suelen salir enemigos de un solo tipo a la vez, y lo que se hace es cargar todos los frames de ese enemigo, que igual ocupan en total unos 60 tiles, y pueden meter por ejemplo tres de estos enemigos, a la vez realizando cada uno diferentes movimientos al mismo tiempo.

kusfo79 escribió:Depende mucho del juego, claro. Un buen ejemplo es el streets of rage. En él, hay unos cuantos tiles (de memoria creo que 12), reservados para el sprite protagonista (que tiene un cojón de animaciones). Luego, solo suelen salir enemigos de un solo tipo a la vez, y lo que se hace es cargar todos los frames de ese enemigo, que igual ocupan en total unos 60 tiles, y pueden meter por ejemplo tres de estos enemigos, a la vez realizando cada uno diferentes movimientos al mismo tiempo.

Osea que en el caso del SOR hay 3 slots, uno por cada enemigo, que se va actualizando de forma independiente, según lo que haga cada uno? Porque hay que tener en cuenta que la SMS no puede hacer flip de los tiles de los sprites y por lo tanto si un enemigo se gira ya no puedes usar los tiles del otro que estaba mirando en la otra dirección.

No, no, el prota tiene su slot, y luego, por ejemplo, estan cargados todas las animaciones de Galsia, en las dos direcciones, con lo que el juego te saca, quizá tres Galsias, que pueden animarse cada uno a su bola por que tienen todos los tiles necesarios ya en VRAM.

Pregunta, si el SOR mueve 3 Galsias y al protagonista, ¿no podrían haber decidido 2 protas y 2 Galsias?
¿Tiene el mismo peso para la MS el que sean 3 Galsias y 1 prota que 2 Galsias y 2 protas?

Para mi no hay color entre las dos posibilidades.

Gracias!.

kusfo79 escribió:No, no, el prota tiene su slot, y luego, por ejemplo, estan cargados todas las animaciones de Galsia, en las dos direcciones, con lo que el juego te saca, quizá tres Galsias, que pueden animarse cada uno a su bola por que tienen todos los tiles necesarios ya en VRAM.

Ah ya veo el tema Entonces en un juego de ese tipo, o en un plataformas por ejemplo, habría que partir en mapa en zonas de enemigos para ir cargando los enemigos de la zona por donde vaya el jugador, no? Sería una forma de implementarlo.

aranya escribió:Pregunta, si el SOR mueve 3 Galsias y al protagonista, ¿no podrían haber decidido 2 protas y 2 Galsias?
¿Tiene el mismo peso para la MS el que sean 3 Galsias y 1 prota que 2 Galsias y 2 protas?

Para mi no hay color entre las dos posibilidades.

Gracias!.

No, por que entonces tendrías que ir updateando los dos protagonistas todo el rato, con lo que sería el DOBLE de tiempo de recargar tiles "al vuelo". Sería factible si tuviéramos TODOS los frames cargados ya.

Gammenon escribió:

kusfo79 escribió:No, no, el prota tiene su slot, y luego, por ejemplo, estan cargados todas las animaciones de Galsia, en las dos direcciones, con lo que el juego te saca, quizá tres Galsias, que pueden animarse cada uno a su bola por que tienen todos los tiles necesarios ya en VRAM.

Ah ya veo el tema Entonces en un juego de ese tipo, o en un plataformas por ejemplo, habría que partir en mapa en zonas de enemigos para ir cargando los enemigos de la zona por donde vaya el jugador, no? Sería una forma de implementarlo.

Depende mucho del juego, en el sonic o el alex kidd, pro ejemplo, los enemigos tienen muchas pocas animaciones y son pequeños, así que puedes tener varios juntos sin problema.

Añadida nueva lección! ahora ya podemos controlar el bicho y hacerlo andar y saltar!