Aspectos generales
- Puede participar cualquier persona o grupo desarrollador que lo desee.
- Cada participante puede presentar tantas entradas como desee.
- Solamente se aceptarán aquellos programas que sean videojuegos, sea cual fuere su género (aventura, plataformas, RPG, puzzle, arcade, etc.).
- Los juegos presentados tienen que ser originales. No se permiten plagios ni copias de otros ya existentes en su totalidad o en parte (música, gráficos, rutinas, etc.). Los juegos que incumplan esta regla quedarán automáticamente descalificados.
- Si el autor lo desea, podrá incluir información extra sobre el juego: comentarios del código, imágenes, historia del juego, etc. Estos contenidos no serán calificados.
- Los juegos se enviarán acompañados del código fuente original.
- Los participantes no podrán enviar versiones del juego posteriores al presentado en un principio.
- Los archivos se enviarán adjuntos a un correo electrónico a la siguiente dirección: webmaster@konamito.com. En el cuerpo del mensaje se indicarán obligatoriamente los siguientes datos:
- Nombre del juego.
- Nombre o nick del autor (que será el que se haga público).
- Email de contacto.
- Si tres días después del envío del correo electrónico no se recibe respuesta, se recomienda reenviarlo.
Plazos
- El plazo de presentación de entradas a concurso comienza el 11 de abril a las 00:00:01 horas y termina el 28 de febrero de 2013 a las 23:59:59 horas (horario de Canarias) . Una vez finalizado el plazo de entrega no se admitirá ninguna entrada, sin excepción. Es recomendable no dejar para el último momento el envío del correo electrónico correspondiente porque la entrada podría quedarse fuera de concurso.
- Antes del 20 de marzo de 2013 a las 23:59:59 horas (horario de Canarias) la organización debe haber recibido las valoraciones correspondientes a cada uno de los juegos de los participantes en el concurso. En caso de un participante no entregue sus valoraciones sobre el resto de los juegos , será descalificado (leer en el apartado Jurado, más abajo).
Uso del MSX-BASIC
- Los juegos tienen que estar programados completamente en MSX-BASIC, no estando permitido el uso de lenguaje ensamblador en general, MSX-BASIC compilado, etc. Sólo se permite una única rutina en ensamblador, idéntica para todos los participantes. Dicha rutina, cuya longitud es de 12 bytes, será la siguiente:
LD HL,ORIGEN ; Origen en RAMLD DE,DESTINO ; Destino en VRAMLD BC,LONGITUD ; Longitud del bloque a copiarJP LDIRVM ; Salto a la rutina de copia
- Con esta rutina se pueden cargar gráficos en VRAM de una manera más rápida. La forma de cargar esta rutina en memoria será a través de POKEs, para ser posteriormente llamada mediante el uso de las instrucciones DEFUSR y USR. Podrá localizarse en cualquier parte de la RAM accesible desde BASIC y se podrán cambiar los valores de los tres parámetros tantas veces como sea necesario.
- El juego podrá ser presentado en formato .CAS, .ROM o .DSK.
- El juego puede estar compuesto por uno o varios bloques grabados con las instrucciones SAVE»CAS:» o BSAVE»CAS:». Se permite que el juego pueda realizar cargas desde cinta, abriéndose, por tanto, la oportunidad de presentar juegos multicarga.
- Si el juego lo requiere, podrá solicitar al jugador que rebobine la cinta.
- En caso de presentarse en formato DSK, se permite la carga de datos y gráficos desde disco. Para ello se pueden usar las instrucciones LOAD y BLOAD. Opcionalmente el juego podrá grabar datos en disco (utilizando BSAVE) para guardar datos que puedan ser recuperados en otra ejecución del juego (tales como records, progreso, etc.). El uso arbitrario del disco para la creación de juegos puede penalizarse de la manera que se detalla en el apartado Jurado (ver más abajo).
- En el caso de bloques binarios, éstos solamente podrán contener datos, debiendo ser cargados con la instrucción BLOAD»CAS:» (sin autoejecución).
- En el caso de bloques con código en BASIC, cada listado debe cumplir todas y cada una de las restricciones que se listan a continuación, sin excepción:
- Prohibido el uso de la instrucción CALL.
- DEFUSR: Se pueden definir llamadas a rutinas en código máquina de la BIOS y a la rutina en ensamblador anteriormente mencionada.
- OUT: Por compatibilidad sólo se permitirán instrucciones OUT a las direcciones del PSG y del VDP, si se accede a este último mediante OUT se deberá garantizar una total compatibilidad con el estándar (leyendo los valores adecuados de la BIOS con la instrucción PEEK).
- POKE: Se puede usar en cualquier dirección e la memoria desde el final del programa hasta &HFFFF, es decir, no se permite modificar el programa con POKE (prohibido código automodificable).
- USR: Se podrán realizar llamadas a rutinas en código máquina previamente definidas con DEFUSR respetando las restricciones para dicha instrucción. El paso de parámetros, tanto de salida como de entrada, sí está permitido, siempre que sea a través de la instrucción USR.
- Se permite el uso de las instrucciones LOAD (con y sin autoejecución) y RUN para la carga de bloques de programa en BASIC, tanto desde CAS como desde DSK. La carga de bloques de datos se realizará única y exclusivamente con la instrucción BLOAD (sin autoejecución), desde disco podrá utilizarse el parámetro S para cargar datos directamente a VRAM. Si se desea se podrán incluir los nombres de los ficheros a ser cargados.
- Prohibidas las instrucciones relacionadas con la impresora.
- Prohibidas las instrucciones añadidas por alguna extensión al MSX-BASIC (cartuchos con ampliaciones, etc.) excepto las mencionadas de MSX-Disk BASIC.
- Los listados MSX-BASIC pueden tener el número de líneas que se desee, siempre numerándose 10 en 10.
Jurado
- El jurado estará formado por todos los participantes en el concurso.
- Cada participante tendrá que valorar al resto de entradas a concurso. En caso contrario quedará descalificado automáticamente.
- El fallo del jurado es inapelable.
- Se valorarán los juegos conforme al siguiente criterio (ejemplo de votación de un miembro del jurado para un solo juego):
- El miembro del jurado valorará por separado cuatro aspectos del juego (entre 1 y 95), a saber: jugabilidad, originalidad, gráficos y sonido. Se calcula la nota media.
- Hay 5 puntos de bonificación que el miembro del jurado repartirá como desee entre los cuatro aspectos mencionados en párrafo anterior. A la nota media calculada anteriormente se le suma el valor más alto de bonificación otorgado (que será de 5 puntos máximo si van todos a la misma característica y de 2 puntos mínimo si se reparten entre las cuatro características a valorar). El número obtenido será la nota final del miembro del jurado para ese juego que llamaremos resultado parcial.
- Se repite la operación descrita en los párrafos anteriores con cada uno de los miembros del jurado y finalmente se calcula la nota media de los resultados parciales que será la nota final.
- Es obligatorio que cada uno de los miembros del jurado otorgue los puntos de bonificación y justifique con un comentario breve su aplicación en cada aspecto concreto. En caso contrario, el miembro del jurado será descalificado del concurso y sus entradas quedan excluídas.
- Los juegos que hagan uso de la carga de datos desde disco serán valorados de una manera diferente. Si el jurado considera que el uso del disco es arbitrario y no imprescindible entonces el juego perderá TODOS los puntos de bonificación.
Premios
Material relacionado con el MSX y merchandising del Blog. Aún por determinar.
Por otro lado, el concurso está abierto al patrocinio de quien lo desee. Los interesados pueden ponerse en contacto con la organización a través del correo electrónico mencionado más arriba.
Ayudas a los participantes
Gracias a la ayuda de SapphiRe (por la programación) y a la posterior de TheNestruo (por la modificación), está a disposición de los participantes un listado MSX-BASIC con el que se puede cargar la rutina en ensamblador descrita en el epígrafe Uso del MSX-BASIC.
10 DEFFNUB(N) = (((N AND &HFF00)\256) AND 255) 20 DEFFNLB(N) = (N AND 255) 30 SCREEN 1 40 RO=&HC000 50 VD=&H1800 60 NB=&H300 70 AD=&HBFF0 80 GOSUB 100 90 END 100 POKE AD,1:POKE AD+1,FNLB(NB):POKE AD+2,FNUB(NB) 110 POKE AD+3,17:POKE AD+4,FNLB(VD):POKE AD+5,FNUB(VD) 120 POKE AD+6,33:POKE AD+7,FNLB(RO):POKE AD+8,FNUB(RO) 130 POKE AD+9,195:POKE AD+10,92:POKE AD+11,0 140 DEFUSR=AD:AD=USR(0):RETURN
Explicación del código:
- Las líneas 10 y 20 definen dos funciones para obtener el byte alto (Upper Byte) y el bajo (Lower Byte) de una dirección de 16 bits.
- En la línea 30 ponemos SCREEN 1
- La línea 40 define el origen en RAM de los gráficos a volcar (Ram Origin).
- La línea 50 define el destino en VRAM de los gráficos a volcar (Vram Destination).
- La línea 60 define el número de bytes a copiar (Number of Bytes).
- La línea 70 define la posición de memoria donde queremos que se ejecute la rutina (siempre que esté libre, cualquiera).
- La línea 80 llama al cargador de la rutina.
- La línea 90 termina el programa.
- La línea 100 carga el número de bytes.
- La línea 110 carga el destino.
- La línea 120 carga el origen.
- La línea 130 carga la llamada a la BIOS.
- La línea 140 crea el defusr, llama con usr y vuelve.
El resultado es que se vuelcan 768 bytes en la tabla de nombres de la VRAM, es decir, toda la pantalla de SCREEN 1.
También YMN ha querido colaborar con la siguiente explicación:
Además de lo anterior, la solución de codificación de la rutina assembler es implementar una aplicación de producción adaptable, o sea, un programa que hace programas.
La aplicación solicita los mismo datos que el listado que aparece más arriba y genera el código fuente del cargador, implementado para ser llamado con GOSUB.
Para procesar el código generado:
- Posicionar el cursor en la línea 10 y pulsar 2 veces RETURN.
- Teclear GOSUB 10 + RETURN.
1 DEFFNT(N)=(-(N0)):DEFFNH(N)=INT(FNT(N)/256):DEFFNH$(N)=HEX$(FNH(N)):DEFFNL$(N)=HEX$(FNT(N)-FNH(N)*256) 2 DEFFNS$(A$)=STRING$(2-LEN(A$),”0″)+A$:DEFFNX(N)=VAL(“&H”+HEX$(N)) 3 INPUT “DIRECCION DATOS ORIGEN EN RAM: “;RO:RO=FNX(RO) 4 INPUT “DIRECCION DATOS DESTINO EN VRAM: “;VD:VD=FNX(VD) 5 INPUT “NUMERO DE BYTES A COPIAR: “;NB:NB=FNX(NB) 6 INPUT “DIRECCION RAM DEL CARGADOR ASSEMBLER: “;AD:AD=FNX(AD) 7 PRINT “10 FOR I=&H”+HEX$(AD)+” TO &H”+HEX$(AD+11)+”:READ A$:POKE I,VAL(“+CHR$(34)+”&H”+CHR$(34)+”+A$):NEXT:DEFUSR=&H”+HEX$(AD)+”:RETURN” 8 PRINT “20 DATA 21,”+FNS$(FNL$(RO))+”,”+FNS$(FNH$(RO))+”,11,”+FNS$(FNL$(VD))+”,”+FNS$(FNH(VD)); 9 PRINT “,01,”+FNS$(FNL$(NB))+”,”+FNS$(FNH$(NB))+”,C3,5C,00″
Explicación del código:
- Líneas 1-2: Define funciones para obtener el byte alto y bajo en formato alfanumérico, establece el valor hexadecimal con dos dígitos y obtiene el valor de un número en formato decimal complementado.
- Líneas 3-6: Define en formato complementado el origen en RAM de los gráficos a volcar (Ram Origin), el destino en VRAM de los gráficos a volcar (Vram Destination), el número de bytes a copiar (Number of Bytes), y la posición de memoria donde queremos que se ejecute la rutina.
- Líneas 7-9: Genera el código fuente del cargador de la rutina, para ser llamado con GOSUB.
Me encanta el Basic y, como no, me encanta este concurso!!! 🙂
¡A mí también! aunque la verdad es que ahora no tengo tiempo para estas cosas; y lo de la dichosa rutina en ensamblador me termina de tirar p’atrás…
¡Animaros a participar!
Me gustaron las normas del año pasado; este año con varias entradas por participante ya es un concurso redondo!
De hecho, intentaré hacer algún que otro minijuego para ir abriendo boca 😉
ryback: ¿no te animas a participar este año?
Tomi: que la rutina ASM no te tire para atrás; si necesitas ayuda con ella yo te echo un cable. Es más, seguramente me haga algunas utilidades para facilitarme el trabajo; ya las compartiré con todos vosotros
Gracias por el ofrecimiento theNestruo! En el fondo es una cuestión de tiempo, ahora necesitaría primero aprender muchas cosas para hacer algo del nivel de lo que hacéis vosotros. Empecé un juego el año pasado, la idea no es mala (creo) pero seguramente no lo acabaré. Si a alguien le interesa le paso el código de lo que llevo, los gráficos, la generación de pantallas, etc. para continuarlo…
A mi también me pasa lo mismo, aunque se algo de Basic, estoy a años luz de lo que hacéis vosotros. Tendría que ponerme al día, que también lleva su tiempo, y luego ya veríamos… Saludos!!!
Hombre, no quiero prometer nada porque luego quedaría muy mal si al final no me presento, pero me gustaría y no lo descarto. Eso sí, si tengo tiempo y se me ocurre algo original, como es ese fantástico Pérez The Mouse con el que ganaste el año pasado. Saludos! 🙂
A mi me gustaria pa rticipar pero solo con basic puro.
Para hacer algo en assembler, ya sean da tos o la ayuda de esa rutina, prefiero hacerlo en tero en assembler.
Y visto el gran nivel del año pasado, no creo q pueda participar tal como quisiera.
Por otra parte, no poder usar el potencial de un msx2 con disquetera encuanto a graficos, aun siendo msxbasic puro, tambien me hace echarme pa atras.
De verdad de me gustaria hacer algo en basic como cada año, pero creo que se ha perdido la esencia como concurso.
Pero nunca se sabe…quizas me venga la inspiracion del basic y saque algo sin la rutina.
Animo y suerte a los partocipantes.
Hombre, la esencia del concurso yo creo que no se ha perdido en el momento que puedes elegir si quieres o no usar la rutina.
Al contrario, pienso que se ha recuperado la esencia desde el año anterior, en el que tenías que acelerar el emulador al 200% para poder jugar a la mayoría de juegos que se presentaron, lo cual es imposible hacer en un MSX real.
Hablando de «esencias», tambien se puede presentar un juego en basic al MSXDev’12 ya que las reglas te permiten elegirlo si lo prefieres al asm pero no creo que esa sea la famosa «esencia»
A mi también mi tira para atrás el no poder acceder al disco para cargar los gráficos porque limita mucho la cantidad de estos.
De los juegos que hice de niño y estoy haciéndoles un lavado de cara ya solo me faltan 2, el Trogloditas y el Panou pero tanto en uno como en el otro necesito cargar varias veces desde disco los gráficos, así que no me sirven para este concurso.
Hombre, en ese caso, yo tampoco vería mal lo de poder cargar los gráficos de disco… Habrá que convencer a Konamito! 🙂
En el último juego que he hecho para MSX (Trail2) el código fuente ocupa 11 KB, pero la ROM comprimiéndola ha quedado en 128 KB por todos los gráficos que cargo y eso que he tenido que separar en fichero distintos la zona de memoria de la VRAM donde está el color y la zona donde están los carácteres redefinidos porque así entre los 2 ficheros son 12KB ya que si hago un volcado de toda la VRAM son 16KB y la ROM ya salía de 256 KB y no entraba en el concurso de MSXDev que lo máximo son 128KB.
TRAIL2: http://www.youtube.com/watch?v=WuXwqXIzBA0
Te ha quedado muy bien Kotai. Perdí la pista de este juego,¿la versión en BASIC también tenía el doble scroll?
Respecto al concurso, yo tampoco he entendido nunca por qué no puede hacerse un BLOAD desde disco, que también es BASIC. Al final la rutina en ASM no hace más que espantar a posibles participantes. Ánimo Ryback, a ver si le convences! 🙂
Un saludo a todos.
Solo hay una versión que está hecha con Basic pero cargando el compilador XBasic, que para mi sigue siendo Basic ya que lo único que cambia del código es que antes del bucle del juego hago CALL TURBO ON y cuando acaba el bucle un CALL TURBO OFF, el resto del programa es 100% Basic, pero con menos memoria para el listado porque al cargar el XBASIC en memoria te quita 8KB. Cambio memoria por velocidad. Además el XBASIC se puede cargar en cualquier MSX y también desde cinta por lo que el juego sigue funcionando en todos los MSX.
Lo del scroll cada jugador tiene 4 capas que no lo he hecho por estética, si no por velocidad ya que así no tengo que pintar el scroll entero en cada iteración, si no que hay algunas iteraciones en las que no pinto algunas de las lineas del fondo y así es más rápido.
Yo creo que en el concurso deberían dejar usar el XBASIC y el acceso a disco para cargar gráficos porque no hace falta tener más conocimientos de programación y los juegos pueden quedar mucho mejor, por lo menos en cuanto a velocidad y cantidad de gráficos.
Lo que sale al principio del vídeo no es el compilador, si no el interprete de KonamiMan (NestorPreter) para poder programar sin tener que poner número de líneas y con variables de más de 2 carácteres, que luego el intérprete lo deja en un listado con lineas y variables de 1 o 2 carácteres.
Sería interesante saber si los obsequios de la edición anterior han sido enviados, por que aquí no se ha recibido nada.
Por otro lado, para aumentar hasta 64k la memoria accesible desde el basic teclear en modo directo:
POKE&HF6C2,0:POKE&HF6C3,0:POKE&HF674,&HFF:POKE&HF675,&HFF:DEFUSR=&H7D29:POKE VAL(USR(0)),0
Germán, los juegos han sido enviados hace unos días. La camiseta está en preparación y será enviada en las próximas semanas. Paciencia 😉
En cuanto a la modificación de las reglas, todos coincidís en permitir la carga de gráficos desde la unidad de disco. Y Kotai propone permitir también el uso de BASIC compilado.
A mí no me importaría modificar las reglas pero me molestaría mucho que los que piden los cambios luego no presentaran nada. Además, hay que tener en cuenta que puede haber gente trabajando en su proyecto con las reglas actuales y un cambio les perjudicaría.
En caso de hacer los cambios, estos tendrían que ser lo más pronto posible para no provocar trastornos innecesarios a los participantes.
¿Cómo lo véis?
Si se permite el uso de gráficos desde disco y el XBASIC para quien prefiera sacrificar memoria por velocidad yo si que presentaría uno de los dos juegos que quiero hacer: Trogloditas 2 para MSX1 o Panou para MSX2
KONAMITO, yo no te lo puedo asegurar por mi situación personal. Lo que sí es cierto es que lo que llevo hecho es con carga de gráficos con BLOAD, y con la rutina en ASM es 99% seguro que no lo haré. De todas formas si no estás convencido no las cambies, el año pasado se presentaron juegos y muy buenos además. (Siempre podría re-presentar Trepón, que quedó descalificado 🙂 Es broma…)
YMN, ¿Qué son esos POKES? ¿Direccionan más memoria para BASIC??? ¿En qué casos?
JAMQUE, ¡anda! en lugar de quejarte asociate conmigo y termina mi juego, que te paso los gráficos y todo!!! 🙂
Un saludo a todos.
Hombre Tomi, no era mi intención sacarle compromiso a nadie. Entiendo las limitaciones de tiempo que tenemos todos por diferentes motivos (trabajo, familia, aficiones, etc.). Solo faltaría que siendo esto un hobby nos lo tomáramos todo tan en serio como una obligación.
Más bien quería hacer constar mi probable descontento y enfado si después de introducir modificaciones en las reglas no se hace uso de ellas.
Un saludo y ánimo.
Es una curiosidad. Pero no esperes acceder a los 64k para realizar una aplicación.
Si no se puede volver a las originales, yo por lo menos lo dejaría como está.
Buenas noches.
Yo veo bien que se pueda utilizar disco y hacer BLOAD,S ya que, esencialmente, «hace lo mismo» que BLOAD más la rutina LDIRVM.
Cada versión tiene sus ventajas, claro. Por un lado BLOAD,S es más cómodo para trabajar (en especial para MSX2 que se maneja más volumen de VRAM). Y por otro, BLOAD+LDIRVM es, una vez cargado, más rápido (por ejemplo, para cargar diferentes pantallas).
Y luego están las ventajas implícitas: con BLOAD,S tienes acceso aleatorio a los recursos gráficos, y LDIRVM usado de manera habilidosa puede valerte para hacer tilesets animados o incluso un scroll (como demostró House II).
Que se por tener la rutina se pierda la esencia del BASIC… yo creo que no. Realmente lo que te quitas son los tiempos de espera de «cargando gráficos» y liberas RAM (los datos ya pokeados ocupan mucho menos que los DATA). Básicamente acabas teniendo un juego BASIC sin tiempos muertos.
¿La rutina echa para atrás a la gente? Espero que no sea así. La rutina no es obligatoria y por mi parte no tendría problema en ayudar a cualquiera a sustituir su cargador de gráfico o sus BLOAD,S iniciales.
Respecto al tema de XBASIC imagino que hay dos corrientes: los que preferimos el BASIC pelao, con sus limitaciones de velocidad, estrujar cada algoritmo y, a veces, sacrificar elementos del juego para que sea jugable. Y en la otra dirección los que tiran de XBASIC para sacar adelante ideas y juegos que de otra forma serían imposibles.
No vería mal que se permitiera, pero personalmente opino que la combinación XBASIC+DiskBasic+DSK2ROM es más de MSXDev que de concurso de BASIC (de hecho, ¿no es Imanok el que hace sus juegos en NestorBasic?).
Y ahora vamos al terreno personal 😉
@j4mk3: quiero ver Walking Kitchennn!!! que eso de sólo saber el título me tiene intrigadísimo 😀
YMN: yo he recibido hoy el aviso de correos. ¡Y explica eso de los 64K en BASIC! ¿Valdría para hacer BLOAD o POKE entre &H0000 e &H7FFF? ¿O también puede ir código?
Tomi: yo asociarme fitfy-fifty no, que bastantes ideas se me van a quedar en el tintero por falta de tiempo, pero si necesitas un empujón aquí ando. Prometo no robarte la idea ni los gráficos… excepto si son buenos, claro xDDD
Konamito: hombre, las reglas son de hace 10 días, y los cambios de los que hablamos no son más restrictivos. No creo que haya ningún problema
Un saludo a todos,
Nés.
Coincido en tu punto de vista en cuanto a que permitir carga de gráficos con BLOAD, S + BASIC compilado es demasiado y se aleja en mi opinión de la idea original del concurso.
Por ahora veo factible modificar las reglas y que cada participante haga uso de sus conocimientos para cargar los gráficos de los juegos.
¡Más opiniones, por favor!
Gracias por el ofrecimiento theNestruo! Si yo no quiero 50-50, con un 99-1 también me vale 😀 (vamos que me hagan el juego, y yo en plan project-manager, que es lo divertido… xDDD). A ver si un día de esto recupero lo que hice, lo medio ordeno y te lo envío, por si te apetece (aunque sea robarme algún gráfico!)
Saludos!
A lo largo de esta semana tomaré una decisión final con respecto a la modificación de las reglas del Concurso.
Konamito, antes de tomar la decisión final ten en cuenta que desde que preguntaste como vemos lo de cambiar las reglas, creo que solo han sido 3 personas las que han opinado.
En mi opinión hay que valorar si añadiendo estos «extras» se van a captar mas participantes, o al contrario habrán otros que no se presentaran pensando que ya no se compite en igualdad de condiciones (se puede correr en la formula uno con un seiscientos trucado, pero nadie lo hace ni lo valoraría)
Saludos
Yo sigo pensando que la rutina en ASM es un filtro de la «calidad» del participante. Si eso es lo que se pretende, entonces está bien.
Un saludo a todos.
Actualizadas las reglas del Concurso MSX-BASIC 2012. Se permite la carga de datos y gráficos desde disco pero su uso conlleva una gran responsabilidad: en caso de no hacerse adecuadamente se perderán los 5 puntos de bonificación extra que se le otorgan a cada juego.
¡Buena suerte!
Hola. ¿Están permitidos los juegos creados con un emulador de MSX?
Hola Francisco.
No importa cómo se desarrolle un juego mientras cumpla con las reglas publicadas. Puedes desarrollar el juego usando un emulador o la máquina real, o un PC, lo que te sea más cómodo.
Bien, en estos días he recibido el obsequio de la edición anterior. Una camiseta con una referencia a la aplicación que envié. Saludos