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.

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.

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.

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.

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:









Saludos.

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.

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...