Como sabéis este año hay una nueva edición del concurso de MSX-BASIC. Por primera vez he abierto la confección de las reglas a todos vosotros que nos visitáis. De vuestras opiniones he podido sacar valiosas conclusiones que estoy seguro de que se plasmarán en una mejor organización de este nuevo concurso.
Ahora la duda está en decidir de qué manera se usará el MSX-BASIC para crear los juegos. Todos sabemos que el MSX-BASIC no destaca por su velocidad pero sin embargo es capaz de brindarnos grandes juegos. Habéis propuesto trabajar por primera vez con MSX-BASIC compilado, método que acelera y mucho la ejecución de los programas. Otros habéis mencionado el uso de rutinas de ensamblador, y otros (los más puristas) quieren mantener el MSX-BASIC intacto. Las diferencias entre unos métodos y otros hacen que las diferencias entre los juegos sean muy grandes. Si cada participante pudiera elegir el método que más le conviene provocaría sin duda es una desigualdad de condiciones difícil de equilibrar.
Así que es necesario que se elija un solo método de trabajo con el MSX-BASIC. Es vuestro turno para pronunciaros.
Podéis complementar vuestra elección con los comentarios que creáis convenientes.
En cuanto al resto de los aspectos del concurso (jurado, premios, plazos) os facilitaré más información cuando cerremos el capítulo de las reglas, que por su complejidad es el más difícil de completar.
Lo siento, no hay encuestas disponibles en este momento
Como ya dije en su día, mi voto va por BASIC+Ensamblador (cargado desde el propio listado BASIC), es una opción de la que siempre hemos dispuesto al trabajar en BASIC.
¿ En que sección quedaría el NestorBASIC con extensiones ? Por una parte es BASIC compilado porque usa el XBASIC pero por otra parte usa rutinas en ensamblador para sus extensiones aunque como usuario final lo único que haces es llamar a las funciones ya creadas, no crear nuevas rutinas en ensamblador.
Yo he votado por BASIC compilado, porque creo que es ahí donde entra NestorBASIC.
Me pones en un aprieto pero yo lo consideraría BASIC compilado…
Yo creo que si se permite meter ASM, tendría ventaja la gente que sabe ASM (aparte de que deja de ser programar en basic). Pero vamos, que es decisión de Konamito… lo que decida estará bien 🙂
Yo no he votado por la opción de BASIC+ASM no porque considere que es inapropiado o que va en contra de la idea original del concurso; es simplemente que no sé programar en ensamblador. Por lo tanto es un voto interesado, pensando en la propia participación, y no en el concurso. No sé si éste será también el caso de los demás…
Bien, las opciones que se presentan para flexibilizar el contest tienen las siguientes características:
MSX-BASIC puro. Es la opción inicial
MSX-BASIC compilado. Se entiende por «compilado» el uso de TurboBasic.
Hay que observar que esto implica:
– No todas las instrucciones basic están soportadas.
– Las aplicaciones no pueden exceder de los 10K.
– Si la unidad de disco está activa, la capacidad anterior es menor.
– Además de otras restricciones.
Por otro lado,
– Hay un aumento en la velocidad de proceso de las aplicaciones.
– Posibilita el uso de assembler embebido.
– Este assembler puede referenciar directamente a líneas basic.
MSX-BASIC + Ensamblador
El asunto de esta opción, es distinguir el código basic y el ensamblado.
Se puede implementar un programa basic:
– Que haga uso de algunas rutinas assembler que mejoren las prestaciones del programa.
– O que sea el soporte a un cargador de código máquina donde se encuentra la aplicación, y por lo tanto en este caso extremo, no es una aplicación basic.
Falta otra opción no publicada: MSX-BASIC compilado + Ensamblador
Esta opción es de interés porque permite superar las restricciones expuesta anteriormente.
De todas formas, el uso de compilado o ensamblador tiene como resultado un programa objeto, que ninguna relación tiene con el MSX-BASIC.
En este contexto, se debe establecer las limitaciones de ese programa objeto, ya sea compilado o assembler, con el objeto de que el resultado no se distancie de una aplicación basic.
Si se admite MSX BASIC+ASM, sin restricciones, al final es otra DEV encubierta 😀
Casi hubiera sido preferible, en mi opinión, MSX BASIC + 1 BLOAD»»,S
Si desde luego, como reza el slogan, es un concurso MSX-BASIC, debería mostrar los ingenios de su creador sobre el manejo de este lenguaje. El uso del Ensamblador aquí, no debería estar permitido, exceptuando las rutinas BIOS propias del sistema. Por ejemplo, al estilo de:
10 DEFUSR(0)=&H41: PRINT USR(0)
… que sin entrar en pormenores, desactiva la pantalla. Este tipo de cosas si que deberían ser aceptadas, pero no así rutinas en Ensamblador, da igual embebidas ó no, ya que eso sería programar en Ensamblador, y no mostaría el esfuerzo del programador por resolver este ó aquel problema desde la perspectiva BASIC, que creo que en definitiva, es de lo que se trata, a parte de que sea un programa majete.
Dicho está. Saludos.
Sea cual sea el resultado de la encuesta bien BASIC puro, compilado o con ASM, como han comentado anteriormente, lo de permitir el BLOAD»»,S para la carga de gráficos sería un gran avance.
UnAz, lo de cargar gráficos externos con BLOAD como comentas estará presente en las reglas, es una opción que la mayoría ha valorado como necesaria y positiva.
Ok, Konamito, muchas gracias por la aclaración.
Bien, la opción de permitir el uso de la instrucción bload para la carga de gráficos implica el uso de recursos externos. En este caso el disk Basic.
Por lo tanto, hay que hablar de MSX-BASIC + Disk Basic.
Este hecho, permite las siguientes prestaciones:
– Acelera la carga de los set gráficos redefinidos.
– Permite multitud de pantallas, con la limitación que tiene el sistema de gestión de archivos implementado en la romdisk, que se encuentra en algo más de 100 archivos.
– Esto supone, que se puede implementar un programa basic con algo más de 100 pantallas.
Por otro lado, este tipo de aplicaciones solo podrán procesarse en ordenadores que dispongan de unidad de disco, por lo que hay una restricción.
En este contexto, se debe definir el número de archivos gráficos a cargar.
Si el objetivo, es acelerar la carga de los gráficos en un solo archivo, no es adecuado usar disk Basic, ya que se puede realizar de otra forma sin perjudicar a los usuarios que no dispongan de unidad de discos.
En este caso, para permitir que el programa se pueda usar con o sin unidad de discos, se puede realizar de la siguiente forma:
– Permitir dos listados basic: gráficos y aplicación.
Esto no incumple la normativa, ya que expresa: «El juego puede estar compuesto por uno o varios listados.»
– Listado basic con los gráficos:
Debe cargar los gráficos en memoria ram + una rutina assembler de copia a vram, que no supera los 15 bytes, para posteriormente grabarlo en memoria externa.
– Listado basic con la aplicación: realizaría una llamada de carga del archivo anterior.
De esta forma, se acelera la carga de gráficos y es independiente del dispositivo de almacenamiento.
En otro orden de cosas, en las bases está redactado lo siguiente:
«Los juegos presentados tienen que ser originales.»
Este punto debe ser más definido, por que excluye, por ejemplo, las conversiones.
Se debe establecer si no se permiten «plagios ni copias de otros ya existentes en su totalidad o en parte (música, gráficos, rutinas, etc.).» en relación al sistema o a cualquier aplicación de cualquier sistema.
Tampoco es mala opción la de @YMN de usar una rutina ASM para la carga de gráficos en lugar de Bload. Pero en tal caso creo que la rutina debería ser la misma para todos e incluso estar incluida en las bases del concurso, así como el contenido del segundo listado BASIC (el de gráficos). Esto liberaría igualmente memoria RAM para su uso en BASIC, pero no aceleraría la carga de gráficos, ¿no?.
Referente a la originalidad del juego… por ejemplo esta pasada edición se ha presentado (y de hecho premiado) un Tetris, juego del que evidentemente no puede defenderse su originalidad. Creo que más que hablar de originalidad del juego debería prohibirse la copia de fragmentos de código de otros juegos (lo que no es fácil de demostrar, pero es un aviso obligado, como el de «prohibida la reproducción total o parcial…»). En mi opinión las versiones de otros juegos (y más sin son comerciales) deberían ser lícitas en un concurso de esta índole, y un jurado cualificado podrá detectar qué es versión y qué es copia.
—Tomi dice:
Esto liberaría igualmente memoria RAM para su uso en BASIC, pero no aceleraría la carga de gráficos, ¿no?.
—
Sería interesante tu mail.
Bien, la «aceleración» de la carga de gráficos se produce en el listado basic de la aplicación que realizaría una llamada de carga del archivo que produciese el listado basic de gráficos.
La velocidad de proceso del listado de gráficos y por lo tanto la primera carga de gráficos, es la misma que si los gráficos están en el mismo listado de la aplicación.
Por otro lado, no tiene restricción de recursos: en el caso del disk basic es necesario una unidad de discos y la romdisk, igual que para el uso de Turbo Basic es necesario la rom de xbasic o un archivo que implementa una simulación de esta rom.
De las prestacciones del disk basic comentadas anteriormente, también es posible implementar otras opciones.
Por ejemplo, es posible almacenar pantallas, más de 10, en un solo archivo de gráficos en disk basic, para después visualizarlas en pantalla de forma instantanea.
Por lo tanto, hay que hablar de MSX-BASIC + Disk Basic.