Tutorial muy básico de C para Master System

Archivado
1…9, 10, 11, 12, 13…21
si veis el código fuente de ihx2sms está limitado a 1024KB.
Hola, acabo de leer esto en SMSPower, que lo dijo @BcnAbel76 :

"Really I am sure Master System can read Megadrive Multipad and use it for make new games supporting 4 Players game (I think it would be nice to implement in devkitSMS)"

Me ha dado curiosidad, ¿se sabe si se podría hacer eso?.
@Paspallas
pos ya tenemos la respuesta de momento!

@aranya
Se habria de mirar como rula electronicamente la cosa!
@kusfo79 gracias.

Un saludo.
http://www.raphnet.net/divers/documenta ... ltitap.txt

http://www.raphnet.net/divers/genesis_m ... dex_en.php

¿Hay algún bomberman homebrew para sms?

*edit*

Imagen
Imagen
Imagen


Parece ser que sí: http://www.smspower.org/Homebrew/BOoM-SMS

Yes...you need the specific multitap made for it.

I've added/fixed chained explosions, fixed some little things (animated death / results). I'll send a new version when i'll add the random/destructible playfield blocs.
View user's profile


Por lo visto usa su propio protocolo de multitap.
@wah_wah_69
te iba a contestar, pero te has adelantado, jejeje
Por cierto, estoy pensando en continuar el tutorial con un ejemplo más completo, usando también GSLib, etc, y también las nuevas herramientas, como assets2bank, etc. Os molaría algo así?
Yo he estado parado estos meses porque se me hacía cuesta arriba ponerme a programar por vicio después de estar más horas de las recomendadas programando por trabajo [buuuaaaa] . Eso, y que me frustré un poco intentado cambiar la paleta a mitad de cada scanline (soy incapaz de cambiarla en todas las líneas en el mismo momento y por las pruebas que hice, no veo una solución posible). En septiembre-octubre me pretendo poner otra vez a tope con ello.

A mí me molaría mucho que continuaras el tutorial porque me parece de los mejores y más útiles hilos que se han hecho en eol en los años que llevo por aquí.
Guai, a ver si tengo tiempo y me pongo para hacer las siguientes lecciones!
@kusfo79 , estaba leyendo por SMSPower, y al entrar en el juego F16 Fighting Falcon, me encuentro con esto:

Link Cable
It is possible to play in a simultaneous 2-player mode using a special cable to link two Mark III consoles via their keyboards' printer ports.

No sabía que se podía hacer eso. Conozco un juego de MD, no recuerdo el nombre, es tipo Doom, donde se hace algo similar, pero en MS no lo sabia.

¿Que nos puedes contar sobre esta opción?. ¿Sabes si está emulada?.

Un saludo.
@aranya

Pues lo había oído de que existía esta opción, pero ni la he probado, ni se si está emulada, mmmm (de hecho solo va en MARK-III, no en Master System). Luego hecho un ojo a ver
De qué va el GSlib?
@kusfo79 , gracias. Perdona la confianza, pero es que al leer sobre MS, pues siempre pienso en este hilo.

Un saludo.
@Gammenon

Pues es una libreria para la gestión y realización de scroll. La he tocado poco, pero la usé para esto:
https://github.com/kusfo/mastersystembrawler
Y lo puedes ver en acción aquí hacia el final:
https://www.youtube.com/watch?v=TobXFuXtmXA

@aranya
No pasa nada! de hecho, mirando en smspower, veo que hay el esquema del cable, pero no pone ni que Meka ni Emulicious lo emulen...
@kusfo79 , gracias. Es que me resulta muy curioso. No sé cómo se jugará así. ¿Se verá al avión de tu compañero en pantalla?.

¿Que más juegos lo podrían haber utilizado?.
kusfo79 escribió:@Gammenon

Pues es una libreria para la gestión y realización de scroll. La he tocado poco, pero la usé para esto:
https://github.com/kusfo/mastersystembrawler
Y lo puedes ver en acción aquí hacia el final:
https://www.youtube.com/watch?v=TobXFuXtmXA

@aranya
No pasa nada! de hecho, mirando en smspower, veo que hay el esquema del cable, pero no pone ni que Meka ni Emulicious lo emulen...

Había leído sobre esa librería pero no me acordaba del nombre. Los mapas los puedes hacer con tiled, no? Pinta muy muy bien, me molaría hacer un contra con eso
@aranya
Pues no lo he probado, pero supongo que si, es como un simulador de vuelo a dos players, y puede ser que llegues a encontrarte con tu compañero... En todo caso, esto de que use el puerto de teclado lo descarta para las master systems...

@Gammenon
Si, puedes usar Tiled, y luego su herramienta personal UGT (nada que ver con el sindicato XD), para optimizar las paletas, metatiles, etc.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@kusfo79 ¿no te has planteado ser un hombre de verdad en el futuro y aprender ensamblador?
@Sexy MotherFucker

Hice mis pinitos en su tiempo, pero no creo que para el 90% de los juegos, te dé ninguna ventaja respecto al C....y si ya en C cuesta horrores debugar en una master system (nada de gdb, no puedes imprimir si se corrompe la vram), en ensamblador debe ser una pesadilla.
Sexy MotherFucker está baneado del subforo por "faltas de respeto"
@kusfo79 ¿y en tu opinión para qué tipo de juegos en ese 10% restante sí sería conveniente emplear ASM para obtener resultados óptimos?
@Sexy MotherFucker
A ver, de los juegos de master existentes, los que gastan más CPU son los que intentan dibujar directamente a la VRAM, total o parcialmente, como F-16 Fighting Falcon, Golden Axe, Altered Beast, Mortal Kombat, etc

Luego, los Sonics, especialmente los de Aspect, parecen chupar batsante CPU, pero no estoy seguro de para qué, quizá para descomprimir datos de los niveles en la ram...
Sexy MotherFucker escribió:@kusfo79 ¿no te has planteado ser un hombre de verdad en el futuro y aprender ensamblador?

Macho deja de cambiarte el avatar que me mareas XD. Con C puedes ir a cualquier parte :-P
Creo que él no quiere ir a cualquier parte.
Él quiere ir a donde no es posible llegar por otros medios.
Gammenon escribió:
Sexy MotherFucker escribió:@kusfo79 ¿no te has planteado ser un hombre de verdad en el futuro y aprender ensamblador?

Macho deja de cambiarte el avatar que me mareas XD. Con C puedes ir a cualquier parte :-P


Ehh las babymetal molan [carcajad] [carcajad] aunque el de snk me estaba molando.
@Sexy MotherFucker está pensando en un Mighty Paprium.

Yo os veo capaces, que risas íbamos a echar a cuenta de Fonzi xD
Hola a todos. Estaba jugando al Mortal Kombat 1 de MS, que lo tengo en cartucho. Fue una obsesión de cuando tenía la MS, aunque nunca lo pude tener. Muchos años después lo compré.

Bueno, lo estoy jugando en mi MS2, pero con el mando inalámbrico de Krikzz. Tengo algunas dudas y algunos comentarios que me gustaría compartir con vosotros.

El juego, si lo paro, y me quedo mirandolo, me parece que tiene unos gráficos muy buenos. He activado el modo sangriento, y he estado jugando bastante rato. Desde mi punto de vista, y jugandolo a 50hz, el juego se mueve bastante bien, aunque un pelín brusco. Está bastante bien surtido de personajes, y cada personaje tiene bastantes ataques especiales y también tienen un fatality. Ahora bien, solo tiene 2 escenarios, y la música me parece bastante mejorable. Tampoco hay voces digitalizadas. He visto en SMSPower que el juego tiene 4 megas.

Otra cosa que me llama la atención, no se si será por el mando de Krikzz, es que resulta bastante complicado realizar los ataques especiales. En teoría, por ejemplo, tirar el arpón con Scorpion es atrás, atrás y puñetazo, pero es que me sale 1 de cada 3 veces con suerte.

Mis dudas:

1- ¿El que resulte complicado hacer un ataque especial como el arpón de Scorpion, es por algún asunto de programación, o es mi culpa?

2- Si el juego hubiera tenido 8 megas, es decir, el doble de espacio, ¿no creéis que hubiera podido ser una versión increíble?, es decir, con todos los personajes, mas escenarios e incluso alguna voz digitalizada como Fight!.

3- Cuando estoy jugando tengo la sensación de que este juego se quedó a las puertas de ser una gran versión de MK, y que solo les faltó pulirlo un poquito mas. ¿Una persona que sepa programar en MS puede pulir el juego, o no se puede acceder al código y se debería de hacer desde cero todo el juego?, es decir, ¿el MK de MS se puede hackear para mejorarlo o no se puede?.

Muchas gracias.
Con más ROM se podrían haber metido más personajes y escenarios, seguramente. Lo del control puede ser que vaya a un framerate bajo y/o inconsistente, lo suficiente para que los controles no se noten fiables. En cuanto a las voces, el FIGHT podría entrar en una ROM pero lo de reproducir voces implica parar todo ya que es un trabajon hacer eso para el hardware de la Master System. No tiene un canal ADPCM o algo así que tiene la NES, sino que tiene que hacerlo por "fuerza bruta", lo cual consume toda la CPU prácticamente.
@Gammenon , gracias. Quizá hubieran podido meter un "Choose your Fighter" en la pantalla de selección de personaje.

¿Cómo está el tema de hackear el juego para mejorarlo?, ¿Que necesitan los programadores para hacerlo?.
aranya escribió:@Gammenon , gracias. Quizá hubieran podido meter un "Choose your Fighter" en la pantalla de selección de personaje.

¿Cómo está el tema de hackear el juego para mejorarlo?, ¿Que necesitan los programadores para hacerlo?.


Bueno, lo de hackear suele implicar desensamblar el juego (convertir el binario puro en instrucciones de ensamblador, algo no tan sencillo por que has de ser capaz de diferenciar código y datos), estudiar ese código y ver que bytes cambiar para obtener el resultado deseado....

Si es una tontería, el hack puede ser relativamente fácil (como los de GG a SMS o lo de añadir voces digitalizadas que está haciendo Maxim) o un infierno si es añadir material nuevo xD
@kusfo79 , vaya que complicado. ¿Que opinión te merece a ti el MK de la MS?

Con 8 megas y un poquito más de tiempo para pulir la jugabilidad hubiera quedado muy redondo desde mi punto de vista. Es una lastima que el espacio para los juegos fuera tan limitado debido al coste.
aranya escribió:@kusfo79 , vaya que complicado. ¿Que opinión te merece a ti el MK de la MS?

Con 8 megas y un poquito más de tiempo para pulir la jugabilidad hubiera quedado muy redondo desde mi punto de vista. Es una lastima que el espacio para los juegos fuera tan limitado debido al coste.


El SF2 y los MK son trabajazos, pero luego ves el Jang Pung 3, que es todo a base de sprites y yo al menos flipo mucho. Creo que se podrían haber hecho juegos de lucha muy vistosos y decentes para la SMS:

Imagen
@Gammenon , yo lo he jugado en emulador. Para la MS no tengo Flashcart, pero para la MD si, y creo recordar que el juego no funcionaba bien. Que mala memoria tengo.

Es un género que estaba en pleno apogeo en esa época, no entiendo como no lo explotaron un poco más. A las 8 bits le sobran juegos de conducción, para los cuales había mucha limitación, y le faltan Vs, que podrían haber quedado muy resultones.
@aranya

Yo no lo jugué en la época, y ahora me parece bastante tosco...aparte que lo de los gráficos digitalizados con una paleta tan pequeña no quedan muy bien....

Y lo de los 8 megas, pues solo los llegaron a usar en Brasil, no creo que lo hubieramos visto por aquí...
@kusfo79 , yo tampoco lo jugué en su época, pero estuve mucho tiempo obsesionado por una captura que salió en una Hobby.

Hacía años que no lo tocaba, pero he estado jugando últimamente y me gusta, no se.

Creo recordar que el juego en su día era muy caro, ahora no estoy en casa para ver las Hobby, pero me suena que mientras los demás costaban 5990 ptas, este costaba 6990 ptas.

No tiene razón de ser el precio, ¿No?, porque no guarda partida, no son más megas, no lleva nada extra. Bueno, quizá por la franquicia de MK.
@aranya
Creo que el cartucho es totalmente normal, pero puede ser que lo encarecieran por la fama de la franquícia, no sé...
Hola, es que estaba leyendo el hilo de SMSPower sobre el nuevo juego homebrew, Flight of Pigarus, y veo que le están preguntando cómo hace scroll vertical infinito, cómo maneja tantas colisiones, y como graba la repetición, si he entendido bien.
¿Esto se lo preguntan porque ha usado ensamblador como lenguaje o porque es algo nunca visto en MS?

Invoco a @kusfo79 porque es su hilo.
@aranya

Es mi hilo y me lo follo cuando quiero!

El tema no es tanto si lo ha hecho en ensamblador o en C, sinó como ha solucionado los problemas que se indican. Por ejemplo, el tema del fondo realmente grande. Si realmente guardaramos todo ese mapeado tal cual, ocuparia un cojón (cada pantalla entera son 1536 bytes), con lo que con un mapa de unas 10 pantallas de alto, ya ocuparías los 16kb que te caben en un banco de memória. ¿Como lo ha optimizado? puede haber usado metatiles de 16x16 o 32x32, y aparte usar compresión para el tilemap, etc.

Lo de las colisiones es algo parecido, puede haber optado por muchas estrategias diferentes. A un desarrollador moderno le puede tenar usar división por quads para detectar colisiones, pero eso es demasiado para un humilde z80, probablemente ha usado un método mucho más customizado a las necesidades de su juego.
@kusfo79 , entiendo. Yo lo decía porque alguna vez se ha hablado de que con ensamblador se puede estirar un poquito más el rendimiento de la MS, y pensaba que el rendimiento del juego era más por el lenguaje usado.
@aranya Eso influye, y mucho, pero igualmente es interesante ver como ha solucionado esos problemas :-)
@kusfo79 , otra pregunta, si tuvieras que dar un porcentaje, ¿Que % más crees que se puede sacar a una consola como la MS usando ensamblador en lugar de C?.

¿Sería apreciable para una persona?, Quiero decir, si el mismo juego lo programa la misma persona, usando ensamblador y C, podríamos notar que juego está hecho con cada lenguaje?. Claro, tiene que ser un juego que sea exigente. ¿Con ensamblador habría más elementos en pantalla moviendose más fluido, o sería imperceptible?
@aranya cuando usas C lo pasas por un compilador y lo traduce a ensamblador, en un mundo perfecto ese código estaría perfectamente traducido y ultra optimizado pero eso no es así, al escribirlo directamente en ensamblador tienes el control total de lo que estás haciendo en cada momento, por lo tanto puedes optimizar de manera más efectiva teniendo en mente lo que puede hacer la máquina.
Después está la opción intermedia que consiste en coger ese código traducido a ensamblador desde C y retocarlo.
Que alguien me corrija si me he equivocado en algo pero creo que no, vamos.
@aranya @Shotdie

Como has comentado, en un mundo ideal, el producto de usar ensamblador o C sería igual, pero claro, los compiladores no són tan inteligentes. Pero por ejemplo, una persona programando muy mal en ensamblador, comparado con el mismo programa bien hecho en C, y pasado por optimizador, puede resultar que el C va más rápido que en ensamblador directamente.
@kusfo79 @Shotdie , gracias por la explicación. Imagino que los comiladores también irán evolucionando, y que por lo tanto ser harán mas eficientes. De todas formas, ¿todo lo que se puede hacer con ensamblador, se puede hacer con C y luego pasarlo por el compilador?.

Imagino que los compiladores tendrán sus limitaciones, además del comentado sobre la eficiencia al convertir C a ensamblador.
aranya escribió:@kusfo79 @Shotdie , gracias por la explicación. Imagino que los comiladores también irán evolucionando, y que por lo tanto ser harán mas eficientes. De todas formas, ¿todo lo que se puede hacer con ensamblador, se puede hacer con C y luego pasarlo por el compilador?.

Imagino que los compiladores tendrán sus limitaciones, además del comentado sobre la eficiencia al convertir C a ensamblador.

Los compiladores evolucionan, el tema es quien se va a molestar en hacer un compilador de la hostia para la Master System.
Respecto a tu pregunta, en teoría sí, aunque si quieres llegar al límite lo mejor sería usar ensamblador porque si eres un crack y te conoces la Master System al dedillo tu sabrás mejor que nadie donde irá cada cosa y como hacer las cosas de manera que funciona.
Imagínate un compilador como un señor que traduce un libro que has escrito al alemán (por ejemplo) y sin revisarlo tú después, por muy buena que sea siempre se van a quedar cosillas aunque si lo revisas tú (optimizas el código que te ha dado el compilador) te saldrá algo mejor, o incluso mejor si lo reescribes tú en alemán.
Si te interesan estos temas échale un vistazo a un canal que se llama Gamehut, es un antiguo desarrollador de Traveler Tales y explica como hicieron muchos trucos de sus juegos (Sonic 3D Blast,Toy Story, Mickey Manía,Sonic R..)
@Shotdie , buen ejemplo lo del libro. Por cierto, me parece que hay un compilador muy bueno para la MS, el devkitsms creo que se llama. Bueno, no se si es un compilador, pero la idea que yo tenía es que programas en C, y te lo pasa a ensamblador. Alguna vez he leído por aquí que tiene algunas limitaciones, como el tamaño máximo de la rom, por ejemplo no puedes hacer roms igual de grandes que las de TecToy. Bueno, estoy hablando de memoria sobre lo que he ido leyendo por ahí.
Creo que es de Sverx.
aranya escribió:@Shotdie , buen ejemplo lo del libro. Por cierto, me parece que hay un compilador muy bueno para la MS, el devkitsms creo que se llama. Bueno, no se si es un compilador, pero la idea que yo tenía es que programas en C, y te lo pasa a ensamblador. Alguna vez he leído por aquí que tiene algunas limitaciones, como el tamaño máximo de la rom, por ejemplo no puedes hacer roms igual de grandes que las de TecToy. Bueno, estoy hablando de memoria sobre lo que he ido leyendo por ahí.
Creo que es de Sverx.


devkitSMS es una colección de librerias (podríamos decir que un SDK). Usa un compilador que se llama SDCC, que es moderno y multiproposito, y puede compilar para varios procesadores viejunos. Eso sí, eso provoca que no esté especializado en Z80

Sobre el ejemplo de @Shotdie del libro, es muy, muy inspirador :-D
Hola, ya estoy otra vez por aquí, mira que soy pesadooooo.

Estaba leyendo en SMSPower, el hilo en el que Kagesan va explicando cómo ha hecho el juego, y va respondiendo preguntas.

Me ha gustado mucho esto:

I also used them to determine how many objects my game can handle without slowdown.

Se refiere a las herramientas de Emulicious. Mi pregunta es, como sabemos la potencia de la MS, ¿No podemos saber cuándo empezará a ahogarse sin necesidad de comprobarlo empíricamente?, es decir, sobre papel podríamos saberlo ¿no?.
Otra pregunta, en los 80 y 90, la gente que hacía juegos de MS ¿como hacía estás comprobaciones?. ¿Había emuladores o trabajaban con hardware real para probar?.

Gracias!!
@aranya
Pues para complementar lo que decíamos en el hilo del Paprium que es casi imposible estimar plazos...también es casi imposible estimar correctamente costes!

Ojo, si que se puede tener una idea del coste al nivel de si es linea, quadrático o logaritmico (el famoso O(n)), pero eso es un valor a nivel de orden de magnitud, no concreto.

Programando en C, no estas seguro de quantos ciclos ocuparan tus funciones, ya que la traducción al ensamblador no es determinista del todo. Trabajando directamente en ensamblador es probable que tengas bastante claro cuantos ciclos duran tus funciones, pero probablemente no sabrás cuantas veces se puede llegar a llamar tu función "checkCollision()" en un mismo frame hasta que te pones con el emulicious a hacer un estudio de tu rjuego.
Feliz año nuevo masterreros!

Acabo de caer... cómo está el tema del sonido FM en cuanto a herramientas de desarrollo? Porque las librerías estas creo que no contemplan esta opción.
Está fatal, por que no hay algo equivalente a la PSGLib pero para el FM...de hecho si miras en smspower, lo hemos discutido bastante. Por otro lado, hay pocos trackers que accepten el chip fm de la master para componer...

Una opción, es hacer lo que hizo Zipper en su homebrew D.A.R.C. Compuso con un tracker de MSX (Moonblaster), y convirtió una libreria player de MSX a master. De hecho compartió su código (en ensamblador),y hace tiempo que estoy con la copla de hacer un wrapper de C por encima, pero el tiempo....

PD: Debería continuar el tutorial pero ya xD
1022 respuestas
Archivado
1…9, 10, 11, 12, 13…21
Volver a Consolas clásicas