Aunque programar se me da bastante mal, hace bastante tiempo y ante mi propio asombro
conseguí hacer un generador de mapas, lógicamente en KUN BASIC, usando tiles de 16x16. El
caso es que paso a paso iba consiguiendo avanzar más y más pero en mi cabeza siempre tenía la
misma pregunta. ¿Cómo iba a hacer que el sprite no atravesara las paredes? pues eso ¿Qué
técnica se usa para diferenciar los tiles que son obstáculo se los que no? El generador guarda
el mapa en la VRAM. Es algo a lo que le he dado mil vueltas y no encuentro solución. La verdad es que me gustaría terminarlo y usarlo algún día aunque quizás no sea lo suficientemente rápido en
un posible juego. 

Gracias

No me parece muy practico guardar los mapas en VRAM, solo si la necesidad de RAM es muy acuciante, supongo que los guardas en una pagina que usas.

Lo mejor es que lo guardes en RAM es mas rapido acceder a ellos y se supone que vas a tener que acceder mucho si es el mapa de un juego.

De todas maneras el sistema es el mismo como te ha dicho Nerlaska, tendras una tabla o matriz con las IDS de las tiles y como van colocadas, puedes aprovecharla sabiendo que tipo de tile se puede atravesar o no, hay una manera muy rapida por ejemplo si das IDS de tile mayor de 127 a las que no se pueden atravesar solo tienes que mirar el primer bit para saber si se atraviesa o no.

Ejemplo:


128 128 128 128 128 128 128 128 128 128                      10000000 10000000 10000000 10000000 10000000 10000000 10000000 10000000

128 001 001 001 001 001 001 001 001 128                      10000000 00000001 00000001 00000001 00000001 00000001 00000001 10000000

128 001 001 001 001 001 001 001 001 128                      10000000 00000001 00000001 00000001 00000001 00000001 00000001 10000000

128 001 001 001 001 001 001 001 001 128                      10000000 00000001 00000001 00000001 00000001 00000001 00000001 10000000

128 001 001 001 001 001 001 001 001 128                      10000000 00000001 00000001 00000001 00000001 00000001 00000001 10000000

128 001 001 001 001 001 001 001 001 128                      10000000 00000001 00000001 00000001 00000001 00000001 00000001 10000000

128 128 128 128 002 128 128 128 128 128                      10000000 10000000 10000000 10000000 00000010 10000000 10000000 10000000

Aqui tienes una habitacion con una puerta. (tipo Zelda totalmente).

Para saber si una tile se atraviesa o no solo tienes que hacer un "and 128" si da 0 se puede atravesar si no, no.


Dependiendo de la cantidad de tile que uses puedes incluso ahorrar memoria metiendo en un byte mas de un tile usando los primeros 4 bits para uno y los 4 segundos para otro, vamos como los propios colores en la vram.

En principio los guardé en VRAM porque había visto algún juego que otro, véase No Name, que
almacenaba el mapeado ahí y supuse que era lo normal. Ya veo que en principo hay que saber
que tiles van a ser los obstáculos para luego agruparlos en las páginas de la VRAM de manera que sean identificables como, por ejemplo, me habéis comentado. Sólo una duda más, no tengo ni idea
de qué direcciones de la RAM son seguras a la hora de almacenar datos y no machacar el propio listado BASIC.

Ya os dije que programar nunca ha sido lo mío, se nota ¿no?. Aún así reconozco que poniéndose
acabas consiguiedo cosas que nunca esperabas. Gracias por la ayuda.

OK. Gracias

Ya que estamos con el MSXBASIC ... el KUNBASIC consume muchos recursos? cuanto acelera la ejecución normal de un programa BASIC?
Y por otro lado ... además de las herramientas de NESTOR para poder editar MSXBASIC en archivos de Texto ... hay alguna otra?
Vamos, basicamente, para poder trabajar con MSXBASIC de la mejor forma posible y para poder sacarle el mayor partido, que cosas hay?

Yo te puedo hablar de lo que yo he podido comprobar.
En cuanto a recursos, consume toda la memoria que pueda, un programa hecho integramente en Kun Basic te deja tan solo 10k (aprox.) para el código fuente, frente a los 24k (aprox.) que te deja el MSX-BASIC original.
En cuanto a la velocidad, depende, en instrucciones graficas como son PUT SPRITE o COPY, son muy veloces, tanto que yo me he hecho un "cutre editor grafico para screen 8", y he tenido que ponerle un contador para mover el puntero del raton.
Otras como por ejemplo los FOR .. NEXT, son algo mas veloces que el MSX-BASIC, pero no mucho más. Hablo solo de mis impresiones.
Por ahí hay un juego el "Mr. HAWAII" que esta hecho integramente en KUN-BASIC, (no en NESTORBASIC), menos la música que esta hecha en CM, creo que es un ejemplo de lo que puede dar de si el lenguaje.
Yo no uso ninguna de estas herramientas, vamos que lo poco que hago lo hago directamente sobre el MSX, a la antigua usanza. Entre otras cosas porque la herramienta de NESTOR no es un editor de MSX-BASIC en si, sino un programa que pasa el código de un archivo de un editor de texto cualquiera a un archivo basic.

Por lo demás yo no conozco más herramientas para facilitar la programación en basic, si alguien conoce otras sería un detalle darlo a conocer.

Yo, en mis juegos en Nestorbasic, también guardaba los mapas en VRAM y luego los consultaba con VPEEK (al principio con POINT, que es más lento que su padre).

El principal problema del kunbasic es que los turbo-bloques tienen un tamaño muy limitado (unos 8-9Kb). Sobre los truquillos de aceleración, básicamente tratan de que el kunbasic trabaja mucho más rápido con múltiplos de 2, tanto en cálculos como en copy's.


Yo usaba el editor AKID en el propio MSX para editar, y luego ejecutaba un .BAT que me había hecho, que me compilaba, me iba al basic y me ejecutaba el programa. Luego, tenía redefinida una tecla de función en el programa, para volver automáticamente al MSX-DOS2 y volver a editar el fuente. Automatizando todo lo posible! 

Hombre para mi por ejemplo el No Name de Kai Magazine es bastante sorprendente ya que
incluso usa scroll pero también te recomiendo los juegos de Imanok, tiene un buen surtido.