Karoshi MSX Community

Hola a todos.

Hasta ahora hacía los juegos en screen1 pero me gustaría hacer algo en MSX2 y he pensado en Screen 5
 
El tema de los sprites lo tengo claro, pero no se como va el tema de los caráteres redefinidos. En screen 1 para pintar un carácter en pantalla hago:
VPOKE 6145+X+Y*32,caracter ascii
En screen 5 supongo que la dirección es otra y no 6145 ya que me sale todo negro usando la dirección 6145
 
Creo que lo que también estará mal es a la hora de redefinir un caracter, en screen 1 yo hago
VPOKE caracter ascii*8, valor de la linea
y para pintar ese caracter
VPOKE &H2000 + caracter ascii*8, valor color de linea
¿ en screen 5 es igual pero cambiado la dirección ? ¿ que dirección ?

Otra cosa que me va por la cabeza es la forma de trabajar con un screen > 1. Yo ahora tengo el juego en 2 ficheros, el primero me pone screen1 y carga todos los sprites y redefine los carácteres ASCII por mis gráficos y luego cargo el segundo fichero donde está el código del juego, así cada vez que lo ejecuto no se tira un rato cargando los sprites y vpokes.
Si hago un SCREEN pierdo todos los sprites y vpokes que había redefinido así que como SCREEN 5 (o cualquier otro >1) no es de texto para programar he de estar en SCREEN 0 o 1 y al ejecutar el programa cambiar al nuevo SCREEN con lo que perderé todos los gráficos y cada vez que haga RUN tendré que volver a generarlos todos ¿ hay alguna forma de evitar esto ?

Gracias

SC5 y superiores no son modos por patrones, sino modos bitmap. No puedes hacer lo mismo que en SC1, SC2 y SC4, aquí para pintar un bloque de 8x8, la única forma es hacer 32 VPOKES en las direcciones adecuadas... o utilizar las funciones del VDP para transferencias de VRAM a VRAM, claro está.

SCREEN 5 es un modo bitmap, es decir, no tiene caracteres redefinidos. Por lo tanto, lo que haces es pintar directamente píxels sobre el lienzo de la VRAM. Con cada VPOKE lo que haces en realidad es cambiar el color de dos píxels, ya que en SCREEN 5 tienes una paleta de 16 colores. Por lo tanto, hazte a la idea de que un VPOKE es igual a dos PSET y no andarás mal encaminado...

Realmente lo que quiero del MSX2 son los 8 sprites por linea y poder poner un color diferente en cada linea del sprite. Si eso se puede hacer en screen 4 también me sirve.

Quiero convertir el juego a MSX2, pero no quiero perder los más de 160 carácteres ASCII que he redefinido para los gráficos. ¿ Es posible hacerlo en algún modo de MSX2 ?
Y en caso de poderse, cuales son las direcciones que he de poner para definir los caráteres y sus colores (que supongo que la dirección depende del screen) y luego como lo pongo en pantalla. Lo imporante es poder reutilizar todos los DATA con los gráficos y colores.

También para el menú poner por ejemplo "KOTAI 2010" si hay algo tipo print que le pase la cadena y la pinte con mis letras redefinidas o es preciso poner un vpoke por cada letra.
Y para terminar si hay alguna instrucción que me diga si tienes un MSX1 o superior para cuando cargue el juego comprobar si estoy en un MSX1 o 2 para que no de un error al hacer SCREEN 4 si se trata de un MSX1, poder sacar un mensaje tipo "este juego solo funciona en MSX2"

Saludos y gracias

Pues si lo que quieres son los 8 sprites en línea y reaprovechar los caracteres que ya tienes, lo suyo sería hacerlo en SCREEN 4. La única diferencia con SCREEN 2 es el modo de los sprites, que aguanta hasta 8 por línea horizontal y multicolores, y que puedes forzar que la pantalla sea de 256x212 en lugar de 256x192. Por supuesto, también puedes jugar con la paleta, pero eso - de hecho - lo puedes hacer en cualquier modo de pantalla si estás en un MSX2/2+/tR.

En SCREEN 4 te diría que no se mueven las direcciones de memoria de caracteres, colores y patrones, pero mejor si lo buscas en el MSX2 TECHNICAL DATABOOK o como se llame, que tienes disponible para su descarga en la página de Konamiman, alias Néstor Soriano. O puedes tratar de usar la instrucción BASE(n) de BASIC para obtenerlas a pelo...

Supongo que en SCREEN 4 sí que puedes hacer algo parecido al OPEN"GRP:"AS#1 y después el típico PRINT #1, pero no te servirá si vas a estar modificando la tabla de nombres. Mejor los VPOKES que dices y así puedes hacerlo con los caracteres que hayas redefinido y no con los feotes de la BIOS.

Y en cuanto a saber si estás en un MSX1/2/2+/tR, te basta con leer una posición de la BIOS. Tienes la dirección concreta y su interpretación en los hilos de arriba del foro de desarrollo, que se llaman algo así como "Desarrollo compatible para MSX".

Con esto deberías tener suficiente para ir tirando. Google es tu amigo ;)

Sí, sin ningún problema.


Screen 4 desde BASIC.


Si lo diseñas para Screen 2 puedes usarlos EXACTAMENTE IGUAL en Screen 4. La única diferencia entre ambos modos es (y no me cansaré de repetirlo) que en SC4 puedes usar los sprites modo 2 (8 por línea y multicolor).

Pero en cuestión de caracteres tienes las tres tablas de patrones en 0, 2048 y 4096; las tres tablas de colores en 8192, 10240 y 12288. No tienes una única tabla como en SC1, pero se puede hacer sin problemas con un par de VPOKES y funciona bien en todos los MSX2.


Creo que engañando al BASIC se puede hacer, si mal no recuerdo JLTur publicó algunas cosillas al respecto.


MV=PEEK(43)

y en MV tendrás un 0 si es MSX1, 1 si es MSX2, 2 si es MSX2+ y 3 si es Turbo-R.

Espero que te sirva :D

Hola de nuevo

Antes de contestar he estado haciendo pruebas y me pasan cosas "raras".
Yo los juegos los hago SC1 pero redefino los colores de tinta y fondo de cada línea de los carácteres ASCII  y me he dado cuenta que al hacer esto, aunque sigo en SC1 el BlueMSX me dice que estoy en SC2. La verdad es que no se muy bien como lo hago, yo simplemente lo copié de un sitio y lo que hago es poner el rango de carácteres ASCII que quiero cambiar y por supuesto las DATA con los graficos y colores


La prueba que he hecho es dibujar un cuadro de 8x8 carácteres en la esquina de arriba a la izquierda:


Y con los cursores mover un sprite por la pantalla. En SC1 va perfecto:

(http://www.remakesonline.com/images/foros/SC1.png)

Pero he cambiado a SC2 y además del cuadro de 8x8 carácteres y el sprite que sale perfecto me aparecen 3 líneas que yo no he escrito:

(http://www.remakesonline.com/images/foros/SC2.png)

Y si pongo SC4 también salen las 3 lineas pero ahora no aparece el sprite por ningún sitio por más que mueva los cursores:

(http://www.remakesonline.com/images/foros/SC4.png)


Hace tiempo que ya intenté hacer esto ya vi que el SC2 tiene 3 tablas y no supe como solucionarlo, Pero por lo que dices parece que se puede arreglar y dejar en una sola tabla:

¿ Como se podría hacer eso ?

Del sprite no he tocado nada como por ejemplo asignarle los colores por línea , ¿ puede ser por eso que no aparezca en pantalla, o hay que hacer algo distinto a SC1 y SC2 ?


Gracias por la instrucción para comprobar el tipo de MSX y buscaré "JLTur" a ver si puedo hacer más fácil lo de poner las letras del menu, puntos, vidas... y no tener que hacer un VPOKE para cada letra.

Saludos

A ver, si no tocas nada más prueba con

VDP(3)=&H9F:VDP(4)=0

eso sí, en SC4 :D

Cuando tenga más tiempo ya te doy unas instrucciones más genéricas, que ahora voy de cráneo...

He probado esas instruciones (que no tengo ni idea de para que son) pero todo sigue igual en los 3 tipos de SC. Lo he puesto antes de redefinir y pintar los carácteres y lugo lo he probado despúes, pero en los dos casos pasa lo mismo, nada.

Saludos.

Bueno, y la otra gran pregunta:


Esto es importante para mi porque el primer fichero en el que hago los gráficos ya tiene 4960 lineas (de 10 en 10) y como uso el compilador XBASIC apenas tengo memoria para el código fuente por lo que si o si lo tengo que hacer en 2 ficheros y si al cambiar de SCREEN se pierden los gráficos no lo voy a poder hacer y me tendré que quedar en SC1 con las limitaciones del MSX1

Saludos.

Una vez tengas todos los datos en VRAM grábalos en disco con BSAVE con la opción ,S. Este parámetro especifica que sea de la VRAM. Luego lo cargas con un BLOAD "loquesea",S. Es más limpio y más rápido.

Muchas gracias, este parece el mejor y más rápido método pero tengo un problema.
He mirado las instrucciones y he visto que es BSAVE <filename>, <start address>, <end address>, S

Como no tengo ni idea de las direcciones las he puesto todas:
BSAVE"VRAM.BIN",0,&HFFFE,S

y efectivamente me ha guardado todos los sprites y los carácteres ASCII modificados, incluso sale en pantalla lo que tenía en el momento de grabar, pero he perdido todos los colores.
Aunque esté (de momento) en SC1 creo que es un caso especial porque pongo 2 colores por linea a los carácteres ASCII que creo que eso solo se puede en SC2, no en el SC1. De hecho el BlueMSX en el momento que cambio el color de los carácteres me dice que estoy en SC2, aunque sigo en SC1 con el modo texto (pero sin cursor en los 2 tercios de abajo de la pantalla)

¿ Como podría recuperar los colores ?

Y las otras preguntas pendientes:

¿ Como hago que se vean los sprites en SC4 ?
¿ Como evito las lineas que salen al redefinir los carácteres en SC2 y SC4 ?
¿ Como se hace para solo modificar un patrón y no tres en SC2 y SC4 ? (creo que es lo que llamáis modo-mixto por lo que he estado leyendo en el foro)

Muchas gracias.  ;)

Y digo yo... si el juego que estás haciendo es de pantalla fija y no cambian muchos elementos del escenario, quizás no sería mala idea pasar el escenario a SR5 (sin restricciones de colores por línea y puedes cargarlos con un BLOAD" ",S) y los cambios de elementos 'no sprites' los haces con un simple copy??

Igual lo que te digo no sirve, porque no sé qué tipo de juego estas haciendo, claro.

umm  ¿ Lo que me dices es pintar cada una de las pantallas, grabarlas con un BSAVE y tener todas en ficheros separados para cargar cada vez con BLOAD ?
No pinta mal, solo que el cambio entre pantalla ha de ser rápido porque se cambiará muchas veces de pantalla y mi intención es hacer unas 100 fases, un mapa de 10x10

El juego está visto desde arriba y la historia a groso modo es que eres un "loco" y tienes un tiempo limitado para escaparte del manicomio y para ello tendrás que encontrar algunos objetos y usarlos correctamente cuando toque. Tendrás que dar varias vueltas por todo el mapeado por lo que el movimiento del jugador ha de ser rápido para que no aburra y por lo tanto se cambiará de pantalla muchas veces:

(http://www.remakesonline.com/images/foros/panou_0000.png)

(http://www.remakesonline.com/images/foros/panou_0001.png)

(http://www.remakesonline.com/images/foros/panou_0002.png)

Para dibujar las pantallas sin ocupar demasiada memoria me hecho unas "funciones" que pintan cada uno de los objetos: pared blanca, pared gris, suelo1, suelo2, sillas, mesa, cuadro, planta, camilla, armario1, esquina-izq-sup...
Y pintar una pantalla es tan fácil como indicar la X,Y num de columnas y num de lineas y saltar a la linea donde está la función de pintado de ese objeto
10 rem *** pantalla 1 ***
20 x=0 : y=3 : c=1 : l=20 : gosub xxxx : rem pared de la izquierda
30 x=1 : y=4 : c=22 : l=1 : gosub xxxy : rem pared superior
....
40 return

Solo pinto las zonas que cambian respecto a las 4 pantallas desde las que se puede llegar a esa (las de arriba,abajo,izquieda,derecha) así es más rápido el cambio de pantalla.

Saludos.

No, no... a ver si me explico mejor.

Como ya te han dicho por aquí, el SR5 es un modo bitmap, de modo que imagino que la forma de trabajar a nivel gráfico será un poco más tipo a como se hace en plataformas más modernas (pero sólo hay una única capa gráfica + la capa de sprites).

En SR5 tienes 4 páginas disponibles (3 ocultas y 1 visible, que puede ir cambiando), entonces lo suyo es:

-Tener todos los gráficos de los elementos que necesitas para montar las pantallas en una de las páginas ocultas.
-Usar otra de las páginas ocultas para guardar back-up's de fondo y tonteridas varias que puedas necesitar.
-Con las dos páginas restantes puedes hacer dos cosas, según tus necesidades:
1. Usar únicamente una de ellas como página visible del juego, donde irás copiando todo a medida que vayas necesitando.
2. Usar la técnica de swap de páginas... o sea, que mientras enseñas una, las actualizaciones las vas haciendo en la otra y así sucesivamente.

Yo creo que para el juego que quieres hacer y si todos los personajes son sprites, con la opción 1 ya te vale.

Para copiar las cosas de una página a otra, pues simplemente con un COPY(X1,Y1)-(X2,Y2),0 TO (x3,y3),1 estarías copiando un rectángulo del tamaño que quieras desde la página 0 a la 1 (luego tienes la opción de copiar con o sin transparencias y tal).

Como ya te he dicho, seguramente que el método se acerca más a lo que haces para PC actualmente.

Hola, el método que comentas en SC5 si que es como se programa ahora y además supongo que deja de existir la limitación de 2 colores por cada 8 pixels en horizontal, de todas formas como este juego ya lo tengo avanzado prefiero acabarlo con los carácteres ASCII.

Por ahora ya he conseguido usar el NestorPreTer y el XBASIC para compilar con lo que consigo un código legible y lo más ahorrador posible en cuanto a memoria y el juego va rapidísimo por el compilador.

Lo de grabar la VRAM en un fichero y luego cargarlo es una pasada, porque es mucho más rápido que modificar los 160 gráficos y crear los 64 sprites y además no tengo que cargar los dos .BAS, solo cargo el del juego que lo primero que hace el es BLOAD para cargar los gráficos pero tengo un problema pierdo los colores. Si no me equivoco la VRAM va del &H0000 al &HFFFE  y ese es el bloque de memoria que grabo, pero al cargarlo recupero los sprites y los carácteres pero no el color de estos, pierdo toda la información de color. ¿ Tengo que grabar otro rango de direcciones para que también se cargue la tabla de color ?

Luego sigo con el problema en SC2 y SC4 que cuando redefino los gráficos me pinta 2 lineas en pantalla y además necesito el "modo mixto" para solo tener que redefinir una vez los carácteres ASCII ¿ como lo hago ?

Gracias.

He seguido leyendo el foro y haciendo pruebas y creo que ya tengo controlado el modo mixto jugando con el VDP(3) para el color y el VDP(4) para los patrones.

Como en principio en SC4 no va el LOCATE y el PRINT he empezado a convertirlos todos por VPOKES pensando que además obtendría más velocidad pero cual ha sido mi sorpresa que es muchísimo más lento hacer los VPOKES que los LOCATE y PRINT y aún se nota más cuando lo compilas con el XBASIC que con los PRINT la pantalla se pinta casi instantánea pero con los VPOKES ves claramente como se va pintando.  ¿ Es normal que me vaya más lento el VPOKE que el PRINT ?  De momento sigo en SC1

Al ver que con los VPOKE me va mucho más lento he pensado en volver a los LOCATE PRINT pero en SC4 no funcionan así que leyendo por este foro he encontrado este formato:


No hace falta poner el VDP(4)=0 para el modo mixto de patrones porque como realmente estamos en SC1 (aunque hayamos forzado el VDP(0) a SC4) ya lo hace de forma automática. Con este modo vuelve a funcionar el LOCATE y PRINT pero no se ven los SPRITES. Si hago lo mismo pero en SC2 los SPRITES se ven perfectos, pero en SC4 no se ve ninguno. He probado a cambiarles el color con COLOR SPRITE$ y no hace nada y además tengo un problema, si pongo la línea de color despúes del SCREEN 1, aunque haya puesto el VDP(0)=4 me da un error porque esa instrucción no funciona en SC1.
Lo que hago es:


Así no da error, pero tampoco se ven los sprites.

Si lo hago directamente sobre SC4, sin pasar a SC1 ni forzar el VDP(0) los sprites se ven perfectamente. ¿ Alquien sabe porque puede pasar esto ?

Tal y como estoy ahora tengo que elegir entre el SC4 con los 8 sprites por linea y un color en cada linea pero pintar los mapas con VPOKE que va muy lento o bien continuar en SC1 con solo 4 sprites por linea y el sprite completo del mismo color pero el pintado de las pantallas muy rápido con los LOCATE PRINT.

A ver si alguien me puede ayudar

Gracias.

Bueno, ya lo tengo todo solucionado. Modo-mixto en SC4 para aprovechar los 8 sprites por linea de MSX2.

Lo único es el pintado de pantalla que sigue siendo muy lento. Entre VPOKES y LOCATE + PRINT la segunda opción me va mucho más rápido y he intentado minimizar los LOCATE poniendo cuando es posible un único LOCATE y luego para moverme por ejemplo a la línea de abajo lo hago con los CHR$ de los cursores (8,10,28,30).

Ahora el "problema", por llamarlo de alguna forma, que tengo es que para ahorrar espacio para las líneas de código y además para que los gráficos no tarden tanto en redefinirse he usado la opción que me comentaron en este post de grabar la VRAM con un BSAVE"";S y luego recuperarla. Es genial esta forma de trabajar, ahora tengo 2 programas uno que genera los gráficos y hace el BSAVE y el otro con el juego que hace el BLOAD, que carga muy pronto y no hay que esperar a que se generen los gráficos pero tengo un problema y es que el fichero que apenas contiene unos pocos gráficos ocupa 64 KB y ya no puedo hacer una ROM con mi juego. Es como matar moscas a cañonazos. He mirado las direcciones de memoria para intentar grabar solo lo justo pero no se puede porque en una zona está la tabla de nombres, en otra los patrones, en otra los colores, otra para los sprites... y el BSAVE solo me deja poner la dirección de inicio y de fin por lo que me veo obligado a copiar toda la memoria.

¿ Hay alguna forma de hacer un fichero solo con algunas zonas de la VRAM o bien hacer una ROM del juego de más de 16KB para poder añadir los 64kb de la VRAM ?

Gracias.

Si el código del juego en sí está en BASIC, tendrás que ponerlo necesariamente en la página 2 de memoria y puede tener hasta un máximo de 16 KB. Dicho esto, podrías utilizar otras 16 KB en la página 1 para ejecutar un cargador de gráficos, pero tendría que estar en código máquina, no en BASIC.

Es factible y bastantes juegos de MSXdev hechos en BASIC emplean técnicas de este tipo. Además, si aplicas compresión, verás que 16 KB de gráficos dan para mucho.

Yo veo dos opciones:

-Hacer varios BSAVE/BLOAD de las diferentes zonas de la VRAM que quieres copiar, para no tener uno único de 64Kb
-Meter todo dentro de un DSK con un AUTOEXEC para que se autoejecute y usar la aplicación DSK2ROM para pasarlo a ROM, con lo que tendrás una ROM del tamaño que sea.

No sabía que existiera un DSK2ROM, lo he probado y va genial, aunque me crea una rom de 256KB. Intentaré reducir los ficheros .BIN al máximo y cargar varios.

Saludos.

Creo que el DSK2ROM tiene una opción de compresión, para que la rom que genera sea más pequeña.

Bueno, cuando parecía que lo tenía todo solucionado: modo mixto en SC4 con 8 sprites por línea, un fichero BIN de 16KB para todos los gráficos del juego , conversión a ROM mediante el DSK2ROM, velocidad de sobra gracias al TURBO BASIC... voy y me encuentro con el temido OUT OF MEMORY cuando aún no tengo ni el 25% del juego.

No se muy bien si lo que he agotado es el espacio para variables o para el código fuente o incluso de los dos (no se si van juntos o no). ¿ se puede ampliar el tamaño ?
En variables puedo quitar un vector de 20 strings de 30 carácteres cada uno que uso para pintar la pantalla y detectar las colisiones aunque estas las podría comprobar haciendo un VPEEK a la dirección de pantalla que quiero en vez de leer el valor en el vector, pero incluso quitando esas 20 variables no se si tendré suficiente memoria para acabar el juego.
Ya tengo hechas las cosas típicas para ahorar memoria CLEAR 30 (no uso cadenas de más de 30 carácteres), MAXFILES=0, DEFINT A-Z..

Me he leído todo el manual de NestorBASIC que pone en las características: Acceso a toda la memoria mapeada del ordenador, hasta 4 Mb aunque en la práctica no se muy bien si puedo usar esa memoria en mis juegos BASIC porque he visto que tiene funciones para leer y escribir datos en otros segmentos de la memoria pero creo entender que para usar esos datos los tengo que copiar sobre varibles del BASIC así que el espacio lo sigo gastando igual ¿verdad?
También tiene funciones para tener cargados listados BASIC en otros segmentos de memoria, pero al final creo que solo puedes usar uno, el que está en el sitio reservado para los programas en BASIC por lo que tampoco es útil de cara a hacer un juego grande y tener varios programas pequeños no me siven para el juego.

¿ Alguien sabe si realmente esa memoria a la que se puede acceder con NestorBASIC puede ser útil para hacer el juego ?


Lo único que parece que si que podré usar para ahorar espacio es NestorCadenas y más en el juego que estoy haciendo que hay unos cuantos textos. Esta noche lo intentaré poner a ver si puedo ahorrarme los textos del juego.

Gracias.

Yo lo que haría es mirar en que se va toda la memoria. En basic los comentarios ocupan un precioso espacio de memoria, reutiliza variables, usa algoritmos que requieran poca memoria y eso de que miras las colisiones en ram en lugar de vram me parece sospechoso. Los gráficos deberían cargarse directamente en vram y las colisiones entre sprites solo requieren cuatro bytes, las posiciones x e y de los dos sprites que van a colisionar. Si son colisiones contra el escenario lo mejor es leerlo desde vram no tener un vector de 80*25 en memoria.

Hola.

En el código no hay comentarios porque al pasarlo por NestorPreTer se eliminan todos espacios y comentarios.

He revisado las variables y solo uso 2 de tipo STRING 'S$' que la uso tanto en el INKEY$ para leer si pulsan la letra 'M' o 'N' (botón 2 del joystick) como para leer todos los DATA y 'T$' donde está el texto que va pasando por el marcador de abajo. Y luego está el vector de 20 dimensiones donde tengo el mapa que hay en pantalla, que además de servir para comprobar las colisiones con el decorado de una forma más rápida que leyendo la VRAM me servía para las zonas oscuras donde vas con la vela encendida y solo ves el decorado de tu alrededor y el resto de pantalla está en negro. Al tenerlo en variables se que tengo que pintar según la posición del jugador.

Luego de INTEGERS tampoco tengo tantos:

Yo creo que lo que se come toda la RAM es el XBASIC/NBASIC y luego el código que he hecho para pegar los objetos disponibles (suelos, paredes, rechos, sillas, mesas, plantas, camas, cuadros....) que son funciones cortas, pero hay muchas y el total son muchas lineas de código.

Lo que voy a intentar hacer esta noche es meter las pantallas en un fichero de texto (aunque estoy en SC4 "engaño" al BASIC para que crea que esté en SC1 y me deje hacer PRINTS de los carácteres ASCII que he modifiado) y con la ampliación NestorCadenas del NestorBASIC meter ese fichero de texto en una zona de RAM fuera de la del BASIC, así me ahorraré todas las líneas de código que pintan los objetos en pantalla y las que dicen cada pantalla que objetos tiene. Lo malo será tener que pintar a mano las pantallas en un fichero TXT, pero eso ya es otra historia.

Supongo que así tendré suficiente memoria para empezar a poner los enemigos.

Algunas pantallas de como va el juego:

(http://www.remakesonline.com/images/foros/panou_0003.png)

(http://www.remakesonline.com/images/foros/panou_0004.png)

(http://www.remakesonline.com/images/foros/panou_0005.png)

(http://www.remakesonline.com/images/foros/panou_0006.png)

Saludos.

EL Xbasic se come bastante RAM, si, y lo peor es que es complicado controlar cuanta, como y donde.
Yo deje el Basic ya por eso, por toparme con demasiados impedimentos, especialmente el no tener ya el control de lo que estas haciendo. Te comes la olla y al final no queda algo igual a lo que quieres porque has de renunciar a esto o a aquello.
Asi que me era mas facil aprender ensamblador (ya puestos a pelearse), que seguir asi. Al menos el esfuerzo compensa mas una vez tienes el resultado. Si el juego no da mas, sera porque el MSX o el programador ya no dan mas ;)

Asi en Basic, para ahorrar algo de RAM... que yo recuerde.... si metias todas las variables en una sola matriz ganabas algo.
Si hay zona de VRAM que no uses, aprovechala tambien para meter datos. Usa la zona de F-keys en RAM para meter datos tambien.
Y si hace falta dividir el codigo en varios .BAS y vas cargando, pues arreando. No me acuerdo de mucho mas :P
El Basic terminaba siendo tener que inventarse las mil y una. Con Ensamblador te quedas en mil, te ahorras una ;)

Me dejaba 2 cosillas:

1- Si, la memoria accesible desde Nestor Basic es MUY util para el juego.
2- El juego va teniendo buena pinta :) Suerte.

Plas plas plas  :)

Totalmente de acuerdo con Kun: para hacer algunas cosas en BASIC la solución es tan complicada que resulta más fácil hacerlo en ensamblador. Y el resultado, en cualquier caso, será mucho más rápido, compacto y eficiente (salvo error mayúsculo).

Y, lo creáis o no, detrás de este profeta del ensamblador hubo una vez un programador en BASIC que hacía equilibrismos para conseguir algunos juegos. Me encantaría repescar alguno de mis programas viejos para ver qué tal han aguantado el paso del tiempo...

Bueno, más o menos ya se porqué del problema de la memoria.

Según el manual de NestorBasic el TurboBasic reserva 256 bytes para los STRING (aunqu hayas hecho un CLEAR 30 para que solo reserve 30) y en mi caso que tenía la Matriz de 20 elementos para la pantalla y luego 2 más hacen 22*256 = 5,5 KB.
Para el BASIC hay unos 28KB pero si cargas el compilador se quedan en unos 12KB y si le quitamos los 5,5KB que he consumido con los STRING me quedan solo 6,5KB para todo el listado y las variables.

Ayer empecé a hacer prubas con NestorBASIC + NestorCadenas para pasar todos los STRING a un serctor de la RAM que no sea el del BASIC y ya lo hice funcionar. Ahora tengo que pasar todos las fases y los textos del juego (que hay muchos) y se me quedará un programa muy corto, con lo que creo que tendré suficiente memoria libre para poder acabar el juego.

Saludos.

Me alegro :)

Así es como debe ser... el programa ha de contener únicamente el motor del juego propiamente dicho y el resto de cosas las vas cargando externamente.

A ver lo que da de si esto, el fichero de textos con las fases ya ocupa 25KB y por ahora solo tengo 44 pantallas de las casi 100 que tiene el juego. Ya se empieza a notar la lentitud al buscar la etiqueta dentro de NestorCadenas para que me devuelva la dirección donde están las cadenas de la fase que quiero mostrar.

Seguiré informando.

Saludos.

Pues ahora que va tomando todo forma no me acaba de gustar como están quedando los gráficos y creo que debería mirar lo de SC5 y los COPY.

He pensado en un sistema para que me sirva el método que estoy haciendo ahora de poner las fases en un fichero de texto y cargarlo en memoria no destinada al BASIC (el juego tiene 100 pantallas y no cabe en la memoria de BASIC), y sería hacer un BMP a bloques de 16x16 (también podría ser de 8x8) y asignarle un número a cada uno empezando por el 32, de forma que en el fichero de texto de las fases pongo el caracter ASCII [32..255] que corresponde con el número de bloque que quiero pintar y el lugar donde lo pinto viene definido por la posición de ese caracter en el fichero de texto.
Vamos, lo mismo que los tiles de SC2, así las pantallas son carácteres en un fichero de texto (que se carga en una zona de la RAM no reservada para el BASIC gracias al NestorCadenas) y no un montón de copys que no sabría como ponerlos sin ocupar toda la memoria del BASIC.

Ahora las preguntas, ¿ que formato o con que programa he de grabar desde Windows la imagen con lo bloques de 16x16 que quiero cargar en las páginas VRAM del MSX ? ¿ y como se cargan ?

Luego lo otro de los COPY y SET SCREEN parece fácil de hacer y no creo que tenga ningún problema.

Gracias.

Hay varios conversores por ahí... puedes usar el BMP2MSX, por ejemplo.

En cuanto al formato origen, usa BMP de 24 bits y con unas dimensiones de 256x212.

El resultado será un archivo .SR5 (imagen) y otro .PL5 (paleta). Te recomiendo la opción de generar todo integrado dentro de un mismo fichero .SC5 y recuperar la paleta con la instrucción COLOR=RESTORE.

Para cargar la imagen, es así de simple:

10 SCREEN5
20 BLOAD"IMAGEN.SC5",S
30 COLOR = RESTORE

Para cargarla en una página u otra, utiliza la instrucción SET PAGE antes del BLOAD

Perfecto, es lo que buscaba. Aún no lo he probado pero parece muy fácil.

Y luego otra duda que tengo con los sprites. Hasta ahora que había usado MSX1 solo tenía una página de VRAM y tenia en el rango &H3800-&H3FFF los 64 sprites de 16x16 (o 256 de 8x8). En screen 5 tengo 4 páginas de VRAM ¿ puedo tener 4x64 sprites ?
Es que 64 son muy pocos y mirando Metal Gear 2 solo en el personaje principal han gastado 48 sprites para caminar, lues están los de arrastrarse por el suelo, el de la muerte y luego los enemigos que les he contado 24 sprites así que usan más de 64 sprites (si es que son sprites y no COPYS, pero parecen sprites porque solo usan 3 colores por línea que son 2 sprites más el OR).

Si se pueden poner más de 64, ¿ como se accede a ellos, poniendo 64,65..... ?

Gracias.

No conozco a fondo el tema de sprites HW para MSX2, porque todos los juegos que hice en su día, usaban principalmente sprites SW... pero vamos, que simultáneamente sólo puedes usar 32 sprites de 64 definidos. De lo que no estoy seguro es de si puedes tener definidas diferentes tablas de sprites y "activar" una u otra... que lo confirme alguien que sepa más del tema.

No sé si son sprites HW o SW... pero se me ocurre que se puede averiguar fácilmente si ejecutas el juego en un emu en el que se puedan deshabilitar los sprites HW.

Lo que sí que hacían en algunos juegos es redefinir los sprites en tiempo real (puede que ese sea el caso del MG2), de esa forma no hay límites en ese sentido.

Hola de nuevo.
Estoy intentando detectar en que máquina estoy (MSX1, 2, 2+...) y la función PEEK(43) me devuelve 145 en un MSX1 y no un 0 como suponía. ¿ Es otra la dirección que hay que leer para saber que tipo de MSX es ?

Gracias.

Según http://map.grauw.nl/resources/msxsystemvars.php la dirección es &H002D. Si lo prefieres en decimal, 45 (no 43).
La que tú estabas leyendo tiene pinta de ser la del charset y la frecuencia por defecto del VDP.

Gracias, con el 45 si que va bien.

Saludos  :griel: