Este año habrá, de nuevo, concurso de juegos en Konamito.com. A la vista está que el MSX-BASIC a pesar de sus limitaciones es capaz de brindar grandes programas, y los juegos que se han presentado a lo largo de estos tres años de concurso son buen ejemplo de ello.
El año pasado por primera vez quedó un juego descalificado por no cumplir las reglas. Esto abrió un debate interesante sobre la idoneidad de las reglas del concurso que a mí personalmente me gustó. Es por ello por lo que decidí que para edición 2011 todos podrían dar su opinión y su punto de vista sobre las reglas del concurso.
A continuación os presento un borrador de las reglas sobre el que podéis dar vuestra opinión y parecer. No os cortéis, y participad. Prometo tener en cuenta todos vuestros comentarios ya que se trata de conformar unas reglas lo más homogéneas posible y que contenten a la mayoría. Eso sí, la redacción de las reglas definitivas estará supeditada a mi decisión personal.
- Puede participar cualquier persona que lo desee.
- Cada participante puede presentar tantos juegos como desee.
- Solamente se aceptarán aquellos programas que sean videojuegos, de cualquier género: aventura, plataformas, RPG, puzzle, arcade, etc.
- Los juegos tienen que estar programados completamente en MSX-BASIC, no estando permitido el uso de lenguaje ensamblador, MSX-BASIC compilado, etc.
- El juego puede estar compuesto por uno o varios listados.
- El código de cada juego presentado tiene que 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.
- 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 (nada de 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.
- Prohibidas las instrucciones relacionadas con el casete.
- Prohibidas las instrucciones relacionadas con la impresora.
- Prohibidas las instrucciones añadidas por alguna extensión al MSX-BASIC (como las de diskrom, cartuchos con ampliaciones, etc.).
- El listado MSX-BASIC puede tener el número de líneas que se desee, numerándose siempre de 10 en 10.
- El juego se entregará en formato .ROM o .DSK. y además se acompañará de los listados correspondientes en un archivo de texto.
- 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 a webmaster@konamito.com proporcionando los siguientes dato:
- Nombre del juego
- Nombre o nick del autor.
- Email de contacto.
- 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.
Hola,
Pues empiezo yo…
Antes de nada diré que solo es una idea, así que no os tiréis al cuello, es la misma idea que ya plantee en otro post.
BASIC COMPILADO O ASM!!!!
Pues eso que para dar un poquillo de vidilla a los juegos lo suyo seria dejar introducir un poco de ASM o dejar BasicCompilado, si no la mayoría de proyectos se arrastran y no se puede hacer algo medianamente en condiciones.
Si, ya se… ahora me diréis que si no se puede hacer en MSX-BASIC pues que no lo haga, pero es que eso se puede aplicar casi a cualquier juego(en msxbasic), el MSX-BASIC no es el medio mas idóneo para realizar juegos.
Yo propongo hacer dos categorias:
1. Basic tradicional
2. Basic compilado / ASM (max 4k por ejemplo)
En el caso que no os guste la idea del basic compilado al menos podríamos permitir la carga de archivos desde disco o cinta para mejorar los tiempos de ejecución de algunos juegos (CrazyCOCO tarda un minuto en cargar los graficos a VRAM) y liberar memoria al basic.
DISKBASIC SI por favor!!!!
Bueno, y ya puestos Konamito di una fecha ya!! xD quiero saber cuando empieza el «tinglao»
Os guste mi propuesta o no yo pienso participar como casi cada año (SpaceScape,CrazyCOCO y lo que venga) 🙂 así que venga exponed vuestras sugerencias rápido! cuanto antes cerremos el tema de las normas antes nos podremos poner a programar!
Saludos,
David
Yo también opino que es el momento de dar el salto y permitir algo de ASM desde dentro del basic.
Una posibilidad interesante que ya te comenté en su día es que el juego se presente en formato .CAS y que pueda ser una mezcla entre BASIC y ASM (con un límite de, digamos, el 30% máximo ASM). Los juegos deberían funcionar cargándose desde BASIC en cualquier MSX con, al menos, 32K de RAM (para así evitar tener que buscar la RAM oculta y saltarse el basic y bla bla bla).
Este año no estoy por la labor (en principio) de dividir juegos en categorías. Así que de haber juegos compilados y no irían todos en el mismo saco.
Y en cuanto al ASM, soy partidario de abrir la mano este año para mejorar los programas… SapphiRe, ¿cómo se puede medir la cantidad de ASM en un programa? Debería poderse medir de una manera rápida y sencilla de cara al jurado que tenga que analizar los juegos.
Se me ocurre una fórmula sencilla: bytes en ASM / bytes totales del programa.
¿Qué os parece?
Pues yo creo que lo suyo es dejar un limite maximo y listo.
Por que todos sabemos hinchar el basic 🙂 unas cuantas lineas inútiles en basic y ya disponemos de mas RAM para ASM jejejej
A muy malas podríamos añadir el basic en datas como ya se comento en otra entrada.
Si el concurso se llama MSX-BASIC yo creo que no se debería dejar usar ASM. Creo que mucha gente «sabe» programar en Basic pero muy pocos en ASM por lo que unos pocos tendrían ventaja.
Lo que si que habría que estudiar es lo del BASIC compilado. No tengo ni idea de como es, pero por el nombre supongo que la programación será 100% BASIC solo que el compilador hace una buena optimización para mejorar la velocidad del programa, que es el mayor problema que tenemos con el BASIC iterpretado. (que me corrija alguien si lo que he dicho no es correcto).
Yo como ya le comenté a Konamito lo que veo bien es poder tener 2 listados, uno que cargue todos los gráficos en la memoria de video y luego otro para el juego, así podemos hacer juegos un poco más grandes.
Yo este año si que me voy a presentar, arreglando los bugs de los juegos que hice en 1988 y 1989 me han cogido ganas de programar algo y como he recuperado el listado de los gráficos de un juego que estaba haciendo en el 89 pero no el del juego en si, he pensado volver a programarlo a ver si esta vez lo acabo y de paso me presento al concurso.
Por cierto, y perdón por salirme del tema, ¿ donde puedo conseguir información del BASIC compilado ? (Compilador, instrucciones basic, manual…)
Coincido con la opinión de KOTAI, y que también manifesté anteriormente en otra conversación. La idea original no es un concurso de juegos de MSX, sino de juegos de MSX-BASIC. Es indiscutible que la calidad de los juegos podría verse claramente mejorada con el uso de ensamblador (en cualquiera de sus posibilidades), pero esto podría acarrear una reducción, no sé si drástica, del número de entradas del concurso. Además, los juegos que no incluyesen ASM sufrirían cierta «competencia desleal», difícilmente salvable sin una distinción por categorías dentro del concurso.
Hola,
Pego aqui el manual del xbasic:
MSX-BASIC-KUN (BASIC COMPILER) alias XBASIC
by J.Suzuki 1989
this document & samples by Sho Endo
translate to english by LASP
this text file typed without changes by Nestor Soriano
some minor changes and helpfull examples added by NYYRIKKI
MSX-BASIC-KUN is an incredible BASIC compiler. It will compile a BASIC
program on memory in few seconds and execute it 15 to 100 times faster!! It
can compile most of the statements and functions of MSX-BASIC and can handle
strings and floating numbers. Once you see it, you’d feel you’d never need to
learn the Z-80 machine language. Real time games, C.G., demo programs can be
written by the ease of BASIC for machine language speed.
*** USAGE ***
1. Settings & General knowledge
This compiler was sold in Japan as a cartridge for 4500 yen. You just set it
in a slot to use it. This compiler ROM was also build in MSX2+ Sanyo machines.
If you don’t have Sanyo MSX2+ or original cartridge, you can load a cracked
version of it from disk by simply typing:
BLOAD»XBASIC.BIN»,R
Now you are in BASIC mode as usual, except that two commands are available:
CALL RUN
CALL TURBO ON/OFF
«CALL» can be written as «_» (underscore). I will use that from now on.
_RUN is the command to compile and execute the entire program on memory. If
it finds an error it will stop and yield the message.
_TURBO ON is the statement to define the beginning of the turbo block.
_TURBO OFF is the end of the block.
The turbo block is the part of the program you want to execute fast. When the
entire program contains some uncompilable statements, you can define the
block to be compiled using this set.
EXAMPLE
100 SCREEN 8:DEFINT A-Z
110 BLOAD»PICTURE»,S
120 _TURBO ON
130 FOR X=0 TO 255
140 LINE(X,0)-(X,211),0
150 NEXT X
160 _TURBO OFF
170 A$=INPUT$(1)
This program cannot be «_RUN», because the «BLOAD» is one of the commands
that cannot be compiled. If you «RUN» this, the part lines 130 through 150
will be executed fast.
As ‘_RUN»FILE»‘ is not supported, you have to add _TURBO ON and _TURBO OFF at
the beginning and the end if you want to RUN»FILE» and have the effect.
100 FOR I=0 TO 999
110 …
.
.
.
890 ‘END OF THE PROGRAM
So, this can be _RUN or add 10 _TURBO ON and 900 _TURBO OFF and RUN»FILE».
If you _RUN a program containing «_TURBO ON/OFF» it will be an error.
_TURBO ON/OFF can not be written in a multi-statement lines.
_TURBO ON/OFF can not be nested. But you may have many closed blocks in a
program.
Variables and arrays are handled differently in and outside of the blocks.
Once you are out of the block, variables and arrays used in the block are
lost. Only, the integer types can be defined as common.
100 DEFINT A-Z:DIM C(2),D(2)
110 A=1:B=2:C(0)=3:D(0)=4
120 _TURBO ON(A,C())
130 DIM D(2)
140 PRINT A,B,C(0),D(0)
150 A=5:B=6:C(0)=7:D(0)=8
160 _TURBO OFF
170 PRINT A,B,C(0),D(0)
RUN
1 0 3 0
5 2 7 4
Ok
Floating numbers used by the compiler is a special format 3-byte value. It’s
accuracy is about 4.5 digits. Double precision is not available.
An array must be declared by a constant in the beginning.
This compiler works on the BASIC program on the RAM and creates the objects
and variables on the left RAM. So there is a limit of the size of the source
program about 10K. Big arrays, string variables (each uses 256 byte), CLEAR
???,&H???? will make the situation tighter as you can imagine. The compiled
objects can not be saved as independent programs.
Interrupts available, such as KEY(1) ON, OFF etc. But it will decrease the
efficiency of the executed object’s size & speed.
Some statements may not work correctly.
100 GOTO 130
110 A=3/2
120 END
130 DEFINT A-Z
140 GOTO 110
If you RUN this, A is 1. If you _RUN this, A is 1.5. DEF??? will be effective
when encountered during the execution in the case of interpreter, while it
depends on the order of line number in the other case.
A little complicated string operation may cause easily a «String formula too
complex» error. As this compiler has only one level of stack for it. Break a
long string formula into multiple small ones, if so.
If you _RUN an endless program, you can not stop it normally. Make a part to
check keyboard.
100 GOTO 100 ‘Reset or power off to stop
100 IF INKEY$=»» THEN 100
110 END
is better.
To avoid running in to endless loop causing hang situation it is recommended to
enable MSX standard software reset. This can be done with following POKE
command:
POKE &HFBB0,1
Reset will be now done if you now press CTRL+SHIFT+GRAPH+CODE/Kana-lock at the
same time. If you hold this key combination down too long, this may cause
program to stop in wrong screenmode, so writing:
SCREEN0’
may be needed.
2. Difference from MSX-BASIC interpreter
List of statements, commands and functions that can not be compiled.
AUTO, BASE, BLOAD, BSAVE, CALL, CDBL, CINT, CLEAR, CLOAD, CLOAD?, CLOSE,
CONT, CSAVE, CSNG, CVD, CVI, CVS, DEFFN, DELETE, DRAW, DSKF, EOF, ERASE, ERL,
ERR, ERROR, EQV, FIELD, FILES, FPOS, FRE, GET, IMP, INPUT#, KEY LIST, LFILES,
LINEINPUT#, LIST, LLIST, LOAD, LOC, LOF, LPRINT USING, LSET, MAXFILES, MERGE,
MOTOR, MKD$, MKI$, MKS$, NAME, NEW, ON ERROR GOTO, ON INTERVAL GOSUB (due to
a bug, look inline examples), OPEN, PLAY, PRINT#, PRINT USING, PUT KANJI,
RENUM, RESUME, RSET, SAVE, SPC, TAB, TRON, TROFF, WIDTH.
List of those with limits.
CIRCLE: Start, end angles and aspect ratio can’t be specified.
COPY: Only graphic COPY is available.
DEFDBL: Same as DEFSNG.
DIM: Must come first in the program or in the turbo block.
INPUT: Can handle only one variable at the time.
KEY: ON KEY GOSUB, KEY(n) ON/OFF only.
LOCATE: x,y must be given in as a set. No cursor switch parameter.
NEXT: Variable names after the NEXT can not be omitted.
ON: ON STOP GOSUB, ON INTERVAL GOSUB not available.
PRINT: Commas work in a different way. No wrapping for digits.
PUT: PUT SPRITE only.
RUN: Variables won’t be initialized.
SCREEN: Screen mode and sprite size only.
SET: SET PAGE only.
STOP: Same as END.
USR: Parameter type must be integer only.
VARPTR: File number can not be given as the parameter.
Otherwise there is no significant difference.
In general, I/O commands & functions, and editing commands can not be
compiled. Of course they are available in the direct mode, and outside of the
turbo block. You can edit, debug and save a program in MSX-BASIC and execute
it by _RUN.
If you want to use PRINT# to write characters on GRP:, use it outside of
turbo block. Otherwise study the sample, «PRINT.TRB».
If you want to use PLAY, use BGM compiler, and get the sound by USR(n).
3. New features added
3 special commands are available by starting a remark line with some specific
characters.
#I
Stands for INLINE. You can write a short machine-language routine.
100 DEFINT A-Z
110 K=1
120 ‘#I &H2A,K
130 ‘#I &HF3,&HCD,@150,&HFB
140 END
150 ‘SUB
160 RETURN
120 means LD HL,(K); K must be a simple variable of integer type.
130 means DI
CALL @150 ;Be careful, this line won’t be RENUMed.
EI
#C
Stands for CLIP. In the screen modes 5 through 8 (except for PAINT, and
CIRCLE), this will be set clipping on and off.
10 SCREEN 8
20 ‘#C-
30 LINE(0,0)-(255,255) ‘Y CLIPPED
40 IF INKEY$=»» THEN 40
50 ‘#C+
60 LINE(0,0)-(255,255) ‘NOT CLIPPED
70 IF INKEY$=»» THEN 70
#N
Check if NEXT overflows.
10 FOR I%=0 TO &H7FFF
20 NEXT I%
This program will end up in a «Overflow error» in MSX-BASIC. And if _RUN, it
will be an endless loop. If #N+ is specififed, it will end normally. This
code will decrease the efficiency of the object, too. Better not use unless
it’s really necessary. To clear, specify #N-.
NOTE: In MSX-2+ Sanyo you can found a new command:
CALL BC
This command turn on the BASIC COMPILER option.
TOMI que te parece la opcion de basic compilado ?
ami me da lo mismo basic compilado que asm
salga lo que salga diskbasic por favor 😛
KOTAI pasame un mail a rubberkey arr0ba gmail.com y te paso el xbasic
Gracias, parece muy fácil, excepto el tema de las varibles que no entran dentro del bloque. He hecho pruebas con el NestorBasic pero me da errores en lineas tan tontas como ON a GOSUB x,y,z…
Mándame el XBASIC a kotai[arroba]remakesonline.com.
Visto lo visto con el BASIC compilado aún me reafirmo más en que si que deberíamos poder usarlo en el concurso ya que es basic 100% y supongo que lo único que habría que hacer es en la imagen DSK añadir el XBASIC.BIN y luego cargarlo en el autoexec.
Seguimos programando en MSX-BASIC pero los juegos supongo que irán un poco más rápidos porque mira que van lentos es BASIC interpretado. Mis juegos de los 80 los pongo con el emulador al 300% de velocidad para que sean medianamente jugables.
Hola CYBERNOID. La verdad es que no lo conozco. Me parece muy interesante, así echando un vistazo rápido al manual que has insertado. Si se trata sólo de compilar un listado de MSX-BASIC creo que no iría en contra de la idea original del concurso. Me gustaría hacer alguna prueba también, ¿me puedes enviar XBASIC a tbtjedi@hotmail.com? Supongo que la conversión de un listado no será inmediata, pero la creación desde cero de un juego debe dar prácticamente lo mismo…
BUF, ya he ajustado lo que llevo de juego para poder hacer un _RUN y menuda diferencia de velocidad, de tardar 6 segundo para que el muñeco vaya de una punta de la pantalla a la otra a hacerlo en menos de 2 segundos.
Y lo único que he hecho es cargar el .BIN con un BLOAD y luego en vez de hacer RUN haces _RUN, o sea que el programa sigue siendo BASIC pero va a una velocidad brutal. Creo que si que se debería permitir el BASIC compilado. La pega es que el juego ya solo funciona con MSX2 ¿verdad, o lo del MSX2 el solo el NestorBasic?
Solo he tenido una pega, ahora no puedo hacer CTRL+STOP para detener la ejecución del programa, una vez hago _RUN ya solo puedes salir reseteando el emulador.
Hola,
para el Ctrl+STOP lo suyo es programar el ON STOP GOSUB X
Aunque creo que es dificil programar un juego completo en modo turbo.
lo de pasar las variables es un poco rollo, pero bueno, es lo que hay 😛
TOMI compilar en turbo basic es tan facil como:
cargas el turbo basic: bload»xbasic.bin»,r
escribes codigo:
10 CALL TURBO ON
20 FOR N=0 TO 1000
30 PRINT «a»;
40 NEXT N
50 CALL TURBO OFF
60 REM RESTO DEL PROGRAMA SIN TURBO
70 REM AQUI PUEDES PONER MAS BLOQUES TURBO
las variables creadas fuera de bloques turbo no existen dentro de ellos, con lo que hay que pasarselas por parametro.
para pasar variables al bloque turbo puedes hacer
DEFINT X
X=10
CALL TURBO ON(X)
Perdonar que sea tan pesado, pero es que me he quedado alucinado de como va de rápido.
He hecho pruebas con un juego que estoy haciendo, poniendo el emulador BlueMSX al 999% con el juego sin compilar y luego el emulador al 100% con el juego compilado y va más rápido el juego compilado con el emulador al 100%. Supongo que esto dependerá del juego y de las instrucciones usadas, pero en mi caso es brutal.
Lo único que he tenido que hacer para que todo el juego se pueda compilar es cambiar dos PRINT USING por PRINT (el compilador no acepta el PRINT USING) y unos gosubs que tenía como ON NA GOSUB 1000,,,1050 les he tenido que pasar todas las direcciones: ON NA GOSUB 1000,1000,1000,1050.
Luego es tan fácil como al arrancar el MSX hacer el BLOAD del compilador y luego en vez de RUN hacer _RUN o bien en el programa añadir las sentencias _TURBO ON y _TURBO OFF
Konamito, queremos BASIC compilado, así los juegos son otro mundo, se pueden hacer «grandes» cosas, incluso añadir scroll al juego. Ahora programar para MSX es otra cosa, porque los juegos resultantes se podrán jugar y no como con BASIC interpretado que en vez de jugados son sufridos de lo lento que van.
Bueno, dejo ya el tema, que ya he sido demasiado pesado.
Cybernoid, si me pasas el programa lo cuelgo en una entrada específica junto con su manual y demás material, para que esté más accesible para un futuro uso.
Veo que optáis por BASIC compilado. Como solución intermedia no está mal. Entiendo que no saber ASM puede ser un hándicap a la hora de desarrollar un juego con respecto a los que sí tienen conocimientos de ensamblador…
Gracias por participar 😉 Más opiniones vendrán, seguro.
Bueno, ahora que sabemos lo del BASIC compilado ya no veo handicap, porque los juegos van igual (o casi) de rápido que en ASM y en BASIC prácticamente se puede hacer casi todo, pero si el concurso tiene como nombre MSX-BASIC, creo que lo suyo es programar en BASIC, aunque en el momento de ejecutar el juego lo hagas mediante el compilador.
Por cierto, yo no estoy usando el XBASIC.BIN estoy usando el NestorBasic de Konamiman, pero supongo que el XBASIC será igual, porque el de Konamiman está basado en el. Se puede descargar de http://www.konamiman.com
Hola,
Creo que entre los participantes había alguien que no era partidario del NestorBasic.
A mi personalmente me da igual uno que otro.
el XBasic funcina en MSX1 ¿el nestorbasic tambien?
Konamito, ya te he enviado el xbasic.
Buenas,
Mi opinion.
Me gustaria que se mantubiera el espiritu con el que se creó el concurso de MSX-BASIC: Recordar aquellos listados que tecleabamos o que enviabamos a las revistas.
Por lo que :
– No soy partidario de que el juego esté en varios listados.
– No deberia admitirse .DSK al concurso sino solo .BAS o .TXT
– Admitir .ROM como añadido para los que quieran jugar con emulador, lo quieran más facil para verlo, etc. Pero es una putada pq no te deja tener un listado superior a 16Ks.
– Soy partidario del ASM, siempre que se haga desde el BASIC.»quicir» que la rutina esté en DATAS, la subas a RAM y la ejecutes con tu DEFUSR.
– Los graficos no pueden estar fuera del listado basic, porque deja de ser un concurso de básic. La manera con la que lleves esos datos ahí ya es cosa tuya.
– No soy partidario del Basic compilado, porque si quiero cargar ese juego en un MSX real que no tenga disquetera….como le paso el .BIN ?
Se que mi opinión es algo sectaria.
Si quereis hacer juegos grandes o muy muy chulos, teneis la MSXDEV o sus juntais y haceis otro concurso. Tendriais mi participación tambien.
Considero que estas opiniones no hace más que marear a konamito con si «lo está haciendo bien o lo está haciendo mal».
En serio, no hay nada malo en crear más concursos .
Desearia que el concurso de MSXBASIC siga siendo de eso, de BASIC.
Saludetes a todos !
P.D: Tomi, te veo pronto en un ClubSprite 🙂
joer… Konamito arregla lo del CAPTCHA que he escrito un buen tocho y luego me he equivocado con el código CAPTCHA y lo he perdido todo. Vuelvo a escribir el mensaje.
He hecho pruebas con XBASIC y NBASIC y efectivamente, XBASIC funciona sobre MSX y NBASIC solo va a partir de MSX2, además el XBASIC son 16KB mientras que el de Nestor son 58KB.
Y he descubierto otra cosa, el BlueMSX si pones MSX2 o superior lleva incorporado el compilador porque puedes ejecutar (y funcionan) los comandos _RUN y _TURBO ON/OFF sin necesidad de cargar ni tener en la imagen de disco el NBASIC o XBASIC.
Respecto lo de no permitir el BASIC compilado por no poder cargar el .BIN desde cinta… yo no se mucho de esto, pero recuerdo que los juegos de cinta se podían cargar con BLOAD»CAS:»,R por lo que supongo que el .BIN si que se podrá grabar en una cinta para luego cargarlo antes de cargar el programa basic.
Saludos.
Yo me reafirmo con lo que dije en su dia. El concurso tal y como lo definio Konamito esta muy bien. Yo lo que mejoraria y publicaria, son los criterios de valoración, para que quedase claro de que el ganador sera el juego por su originalidad y por quien supo aprovechar mejor los recursos del Basic.
Todos estamos encabezonados de que un juego para ser bueno ha de entrar por la vista (yo padezco de ese mal 😛 ), pero tenemos que esforzarnos en dedicar más tiempo en la idea del juego y que esta se ajuste a las posibilidades del basic.
Creo que lo que podria ser interesante es hacer otro concurso donde cada año fueran cambiando las bases: acceso a disco (+ bload R), +asm, compilado, etc…
Saludos!!
Yo estoy de acuerdo con Aorante, el concurso debería seguir siendo como hasta ahora.
Si el basic es lento, es porque nosotros lo hacemos lento, ya que por ejemplo tiene una instrucción muy veloz como es PRINT, que si tecleas PRINT 5*8 te da el resultado instantaneamente 🙂
El problema es que lo queremos hacer todo tan complicado que preferimos poner Print (x*52+3)+(y*32+8)/(x-a+b*2)+(y-(a*b)/5) etc… para conseguir el mismo resultado.
Tambien me parece bien lo de publicar los criterios de valoración ya que a mi entender, lo principal es la originalidad y como te las apañes con el basic para conseguir lo que quieres de una forma aceptable.
Y aunque la solución seria tener un concurso con varias categorías, no hay suficientes juegos como para crearlas (en el actual solo un juego para MSX2) así que entiendo a Konamito con lo de crear solo una.
Hola JAMQUE!. Sí me gustaría ver «¡Guerra!» en ClubSprite (disculpa Konamito por este corte publicitario), pero tendría que arreglar antes lo del uso explícito del emulador. Eso un pedazo informático como tú se lo verá hecho, pero yo no sé ni por dónde empezar… También tendría que ponerle un final… a estas alturas… ufffff.
Volviendo al debate, en mi opinión la postura conservadora y proteccionista del MSX-BASIC es la más respetuosa con los origenes del concurso, su carácter diferenciador con otras convocatorias e incluso el concepto estricto de «retroinformática». Aunque me parece también muy buena la idea de usar XBasic (o similar), soy más partidario de la postura expresada por Jamque, Aorante, Azimut… Aun en esta opción, los expertos del ASM tienen una ventaja, pero lícita, de usar rutinas vía DATA’s.
Aunque se me tache de conservador proteccionista, creo que el concurso de BASIC debe mantenerse fiel a sus principios (que por alguna cosa es un concurso de BASIC). Efectivamente, eso limita en buena medida las posibilidades de los programas… pero para cosas «mas lucidas» en ASSEMBLER ya tenemos la MSXdev.
Un saludo.
No era mi intención tachar a nadie de nada, sólo he querido referirme a las posturas de defender el MSX-BASIC frente a las de usar otros BASIC’s o extensiones de éste. Disculpad no obstante.
Hasta el momento veo que hay tres posturas definidas:
* MSX-BASIC con carga de rutinas ASM.
* MSX-BASIC puro, tal y como lo conocimos en las revistas de la época.
* MSX-BASIC compilado.
De estas, la que menos me seduce es la última y la que más la primera. Finalmente para redactar las reglas optaré por el asesoramiento «profesional» para ser lo más preciso posible con la descripción de las limitaciones.
No olvidéis que MSXdev es un concurso con menos limitaciones y que permite hacer cosas más «profesionales». El reto aquí está en crear algo divertido y jugable con pocos medios.
Mi opinion es:
que el concurso distingua dos categorias:
1. MSX-BASIC, tal como esta
2. KUN-BASIC puro y con las mismas reglas que la categoria 1
Veo que al final tendré que dividir el concurso en categorías… Es lo más justo, sin duda.
Antes de hacer categorías y anunciarlo yo casi haría una encuesta para saber cuantos participantes habrían de esas categorías.
Es decir, al igual pones BASIC+ASM y se presenta solo 1…
por supuesto esa encuesta debería ser multiopcion, para el que quiera presentar un juego MSX-BASIC (pelao) y otro MSX-BASIC COMPILADO
Si al final hay varias categorias, habrá que definir cuales antes de la encuesta, ya que he estado pensando en lo del Basic compilado y no termino de verlo claro.
Si es lo mismo que el basic estandar, solo que mas rápido pero ademas hace falta un programa para poder correrlo en un msx real ya que no es estandar del sistema, es lo mismo que ejecutar el juego en un emulador y acelerarlo un 300% (por decir una cantidad.)
Asi que no veo la necesidad de crear una categoria para el basic compilado, ya que con el basic «normal» y un emulador consigues lo mismo.
No se si lo he expresado bien, pero si solo es eso, para mi el compilado sobra.
El Basic Compilado si que se debe poder poner en un MSX real, simplemente antes de lanzar tu programa o bien en la primera linea haces un BLOAD»XBASIC.BIN»,R y ya funcionan las instrucciones CALL TURBO ON/OFF.
Yo me he reeganchado al MSX gracias al compilador, era la ilusión que tenía de pequeño, un compilador (que sabía que existian pero no sabía donde) para acelerar mis juegos en Basic.
Además con el XBASIC puedes hacer una ROM que lo lleve incorporado, así que podemos entregar los juegos en un único fichero .ROM sin tener que cargar primero el compilador.
KOTAI, ¿las ROM’s se generan desde el propio XBASIC o con alguna aplicación externa? ¿están restringidas a 16K como con «MSX-BASIC ROM Creator»?
En caso de dos categorías (BASIC, y BASIC+ASM) creo que habría que eliminar las categorías MSX y MSX2.
Pero cuando haces ROM con XBASIC te queda poca memoria para programación en basic…
Lo suyo es que si se permite XBASIC se permita bload para evitarnos tener que meter los gráficos en el listado de basic.
Las roms las puedes crear con el mismo programa que se utilizo en la edición anterior (no recuerdo el nombre)
Kotai, a eso me refiero, que tienes que cargarlo externamente, con lo que ya no es del estandar.
No se si este programa tambien esta para cassette, ya que con BLOAD”XBASIC.BIN”,R se supone que tienes una disketera 🙂
¿Se nota que no soy muy partidario del Basic Compilado?
🙂 🙂 🙂
Bueno, yo no lo he probado pero para meter dentro de una ROM el XBASIC hay que hacer esto:
____________________________________________________________________
Even better…
– Convert your X-Basic program to ROM (ie. test.ROM)
– Type in Win DOS-prompt: COPY /B XBASIC.ROM+TEST.ROM READY.ROM
Now you have a ROM file (32K), that you can burn to cartridge with all X-BASIC speed & features.
____________________________________________________________________
Supongo que le pasas tu ROM de 16KB y el XBASIC que son otros 16KB te deja una ROM de 32K.
Si se permitiese el compilador yo no puedo meterlo en una ROM por lo que han dicho de poner los gráficos en un fichero BIN. Como redefinir los más de 160 caráteres ASCII, colorearlos y crear los 53 sprites es muy lento lo que he hecho es crear 2 programas, uno que solo hace los gráficos y cuando están todos generados hago una copia de la VRAM a disco con un BSAVE»graficos.bin»,0,65534,S y luego desde el juego lo primero que hago es el BLOAD»graficos.bin»,S para recuperar la VRAM con todos los gráficos hechos.
El problema es que aún no controlo mucho y lo que hago es grabar toda la VRAM quedando un fichero de 64KB para cuatro gráficos matados (o sea matar moscas a cañonazos) y luego no puedo hacer una ROM por culpa de este fichero de gráficos que es demasiado grande. La ventaja que tiene este método es que los gráficos cargan al instante sin estar 2 horas modificando los caracteres ASCII y además tengo toda la memoria libre para hacer el juego en Basic.
Por tanto mi voto es a Compilador SI, obligar a ROM NO, a no ser que alguien me diga como grabar solo la zona de la VRAM donde están los gráficos que he redefinido para que genere un fichero BIN pequeño y poder meterlo en el ROM-CREATOR y hacer una ROM de 16KB).
Si hay que votar yo tambien me apunto a basic compilado en disco (bload(
Me gustaría entrar un poco en el debate, en relación a un par de cosas que se se han comentado por aquí:
1)Creo que no se puede comparar el kun basic con un emulador acerelado, el primero hace uso de la máquina real y de todas sus caracteristicas.Y además fue un cartucho que se distribuyó en la etapa MSX y que incluso se incorporó en algunos MSX’s.
2)Tambien pienso que, hacer un concurso en el que se incluya el Kun-Basic no perjudica a nadie, simplemente el que no quiera participar en dicha categoría que no lo haga, y así los que nos apetece hacer algo en XBASIC tenemos la posibilidad de hacerlo.
En fin, creo que se debería votar, y yo opto por votar en las siguientes categorias:
1.- MSX-BASIC con un único listado al estilo revistas, en el que se pueda incluir código máquina a través de datas (igualito que en las revistas)
2.- MSX-BASIC con un único listado y archivo BLOAD ””,S para evitar las largas esperas de carga en los gráficos
3.- y Kun-BASIC (usando bien el cartucho original o cargando con bload”xbasic.bin”,r)con las mismas opciones que en 1.- y 2.-.
En fin ahí lo dejo.
Sería interesante antes de hacer una votación hacer un sondeo a ver que categorias le atraen más a la gente, y luego votar.
yo muy posiblemente me apuntaría a KunBasic, aun no tengo ningún proyecto pensado, pero seguro que algo se me ocurre, aunque también es posible que haga algo en MSX-BASIC pelao.
yo creo que lo suyo es la opción 2 y la 3, creo que ya ha llovido mucho desde la MSXClub y la MSXExtra, no hace falta anclarse a listados de revistas.
@cybernoid, aunque hayan miles de programas en basic, el concurso sigue siendo una actividad divertida. Se puede ver en el resultado del concurso de este año, aunque estoy de acuerdo en que crear una nueva categoría más flexible, estaría muy bien. 🙂
Yo también me apunto, y este año si, que el año pasado dije que me apuntaba pero al hacer pruebas y recordar la lentitud del BASIC lo dejé estar.
Ahora con el KunBasic es otra cosa y me apunto seguro.
Además voy a acabar un juego que empecé en el año 1989 (solo tengo los gráficos) y además lo voy a hacer en SCREEN4 que he estado todo el fin de semana haciendo pruebas hasta que lo he conseguido, así que este año podéis contar conmigo con un juego de MSX2 y compilado con KunBasic (si finalmente las normas lo permiten).
Yo voto por el formato del concurso actual sin tocar nada. Aparte, si se forman otras categorias, aunque a alguien le pueda dar esa impresión, no estoy en contra 🙂
@AORANTE yo no digo que no sea divertido, pero las normas me parecen un poco «chungas», es que no permitir hacer un triste bload(ni siquiera un load) es un poco chungo, como quieras aprovechar un poco el MSX2 te comes la memoria de basic intentando dar un poco de color.
Ademas ya he dicho que posiblemente termine con dos proyectos uno KunBasic y un MSXBASIC «pelao».
En mi opinión, la opción de BASIC + ASM vía Data’s. Aunque en mi caso difícilmente haría uso de este auxilio, creo que es un uso lícito del MSX-BASIC y no hay porque mermar las capacidades de programadores más «completos». La limitación de listado único, en mi opinión, ya es suficiente. Igualmente tampoco me opongo a la creación de otras categorías, sólo que no sé si habrá suficiente participación para todas.
Pues veo que no hay mucho consenso xDD
al igual lo suyo seria hacer 2 categorias:
1- MSX BASIC NORMAL (como ha sido hasta ahora)
2- BASIC A TU ROLLO (asm, xbasic,bload’s,cload’s y demás mandangas)
que os parece?
Mi opinión: La ya dicha pero la repito más corta.
Estoy con Tomi, Azimut y Xgipe:
Concurso BASIC, un listado, como hasta ahora.
Si caso DEFUSR y DATA para la chorradita ASM que quieras.
Participaria en eso por el reto y lo retro del asunto. Como quien quiere coser tal como era en al edad media una cortina.
No participaria en otra categoria diferente, dado que si lo que quiero es hacer un juego rapido y vistoso en MSX, está la MSXDEV, el ASM puro y la voluntad de hacerlo por mi cuenta sin tener detrás ningún concurso.
Hola! Hace tiempo que no me prodigo mucho por aquí (nada, la verdad :p), pero últimamente estoy tecleando algunas cosas en BASIC y me apetece dar mi opinión.
Prefiero el concurso tal y como hasta ahora. Quiero decir, que aunque se abra a más categorías, que permanezca la de basic puro y duro. Me parece mucho más divertido buscarle las cosquillas al basic con todas sus limitaciones y conseguir algo entretenido, que no empezar a meterle aditamentos y parches porque el lenguaje no da la talla para lo que se pretende. Yo por lo menos participaría en esa sección (si consigo acabar algo a tiempo, claro!, que tengo varias cosas a medias que tenía intención de haber presentado…)
Y ahora expongo una duda. Lo de la necesaria originalidad del juego, ¿a se refiere exactamente? ¿A copiar código de otro juego BASIC, al concepto del juego, de MSX o de cualquier sistema? ¿si presento algo basado en algún juego web de esos que andan por ahí, es válido? (si me dices que no me matas, juas ;D)
Un saludo.
Hola:
Bueno, yo también voy a poner mi opinión, aunque hace mucho tiempo que ando desconectado del tema, pero bueno, quiero dar mi humilde opinión, y es la de que haya una única categoría, y sea MSX-BASIC puro y duro, o como mucho, permitir ASM por ejemplo para el tema gráfico (y siempre presentando la fuente de este fichero, bien ASM o bien cargador de DATAS)
Y lo digo por lo siguiente: Yo participé en el concurso MSX-Basic con el límite de 10 líneas. Allí aprendí cosas como aprovechar las líneas al máximo y buscar alternativas como sustituir IFs por operaciones lógicas, etc. Es decir, se agudiza el ingenio para darle máximo rendimiento a las creaciones.
Siempre se le puede dar una vuelta de tuerca al código para que vaya mejor, y eso es uno de los atractivos de la programación (o por lo menos para mi), tienes un lenguaje y un sistema que da lo que da y poder exprimirlo al máximo de las posibilidades del programador, e incluso descubrir cosas que quizás pasabas por alto y que te pueden ayudar a que, en este caso el juego, vaya mejor.
Con un Basic compilado, puedes descuidar el optimizar tu código porque con el Basic compilado quizás apenas lo notes y, en consecuencia, pierde un poco el encanto.
En cuanto al ASM, creo que si se permite debería estar limitado su uso, como ya he dicho, por ejemplo para el tema gráfico, creo que es algo que sin mucho conocimiento del tema, sería fácil para aquellos que no sepan ensamblador.
Bueno, en resumen, creo que en MSX-BASIC puro y duro, tiene su encanto y tiene su reto añadido, pero bueno, esto es para gustos.
Un saludo a todos
Konamito ¿ que fechas tienes pensadas para el concurso ?
¿ Cuando estarán las reglas ? No es por dar prisa, pero como me estoy desoxidando del MSX-BASIC me gustaría ir haciendo cosas que luego me vayan a servir para el concurso.
Saludos.
Pues la fecha que tengo en mente para comenzar esta nueva edición es a primeros de marzo, para que podamos durante febrero llegar a redactar las reglas definitivas. Para ello se hace necesario abrir una encuesta, que lo haré en estos próximos días.
No os preocupéis que os mantendré informado de todo.
Yo en cuanto a no programador y bocazas, solo resaltaría dos temas problemáticos en el concurso BASIC de este año:
– EL tema de la descalificación.
– Los juegos (ha habido varios) lentos.
Tal como estan los baremos de puntuación ahora, lo cierto es que se podrían aplicar a cualquier juego para cualquier equipo y lenguaje, a ese nivel el tema de la objetividad esta asegurado, mas allá de la pericia que tenga cada uno. Yo mantendría el tema basic puro, con un pero, si son juegos que por complejidad, torpeza del programador o cualquier razón, tienen problemas de rendimiento serios, haya margen para buscar maneras de acelerar y mejorar la experiencia.
La jugabilidad, gráficos, diversión, etc. será la misma, porque al fin y al cabo son cosas que vienen del concepto y las ideas originales, y no creo que usar bload haga mejor un juego conversacional o un puzzle de toda la vida.
Quizas se podría establecer una etiqueta «ASM Free» 😀 o algo así para los que aprecian el trabajo de programación basic que hay detrás. Seguramente habrá gente que se picará por lograr mejores resultados que otros juegos con «mejoras» y además se podría recalcar que son juegos de código basic (tecleables, ya sabeis ^_^)
Pero vamos, todo esto sin dejarnos llevar por pasiones paternales y entendiendo que las cosas no rulan a veces como nos gustaria. El reconocimiento de toda la comunidad MSX ya lo tienen los participantes, hagan lo que hagan…
Si me permitís dar mi opinión respecto a lo que se ha de permitir o no, todo dependerá únicamente del objetivo del concurso:
-Si el objetivo es a ver quien consigue hacer el juego más divertido posible con las limitaciones del basic, pues nada… basic pelao para todo y punto. Sería un poco como el reto del juego en 10 líneas, que como reto programativo es fantástico, pero el resultado no quedó divertido (lo diversión, en todo caso, la obtiene únicamente el programador durante el proceso de creación).
-Si el objetivo, en cambio, es demostrar que sin necesidad de ASM y sólo programando en basic se puede conseguir hacer juegos divertidos, rápidos y jugables, yo optaría por tirar de toda la artillería: carga de gráficos con bload y uso de basic compilado.
Como ya os dije, no estoy por la labor de crear más de una categoría en el concurso. Este año hemos tenido MSX1 y MSX2 y a esta segunda solamente se apuntó un juego…
Sobre qué se pretende al crear un juego en MSX-BASIC estoy más con la opinión de crear un juego divertido, jugable y vistoso.
En primer lugar, aunque mi opinión se haya volcado hacia el MSX-BASIC puro y duro, el resto de opciones me parecen tan buenas como las otras.
Sin embargo, si no va a haber categorías, creo que habría que reflexionar en lo siguiente: y es que va a haber gente con distintos niveles en cuanto a conocimientos. Si se deja abierta la puerta al ASM, Basic compilado, etc. no todo el mundo va a participar en igualdad de condiciones.
Una buena opción comentada por varias personas, es la de los gráficos con bload y basic compilado es una opción a tener en cuenta. Si ayuda a que los juegos sean lo más jugables posibles y rápidos, es la mejor opción para todos, incluso para los que tenemos menos nivel. Al final, viendo la documentación del basic compilado , y la carga de gráficos con bload, que no sé muy bien cómo va, pero creo que no tiene mucho misterio ¿o si?
En cualquier caso, lo que se incluya o no se incluya en las reglas, lo que sí que creo que debería ser es un concurso con la mayor igualdad de condiciones posible para todos los participantes.
Misterio ninguno, si sabes programar en BASIC también sabes en BASIC compilado. Los pasos a seguir:
1) hacer un BLOAD»XBASIC.BIN»,R que puede estar en la primera línea de tu programa o en el AUTOEXEC.BAS ya que una vez cargado ya no lo pierdes por más programas que cargues.
2) cuando quieras acelerar el código haces CALL TURBO ON y cuando quieras volver al modo normal haces CALL TURBO OFF. Lo de los bloques es porque hay instrucciones de BASIC que no se pueden compilar como LOAD,CLOAD,BLOAD,SCREEN,ON INTERVAL…. cuando vayas a poner una instrucción de esas haces un OFF y luego un ON
Y ya tienes tu juego funcionando de 20 a 100 veces más rápido.
Y lo de los gráficos con BLOAD también es muy fácil:
1) haces un programa BASIC que genere todos los SPRITES y redefines los caracteres ASCII. Como esta información se guarda en la VRAM lo que hacemos es un fichero con su contenido, para ello una vez ejecutado tu programa haces BSAVE»graficos.bin»,0,16383,S donde los 2 primeros parámetros indican la zona de VRAM a copiar (en el ejemplo la primera página) y la «S» indica que se ha de copiar de la VRAM y no de la RAM
2) haces otro programa con el juego, inicializas la pantalla como la tenias en el programa que hace los gráficos (KEY OFF : SCREEN 1 : WIDTH 32…) y haces un BLOAD»graficos.bin»,S y ya tienes todos los gráficos redefinidos y SPRITES sin tener que esperar un rato a que se generen. Para probar y depurar el juego esta solución está muy bien porque te ahorras el tiempo de generación de gráficos que es muy lento.
Como ves es muy muy fácil y sigue siendo BASIC 100%, no hemos añadido nada raro ni hay ventaja de conocimientos sobre la gente que usa BASIC puro.
PD ¿ se nota mucho que quiero que en el concurso se permita BASIC compilado ?
Tras el debate suscitado por los resultados del concurso de este año, cambio de postura respecto a este tema y coincido con @Kotai: basic compilado (y bload «»,S por descontado). Lo contrario penalizará cualquier proyecto mínimamente ambicioso o complejo, ya que la lentitud del MSX-BASIC sólo se puede combatir con simplicidad (entiéndase en el aspecto gráfico, de programación de la lógica de movimientos, de IA básica, etc.). Gracias Kotai por tu insistencia, ¡he visto la luz! 🙂
Un saludo.
si es que al final todos venís a las mías jejejejeje
por cierto, si se acepta Basic compilado, espero que también se acepte ASM inline (en datas o con la directiva del xbasic)
@cybernoid @kotai
Todavía no había hecho ninguna prueba «exigente» con Xbasic, acabo de hacer una: ¡impresionante! Sería una verdadera lástima no aprovechar esta herramienta. Me falta hacer alguna prueba sobre máquina real para terminar de creérmelo.
@TOMI 🙂 ya sabia yo que te iba a gustar.
ya sabéis que si os hace falta ayuda tenéis mi mail para lo que queráis.
No todo es bueno, tiene una gran pega la MEMORIA.
En BASIC tenemos 28KB para el código fuente y las variables pero al hacer el BLOAD»XBASIC.BIN»,R ese tamaño queda reducido a 12KB y eso no es todo, en BASIC las varibles de tipo STRING por defecto ocupan 200 Bytes a no ser que con CLEAR cambiemos el tamaño por ejemplo a 30 Bytes (CLEAR 30) pero en KunBASIC esto es ignorado y TODAS las variables de tipo STRING ocupan SIEMPRE 256 Bytes.
En el juego que estoy haciendo he usado 22 variables de tipo STRING (2 normales y un vector de 20 dimensiones para pintar la pantalla) pues eso supone 22×256 = 5,5KB por lo que solo me quedan 6,5KB para todo el código fuente y el resto de variables, así que hay que ingeniárselas muy muy bien para usar el mínimo número de lineas y varibles, o bien como estoy haciendo yo usar la VRAM para guardar valores en vez de hacerlo en variables.
Gracias Kotai, yo también he visto la luz XD. Con tus explicaciones. Es una buena opción.
Saludos a todos
Uffff, a mí eso de los 12Kb me ha dolido… Era demasiado bonito para ser verdad 🙁
Entonces las opciones de la encuesta serían:
* MSX-BASIC compilado
* MSX-BASIC «pelado»
* MSX-BASIC + Uso del lenguaje de ensamblador
Cargar gráficos desde un archivo externo lo veo interesante.
Decidme algo por si se os ocurre alguna opción más, y si no este fin de semana abrimos la encuesta durante 10 días.
Las opciones están bien, el problema del BASIC compilado con XBASIC es la memoria que solo son 12KB, así que yo me he pasado al NestorBASIC que solo consume 500Bytes del BASIC ya que el compilador lo mete en otro segmento de memoria y además permite guardar datos en otras zonas de memoria no reservadas para el programa BASIC, incluso en la VRAM pero tiene un problema, solo funciona en MSX2 o superior mientras que XBASIC funcian con MSX1.
Si te metes con NestorBASIC y empizas a almacenar los datos en otras zonas de memoria ya no se puede considerar BASIC «puro» porque ya empiezas a usar funciones USR() definidas en ensamblador, así que si no lo añades al concurso lo entenderé, pero yo lo voy a usar para mi juego porque si no con 6,5KB no me da para mucho. Además ya que solo funciona en MSX2 al compilarlo con NBASIC he aprovechado para pasar el juego de SCREEN1 a SCREEN4 y así poder poner los 8 sprites por línea o cambiar la paleta de colores.
@Kotai, ¿un cursillo rápido de NestorBasic como el que nos diste para Xbasic? 🙂 ¿Por qué hay que usar funciones USR()?
Gracias!
El NestorBASIC funciona igual que XBASIC (de hecho lo lleva incorporado) pero en vez de hacer BLOAD»XBASIC.BIN»,R has de hacer BLOAD»NBASIC.BIN»,R y luego lo del CALL TURBO ON/OFF es igual.
En la página de Nestor: http://www.konamiman.com puedes bajartelo junto con los manuales en castellano y las extensiones.
La diferencia entre XBASIC y NBASIC es que el segundo permite cosas como el uso de toda la memoria mapeada disponible para almacenar datos o rutinas en código máquina, acceso a todas las funciones de disco, o reproducción de músicas MoonBlaster y efectos de sonido PSG desde el BASIC o el Turbo-BASIC. Y la gran pega es que solo funciona sobre MSX2.
Yo estoy empezando a usar la extensión «NestorCadenas» para poner todas las fases y textos del juego en un fichero TXT y cargarlas en un segmento de RAM que no sea el del BASIC, así ahorro mucho espacio en el codigo fuente.
@Kotai
Dais miedo… 😉 ¡Gracias!
Yo he empezado a «esbozar» un poco lo que quiero hacer. He hecho pruebas con la carga de gráficos por Bload y la verdad que la cosa gana mucho. Konamito, si que es un tema interesante a tener en cuenta y, con lo que ha explicado @Kotai, la verdad que es supersencillo.
De momento, la idea que tengo es hacer el juego para MSX-1 y en un principio desarrollaré en MSX-BASIC puro y duro. Si se decide lo del Basic compilado, está bien saber ya de antemano lo de las limitaciones de memoria. Gracias @Kotai por tus aportes y tus explicaciones.
Un saludo a todos
@Kotai, @Cybernoid
Me está ocurriendo con Xbasic que en cuanto compilas tres o cuatro veces empieza a generar líneas de código basura que además no se pueden eliminar. No queda más opción que reiniciar, y aun grabando el código, al cargarlo de nuevo sigue «contaminado». Es muy difícil trabajar así…
A mi eso no me ha pasado nunca y llevo 2 o 3 semanas utilizándolo. De todas formas el XBASIC lo he usado muy pocop, casi siempre lo hago con el NBASIC.
Pues a mi tampoco me ha pasado eso nunca 😛
A ver si es que tienes tanto código basic que se monta sobre la zona de memoria del XBASIC.
Prueba con NBASIC a ver que tal, aunque no tendría porque funcionar mejor
No sé qué pasa entonces. Se trata de un código nuevo, todavía muy breve. Quizás haya tocado alguna dirección de memoria que no debo. Pero el problema sólo me ocurre al intentar compilar.
Empezaré de nuevo… ¡gracias!
Referente al concurso quizás estaría bien plantear sólo dos categorías (o dos opciones de encuesta): una de MSX-BASIC «puro» (sólo MSX-BASIC, un único listado, sólo para MSX de 1ª generación, sin accesos a disco, etc.) y otra de MSX-BASIC «libre» (MSX 1 o 2, bload’s, ASM en data’s, compilado si se quiere, multilistado, etc.).
Un saludo!