Karoshi MSX Community

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

Gracias

Hombre .. no se lo que te dirán por aquí pero .. necesitas o bien:

1) SABES QUE TILES SON OBSTACULO: con lo que te permitiría tener los mapas clavados en VRAM y usar los ID de Tile para saberlo.
2) LA FORMA MAS HABITUAL: Esa información la guardas paralelamente con la VISUAL. Por ejemplo: EN otra matriz, como un flag, ...

Me hago entender?

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.

Efectivamente, yo lo hago así. Es decir, tengo una matriz de datos en RAM que reflejan lo que realmente hay en VRAM. De esta forma puedes hacer chequeos rápidos.

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.

Eso lo mejor no será que te declares un ARRAY de BASIC y ya esta? quiero decir .. que uses las variables del BASIC para hacer esas cosas y asi no tienes que preocuparte por nada. De todos modos yo no soy experto en MSXBASIC, se programar en él pero igual la gente experta te dice que hay zonas de la RAM no usadas o que se pueden usar o yo que se .. el MSX esta lleno de TRUQUIS para programadores :)

OK. Gracias

Hola Evpon,

En tu pregunta no dices si el programa es para MSX1 (supongo que si) o para MSX2, lo digo por el tema de haber usado KUN-BASIC, que normalmente está más preparado para la segunda generación.

En el primer caso, yo personalmente usaría la VRAM, ya que KUN-BASIC consume mucha RAM al generar código objeto junto con el código fuente cuando se está ejecutando el programa. Y por supuesto en VRAM también se puede usar el método propuesto por Sd-Snatcher, que es rápido de verificar.

Y si el programa es para MSX2, yo lo que estoy haciendo son mapas en páginas no activas de VRAM (seleccionando con SET PAGE), a cada title le asigno un color (p.e. en Screen 8 habría 256 colores, por tanto 256 titles difrentes) y luego compruebo simplemente con la instrucción POINT si es distinto de cero (por ejemplo) para saber si es un bloque atravesable  o no.

Para los modos de pantalla de menos colores, como Screen 5, se puede hacer lo mismo pero usando dos pixels, con lo que con la fórmula, " valor=16*point(x,y)+point(x+1,y) " obtienes la posibilidad de meter hasta 256 titles opacos. (o leyendo directamente con VPEEK, obtendrías directamente el valor).

Este metodo tiene la ventaja, de que por ejemplo en un ordenador de 128K de VRam, usando una sola página en Screen 5, te permite almacenar hasta 32K de información, más que el propio codigo fuente en BASIC.

Espero haber aportado otra idea que te pueda servir.
Un Saludo

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?

En este foro se comento una serie de truquillos de programacion para acelerar lo mas posible los programas basic. Es lo unico q se me ocurre despues de lo q habeis comentado. Fue en un concurso de juegos en basic q se organizo.
Yo no conozco nada mas.  :-[

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.

Pues muchas gracias señores .. ha sido muy constructivo e interesante.
De todos modos además del "Mr.Hawaii" conocéis algún otro juego hecho en KunBasic en el que digas ... Ole la gracia morena de juego hecho en BASIC :)
Vamos .. algo que parezca increible o inusual . Sorprendente.

El MSXBASIC mola porque es un lenguaje de alto nivel y enciendes el MSX y ya lo tienes .. eso es lo molón. Lo que pasa es que tiene sus inconvenientes malignos .. sobre todo cuando estas acostumbrado a currar en C/C++ y cosas de esas.

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!  ;)

Es para MSX2 SCREEN5. Osea que no iba mal encaminado guardando datos en VRAM. :) Lo que hago es asignar con VPOKE's un pixel a cada tile según su posición X, Y en la página donde se guardan. Diría que es bastante rápido al regenerar los mapas en un posible juego lo que todavía no sé es como Kai metía hasta scroll en ellos. Gracias por vuestra ayuda!

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

Si, los de IMANOK la verdad es que algunos de ellos dices .. joder .. que guapos. Aunque corrigeme si me equivoco .. usabas NestorBasIC Imanok?
Por otro lado .. echare un vistazo al NO NAME este que nombras.

Sí, las versiones que hay ahora en la web, usan todas Nestorbasic.

Échale un ojo también al 'Nuts'. Para mí, es el mejor de los que hizo.

chicos que es lo de imanok?

yo tengo una duda con respecto a este tema... también... ???

¿Como habria que programar a traves de vpeek las condiciones para que no pueda pasar?

imagino que la secuencia sera algo asi como:

se toca el joystick, se lee mediante vppek si puede o no puede avanzar hacia ese valor y si no puede pasar no pasa...

pero ¿mediante que comandos?

"Los de Imanok" hace referencia a sus juegos, Imanok es uno de los desarrolladores con más experiencia y en activo que tenemos por estos lares :). Pasate por su página (http://imanok.iespana.es/)

La secuencia habitual para moverse y detectar obstáculos en el fondo es:

1) Mover el bicho a las coordenadas en curso
2) Lees la dirección del joystick.
3) Según sea esta, lees (usando VPEEK) lo que habrá bajo la posición a la que te desplazarías.
4) Si no es un obstáculo modificas las coordenadas y si lo es, las dejas como están.
5) Vuelta a 1)

La fórmula a usar en el VPEEK es muy sencilla, piensa en cuantas columnas y filas hay en pantalla. Por ejemplo, si en screen 1 la pantalla comienza en la dirección $1800 (pásalo a decimal si te lías) y cada una de las 24 filas (Y) tiene 32 posiciones (columnas o X), ¿cual sería la posición de memoria que habría bajo X=16 e Y=12?,...tu mismo ;). Para que te quede más claro te puedes guiar de un cuaderno cuadriculado, seguro que lo pillas al vuelo.
Una vez que sepas calcular esa dirección, no creo que tengas ningún problema en deducir la relación que habrá entre esa posición y las que están inmediatamente encima, debajo, a su izquierda o a su derecha. Eso es todo lo que necesitas :)

bueno, retomo este tema también porque estoy repasando cosas y hay algunas que sigo sin tener claras.

hablabais de pasar los datos a la RAM o a la VRAM... ¿como se hace esto?
alguien podria iniciarme?
he visto que también se habla de hacer la deteccion de obstaculos, declarando un array en Basic... pero... ¿como le digo yo a la maquina cual es la estructura de la habitación? ¿tambien con datas?
¿podriais ponerme unos ejemplos para ambas cosas?
Graaacias!

Pero, ¿en BASIC o en ensamblador?

Si es en ensamblador, tienes una función en la BIOS que se encarga de hacerlo a toda velocidad, sólo tienes que llamarla con los parámetros apropiados:


Si es en BASIC, pues muchisimo más lento; pero podrías hacer lo mismo con un bucle de VPOKES, no hay instrucción que te lo haga de golpe:


...o algo así, dependiendo de lo que te venga mejor o necesites en tu código.

Respecto al mapeo de habitaciones, supongamos que tu habitación tiene 8x8 posiciones y que tiene esta disposición:


Si las X representan muro y los puntos terreno despejado, puedes optar por mapearlo de muchas formas, si quieres ahorrar memoria y no te importa que todo vaya un poco más lento puedes usar 1's para las paredes y 0's para lo vacio:


Si quieres que en BASIC vaya todo un poco más rápido a costa de sacrificar memoria, puedes asignar arbitrariamente un byte a cada posición, si utilizamos 1 para los muros y 0 para lo vacio una vez más:


Así los cálculos para saber que hay en la posición en la que te encuentres son más sencillos y rápidos (tampoco tanto; pero bueno).

Gracias Jl, por tus explicaciones, pero sigo sin enterarme...

no entiendo esto:

RAM=&HD800
FOR VRAM=0 TO 6143:VPOKE VRAM,PEEK(RAM+VRAM):NEXT

ni tampoco porque me das esa linea de datas?

te importaria explicarme un poco más?, por favor.

Esa linea lo que hace es volcar 6144 bytes consecutivos almacenados en la RAM a partir de la dirección &HD800 a la posición 0 de la VRAM. Supongo que lo que te confunde es lo de RAM+VRAM; pero no hagas caso, no lo he hecho más que para aprovechar la variable del bucle. Otra posible forma de volcar desde BASIC, la RAM a la VRAM es simplemente usando los datos almacenados en lineas DATA, seguro que ya has visto este método más de una vez:


Por cierto, con lo anterior estoy redefiniendo la letra "A" en screen 1, o lo que es lo mismo copiando 8 bytes de la RAM (donde quiera que el BASIC los haya situado) a la VRAM.

Cualquier conjunto de datos que quieras almacenar en BASIC deberás hacerlo mediante lineas DATA, ya sean gráficos, mapas o cualquier cosa. Digamos que yo he transcrito esos minimapas que te puse a valores y he puesto las lineas DATA tal como quedarían en tu programa BASIC :)

Todo esto que te explico es para BASIC que supongo que es lo que pretendes usar, ¿correcto?

correctisimo! muchisimas grácias! ;)

lo cargare de la segunda forma de momento, pero te quiero preguntar, solo por curiosidad:

¿que hace ahi entonces ese PEEK?

el PEEK lo utiliza para leer la informacion contenida en la RAM y el VPOKE para escribir la informacion en la VRAM

pero...
porque hay que ponerlo al hacer el vpoke? dentro, quiero decir.
me refiero a despues de la coma, esto no lo habia visto nunca...

Ahhh, ¿te refieres a eso?. La práctica totalidad de los lenguajes de programación permiten el uso de "expresiones" en lugar de valores, una expresión en este caso sería cualquier constante, variable o función que devuelva algún valor. Según esto y teniendo en cuenta que la sintaxis del VPOKE es VPOKE direccion,valor; pues cualquiera de las siguientes construcciones sería válida:


Esto es aplicable a cualquier instrucción de MSX-BASIC, por ejemplo puedes poner:

Gracias Jlturstan!
luego le pego unas vueltas, a ver si lo pillo, que estoy currando y no puedo ahora.
Un saludo!