Karoshi MSX Community

Buenas tardes familia.
Como algunos ya sabeis sigo investigando en el mundo de los sprites, y en el mundo del basic, voy poco a poco avanzando y haciendo mis programitas, empollando de todo lo que pillo, en plan libros y revistas y tal...
bueno, el caso es que me gustaria comprender el vpeek y el vpoke. En la mayoria de los libros que tengo (por no decir todos) hablan sobre el tema pero basicamente para decir que solo los programadores "expertos" deben hacer uso de esto, y la información que consigo a traves de las revistas de la epoca, no me deja nada claro, quiero decir:
Se que al igual que se crea un sprite mediante algo parecido a esto:

10 screen 2,2
20 s$=""
30 for i=1 to 32
40 read a
50 s$=s$+chr$(a)
60 next i
1000 data 128,1,15.........

y despues...

80 put sprite0,(x,y),15,0 (por ejemplo)

también se puede hacer mediante vpeek y vpoke y de tal forma hacer que todo sea mas rapido.

lo que me gustaria saber es cual es la manera exacta de hacer lo mismo mediante la sentencia vpeek y vpoke, que pasos hay que seguir?? me refiero ha si hay un codigo digamos "patron"
para hacerlo.
estoy con el msx red book y estudiando las direcciones destinadas para cada cosa, pero digo yo que existirá una formula para darle los datos de la forma del sprite a la vram y poder hacer uso de él o de ellos en basic.

podeis ayudarme por favor?
gracias a todos!!

Si mal no recuerdo del BASIC (esto del ensamblador me ha hecho olvidar el MSX-BASIC) te faltaría la instrucción

70 sprite$(0)=s$


En efecto, se puede hacer.


Lo que tienes que hacer es localizar la dirección de la tabla de patrones de sprites en el screen que estés utilizando. Si mal no recuerdo, el número a usar en BASE sería


siendo SC el modo de pantalla en el que estemos. Con lo que la dirección de la tabla de generadores de sprites sería:


Ahora tendríamos que elegir el sprite adecuado (se pueden definir un total de 256 patrones de sprites en modo 8x8 ó 64 en modo 16x16). La dirección de la VRAM donde se empieza a guardar el patrón N-ésimo de un sprite sería:


siendo TS (como su propio nombre indica) el Tamaño del Sprite en bytes (8 ó 32 bytes).

A partir de ahí puedes empezar a VPOKEAR todos los datos que quieras, que serán metidos en el patrón del sprite N-ésimo. Si te pasas de los 8 bytes (para sprites de 8x8) o de 32 bytes (para sprites de 16x16), empezarás a definir el patrón del sprite (N+1)-ésimo y así sucesivamente. Si tienes, por ejemplo, 4 patrones de sprites para definir, simplemente localizas la dirección de VRAM del primero de todos y empiezas a vpokear los 32 ó 128 bytes (según sean sprites de 8x8 ó 16x16 respectivamente) de datos.

Obviamente todo este código es genérico. Si usas un Screen determinado (o un patrón inicial conocido) podrás substituir la fórmula por su valor concreto, lo que te dará una mayor velocidad al ahorrar cálculos.

Espero que esta explicación te sea de ayuda.

Saludos
--
SapphiRe

SapphiRe, estas en todo. :)

Tienes razon, falta la instruccion:

70 sprite$(0)=s$

Si no, no defines el sprite. El "0" del parentesis especifica el numero del sprite que defines. Lo que no me queda claro ahora, es si el segundo parametro de la instruccion SCREEN define el tamaño de los Sprites (creo que asi esta puesto en modo 16x16)... o puede que yo este metiendo la pezuña... pero como ahora estoy con el Ensamblador, como que me he olvidado. Pero miralo por si acaso.

Lo cierto es que a traves de los comandos BASE, VDP y VPOKE/VPEEK se accede bastante mas rapido a los procesos de video que a traves de comandos como SPRITE, o al menos, eso parece. Pero sin embargo, mi consejo es que primero te metas con los medios directos y hagas pruebas. Eso afianzara conocimientos que luego te serviran para lanzarte poco a poco a cosas mas complicadas. Por supuesto, el uso de estas instrucciones deberia ser el paso final, ya que esos conocimientos te serviran bastante cuando un dia te metas en el Ensamblador. Pero antes, el BASIC es un buen punto de partida, ya que te permitira ver que puede hacer el MSX para ti.

Bueno, la verdad es que todo esto es para robarle un poco de protagonismo a Sapphire... ¡dios, estas en todas partes! ¿Como lo haces? ;)

Por cierto, gracias por la ayuda de las interrupciones y lo de RRL y RRD. Eres un libro de conocimientos :)

Salu2.

es verdad Saphire, me estas siendo de gran ayuda, gracias otra vez.
si, es cierto olvide poner la linea 70 para decirle que numero de sprite es ese en cuestión... :'( ejeeemmmmmmmm....

a ver si me aclaro:
primero defino el sprite tal y como lo estaba haciendo y despues con la instrucción base lo cargo en la vram?? :-[
quiero decir que si la instrucción base es posterior a la rutina de creaccion del sprite?

y en este codigo que me das: (SC+1)*5-1 ¿sc hay que reemplazarlo por el numero de la dirección que esté utilizando el modo de pantalla seleccionado? (screen 2 en mi caso)
por que va acompañado de +1? y que es ese 5*1??

una ultima pregunta: ¿como vpokeo los datos del sprite? seria algo asi como vpoke(15,128....)???

siento ser tan lerdo, espero que mantengais la paciencia y consigais hacer que lo comprenda del todo.
mil gracias otra vez! :god:

Si es que soy profesor... no puedo evitarlo...


Al revés...


No, hay que reemplazarlo por el NÚMERO de pantalla. En este caso un 2. ¿Por qué esa fórmula? La respuesta es que el número que hay que usar en BASE para obtener la tabla de definiciones de patrones de sprites es:

SCREEN 0 -> 4
SCREEN 1 -> 9
SCREEN 2 -> 14
SCREEN 3 -> 19
...

Y así sucesivamente, por lo que (SC+1)*5-1 es la fórmula que calcula el número a consultar para el modo de pantalla SC (es que soy matemático, tampoco puedo evitarlo).


Si PP es el primer patrón de Sprites que quieres modificar y NP el número de patrones de sprites que quieres modificar puedes usar el siguiente código:


¡OJO! Asumo que estás en Screen 2, por eso el 14... si cambias de pantalla tienes que cambiar ese número. También ambos 32, que son para sprites 16x16 (si fueran 8x8 serían 8 ). Si tienes el RESTORE apuntando a los datos de los sprites esta rutina rellenará NP patrones de sprites a partir del patrón PP.

No te agobies, aquí creo que ya se impone una relajada lectura del MSX technical handbook (¿que tal te desenvuelves con el inglés?): Chapter 4,  VDP and display screen (parts 1-5). (http://www.konamiman.com/msx/th-4a.txt). En el apartado 5 se explica el funcionamiento de los sprites en modo 1 (los del MSX1) y en modo 2 (los del MSX2).

Es fundamental que para controlar la pantalla tengas siempre muy clara cual es su estructura de la memoria de video. En este otro documento (http://www.work.de/nocash/portar.htm#videodisplayprocessor) tienes expuesta de forma muy básica como se distribuyen las áreas en la VRAM en cualquiera de los modos. Como verás, screen 2 está dividida en las siguientes zonas:


Está claro que ahí tienes los 16K de VRAM (0000-3FFF),
Para modificar una dirección con el valor que quieras lo único que tienes que emplear es el vpoke, por ejemplo, VPOKE &H1B00,92 (haces que la coordenada Y del sprite 0 valga 92). Con el VPEEK lo que podrás hacer es leer su contenido, por ejemplo, Y=VPEEK(&H1B00).

Como ejemplo, pasa a SC1 tecleando y luego teclea este churro de VPOKEs, a ver si pillas lo que se ha hecho:


Ya sólo es cuestión de experimentar... :)

ok, entonces:
(sc+2)*5-1 es la formula para saber el numero que conultar, esto creo que lo entiendo.

pero sigo sin comprender el listado, porque en basic existe una o varias lineas data donde poner los numeros (ya sea en binario o decimal...) de los valores digamos de los bytes que se van a encender.
pero en tu listado no comprendo por ejemplo que quiere decir ese "read da" ¿hace referencia a alguna linea data? es decir, ¿aunque defina asi los sprites tengo que seguir teniendo unas lineas data con los valores de la composición del sprite?

y ¿podrias explicarme un poco más en detalle lo que hace la linea 20?
sigue sin quedarme claro que es pp y que es np... tengo que sustituirlos por algun numero?

graaacias.

lo siento jj no habia visto tu respuesta, muchas gracias!
me pongo con ello, a ver que sale.
un saludo!

Claro, las líneas data ya las tienes que poner tú con la definición del sprite.


¡Eso es! Esa línea lee el DAto.


Comienza un bucle FOR..NEXT para incrementar la DIrección tantas veces como sea necesario desde el INicio hasta el total de bytes a VPOKEar (32 veces el Número de Patrones que quieres modificar).


Si quieres sí, si no, puedes usarlos como variables.

PP -> Primer Patrón a definir
NP -> Número de Patrones a definir

Es decir, si quieres modificar los patrones del 7 al 21 (ambos inclusive):

PP=7
NP=15

Puedes usar la rutina que te he pasado como una subrutina genérica y llamarla con un GOSUB, para lo cual deberías tener un RETURN al final de la misma. Lo único que tendrías que hacer sería algo como:


Donde xxx es la línea de inicio de la subrutina y en la línea 10000 comienzan los DATAs correspondientes a los 15 patrones de sprite que quieres modificar (desde el 7 al 21 ambos inclusive).

Saludancias
--
Sph.

bueno, creo que lo tengo. (igual es mucho decir)
voy a practicar un poco a ver que saco y a ponerme con esa "lectura relajada del msx red book" de la que Jl habla ;)
muchisimas gracias otra vez, de verdad, de la güena. ;D
salud!

tengo una nueva duda sobre el tema, JL me decia esto:

Para modificar una dirección con el valor que quieras lo único que tienes que emplear es el vpoke, por ejemplo, VPOKE &H1B00,92 (haces que la coordenada Y del sprite 0 valga 92).

lo que no entiendo es ¿porque justo la coordenada y? ¿que habria que hacer si quisiese mover la coordenada x? pensaba que estaban en la misma dirección...

y otra cosa:
aunque me refiera a las direcciones del vdp a traves de hexadecimales... ¿los atributos se le dan en decimal?


graaaacias again!

Hola,

Si no me equivoco para mover la coordenada X es la siguiente dirección de memoria, osea vpoke &h1b01,X, y la siguiente es el nº de sprite que quieres mostrar, y la siguiente el color
, y en la siguiente empezarían las propiedades del siguiente sprite (joe, hay que ver lo que me repito xDD), da igual como le pases el valor al vpoke, lo puedes pasar, en decimal, en hexadecimal, en binario, total, el siempre lo entenderá en binario.

espero que te sirva de ayuda.

saludos,
gobblin

Exacto, como ya te han explicado:


Por que eso es lo que se guarda en esa dirección, las siguientes contienen lo que te ha explicado gobblin.


Explicado está. Y piensa en lo que comentas, ¿cual es el rango de valores de "x" y de "y"?, no te caben ambos en un solo byte (sólo 8 bits)


Eso es a gusto del consumidor, siempre, siempre, siempre puedes meter cualquier número en el formato que quieras (binario, octal, decimal o hexadecimal) y que normalmente te sea más sencillo de comprender.

Respecto a las direcciones usadas para los atributos de los sprites siguen esta secuencia:


Con esto seguro que ya te haces una idea de lo que modificar para mover o modificar un sprite... :)

pero yo pensaba que según esto:

  0000-17FF   Definicion de patrones
  1800-1AFF   Mapa de patrones
  1B00-1B7F   Atributos de los sprites
  2000-37FF   Definicion de los colores
  3800-3FFF   Definicion de los sprites

los mapas de patrones se almacenarian desde 1800 hasta 1AFF, sus atributos desde 1B00 hasta 1B7F... y asi con todo... :-\

y según esto:

1B00 - Coordenada Y del sprite 0
1B01 - Coordenada X del sprite 0
1B02 - Patrón del sprite 0
1B03 - Color del sprite 0
1B04 - Coordenada Y del sprite 1
1B05 - Coordenada X del sprite 1
1B06 - Patrón del sprite 1
1B07 - Color del sprite 1
1B08 - Coordenada Y del sprite 2

el patron del sprite 0 por ejemplo no se almacena en 3800???  ??? ni el color en 2000???  :'( ??? ::)
me pierdo aqui...

Es correcto, pero creo que te has liado un montón ya que la tabla de colores se refiere a los patrones, no a los sprites.


En 3800 se almacena la DEFINICIÓN del patrón 0, pero en el plano 0 de sprites no tiene por qué visualizarse el patrón 0. Tienes 64 patrones de sprites para definir, mientras que cada plano de sprites puede mostrar uno de esos patrones (32 al mismo tiempo). Ese es el valor que se almacena en el tercer byte de atributos para cada plano de sprites: un índice.

Saludos
--
Sph.

Exacto, relacionadas con los sprites sólo tenemos dos tablas: la primera contiene lo que ya has visto, 4 datos X 32 sprites simultaneos que se permiten en el MSX (128 bytes totales de longitud) y la segunda es la de definicion de los sprites, que es donde defines el aspecto que tendrá cada sprite.
Esta última tabla tiene 2K de tamaño y eso determina lo siguiente:

Si se usan sprites de 8x8 (8 bytes de tamaño cada sprite): 2048/8 = 256 sprites diferentes que pueden ser definidos.
Si se usan sprites de 16x16 (32 bytes de tamaño cada sprite): 2048/32 = 64 sprites diferentes que pueden ser definidos.

Como ya te ha dicho Sapphire, el valor que metes en su area de atributos es el número de sprite definido que quieres mostrar. ¡Ojo!, en caso de usar sprites de 16x16, el número de sprites será siempre un múltiplo de cuatro (0,4,8,12,etc.).

estoy en ello, muchas gracias a todos por vuestra paciencia...

bueno masters...

Sigo estudiando la estructura del vdp y los distintos modos de pantalla, ayer estuve dandole unas vueltas y me surgen nuevas dudas, asi que aqui van, espero que podais ayudarme:

En Screen 1 es posible utilizar sprites ademas de texto, esto me hace pensar que podria vpokear los caracteres de texto para definir "bloques" para los escenarios, pero ¿para los sprites? existe un lugar en la vram para almacenarlos en screen 1? o es la misma dirección que para screen 2?
me refiero al margen de la asignada al texto.

espero ansioso la respuesta ;D muchisimas gracias a todos!

Pues en principio es la misma; así que vas bien encaminado...  :)

que bien!
entonces si quisiera hacer un "escenario" podria diseñarlo con bloques imagino que ¿con print? ¿asi tal cual?
y despues almacenar mediante BASE los sprites y ¿colocarlos con PUT SPRITE?
¿QUEDAN ESTOS EN UN PLANO SUPERIOR A LOS CARACTERES?

Graaacias!

Si, puedes hacerlo con PRINT y si, quedan los Sprites en un plano superior :)

Aja, tal que así. Por cierto, no acabo de pillarte eso del BASE, supongo que te referirás a que con el BASE obtendrás la dirección en la que comienza la definición de sprites y luego VPOKEarás los datos de cada uno. Si es así, también es correcto...

madre  mia! entonces Screen 1 es una maravilla no?

bueno...  con respecto al color, se supone que permite un color frontal y uno de fondo por cada 8 bites, me imagino que esto será horizontalmente, ya que en el polka por ejemplo te permite color frontal y de fondo por cada linea horizontal de 8 bites, por lo que en un mismo caracter existen mas de un color frontal y uno de fondo...

¿esto es muy complicado de hacer? que cada caracter tenga mas de dos colores, me refiero. ¿cual seria la manera?

y luego cuando tienes digamos el escenario montado...

¿mediante que comandos o rutinas se dice por donde y por donde no va a poder pasar nuestro personaje?

gracias, un saludo!

Usar Screen 2. En Screen 1 es imposible y el modo mixto no funciona en todos los MSX1 por lo que si no vas a hacer nada específico de MSX2 olvídalo.

Saludos
--
SapphiRe

que olvide lo de mas de un color o que me olvide de screen 1?

que es el modo mixto?

Primera pregunta:

A ver, SCREEN 1 sólo permite 2 colores por 8 bytes (y no bites, como decías antes), es decir, por cada bloque ("tile" en inglés) de 64 bites; aunque, realmente, los dos colores de cada carácter se agrupan en 8... Que si das color de carácter blanco y fondo azul al carácter "A", eso quiere decir que se lo darás a "A", "B", "C", D", etc... Los grupos van de 8 en 8; que si cambias el color del uno de los caracteres de 64 a 72 (64+8) todos cambiarán. Recuerda: de 8 en 8; 8, 16, 24, 32, 40, 48, 56, 64, ...

xxxxxxxx 8 bites = byte
xxxxxxxx 8 bites = byte
xxxxxxxx 8 bites = byte
xxxxxxxx 8 bites = byte
xxxxxxxx 8 bites = byte
xxxxxxxx 8 bites = byte
xxxxxxxx 8 bites = byte
xxxxxxxx 8 bites = byte

En SCREEN 1, todo ese grupo de "x"s (8 bytes = 1 tile) tendría dos colores únicamente.

En SCREEN 2 cada línea de "x" tendría dos colores; por lo que podrías tener "16" colores (y digo 16 entre comillas porque realmente son 15, ya que el cero hace de transparente) en ese grupo (o "tile") de 64 "x".

Segunda pregunta:

En SCREEN1 redefines todos los caracteres una sola vez, es decir, tienes 256 caracteres (tiles) y los redefines una vez para toda la pantalla. Si escribes "Megaron"  ;D en la primera línea de la pantalla o en la última, las letras tendrán siempre los mismos gráficos.

En SCREEN 2 la pantalla se "divide" en tres tercios. Tienes que redefinir los caracteres 3 veces y los colores tres veces, una por cada carácter; vamos, una putada de mal gaste de tiempo (ciclos?, hercios?, t-states?, etc...)

De hecho, si tienes en cuenta que hay 256 caracteres en una pantalla de 32 caracteres por línea en SCREEN 2 (en SCREEN 2 el máximo es un "WIDTH 32") verás que tienes 8 líneas de 32 caracteres (32 x 8 = 256). Vamos, que 32 caracteres horizontalmente serán 32 (caracteres) x 8 (bites/pixels) = 256, lo que sería el eje X). Y, como hemos dicho, 8 caracteres verticalmente; 8 (caracteres) x 8 (bites/pixels) = 64. Es decir, un tercio de la ordenada Y (3 x 64 = 192).

Como puedes ver, SCREEN 2 tiene "3 veces" más trabajo que SCREEN 1,pero el modo mixto (por fin!!!!!!!! la respuesta a la pregunta!!!!!!!) permite redefinir los caracteres una sola vez, como SCREEN 1 y utilizarlos en toda la pantalla. Para ello ... Pero en fin, que de la MSXdev hay algunos, como el Gniffel, T-Virus, etc ...

Espero que programes cosas y que todo vaya "pa'lante".

oye muchisimas grácias por la información y felicidades por el T-VIRUS, está muy chulo  :).
lo que pasa que Sapphire comentaba que el modo mixto no funciona bien ¿no es asi?
un saludo!

Bueno, pues gracias... El T-Virus fue mi segundo juego en ensamblador, por lo que es un poco caca.

Sobre el modo mixto... pues sí, no es compatible en todos los MSX, tan sólo en un 99% (o un 99,9%  ;D ).

Ahora, que si lo puedes utilizar o no: Claro que sí. Hay quien dice que no se debería porque no guardaría una total compatibilidad con todos los modelos MSX y hay otros, como yo, que lo usarían sin dudarlo. El que tiene uno de esos modelos incompatibles seguramente tenga más modelos MSX que sí son compatibles con el modo mixto. Por cierto, cualquier MSX2 o superior sí es compatible con dicho modo.

y es posible utilizar ese modo mixto en basic?
porque la verdad, si es compatible al 99,9% ;) yo también soy de la opinión de utilizarlo...

podrias decirme como funciona por favor? creo que ademas tú que ya has hecho un juego así, me podrias ser de mucha ayuda para comprenderlo...

ya me dices, te lo agradeceria mucho, un saludo!

Pues, en ese caso te remito al tema en cuestión: Aquí (http://karoshi.msxgamesbox.com/index.php?topic=566.0)

Lee todos los mensajes para comprender mejor de qué va el tema y descárgate el archivo del primer mensaje.

Ya nos contarás...

En el caso de un programa en BASIC creo que en vez de meterse en líos de modos mixtos y demás es más útil lo siguiente:

10 screen 1:width32
20 SCREEN 2
30 poke &hfcaf,1

De esta manera estarás en screen 2 pero el basic "piensa" que estás en screen 1, por lo que podrás usar PRINTs (que son bastante rápidos). Deberás definir cada tile con vpokes en los tres bancos, eso si. En el concurso de juegos en BASIC que se hizo por aquí hace ya algún tiempo podras encontrar varios programas que usan esto.

un saludo.

ya, me encantaria poder ver los juegos que hicisteis, pero los enlaces no van...
viejo? ::)

Oye Dioniso, ¿y que hace exactamente esta linea?
 30 poke &hfcaf,1

gracias!

Justo lo que te comentaba Dioniso a continuación del ejemplo, hace que el ordenador aun estando en screen 2 se piense que está trabajando en screen 1; así se pueden utilizar los PRINT con carácteres multicolores.

ok. entonces,  esos caracteres multicolor que voy a poder usar con print, ¿cuantos colores podrán tener? ¿solo uno frontal y uno de fondo por cada caracter o mas de uno?

Gracias gente, un saludo!

2 colores por Byte, fondo y tinta. en un mismo caracter podras tener 16 colores

MAAMAA MMIAA!!!

Que bién! joder, muchisimas gracias!
ahora solo me falta un poco más de estudio del vdp y sus direcciones, estoy dandole, pero casi todo lo que tengo está en ingles y me cuesta un poco más (que ya es decir)
bueno, os seguire informando y pidiendo ayuda, GRACIAS!

De todas formas un consejillo, el problema que vas a tener con juegos que usen los carácteres multicolores es que vas a tener que cargar los patrones y los colores en la VRAM y eso respecto a si usas screen 1 puede significar hasta 6 veces más de tiempo. Te puedes imaginar que o defines pocos carácteres o el tiempo de espera usando BASIC va a ser un poco largo (y aburrido).
Usando código máquina no habría problema; pero si empiezas con BASIC, yo probaría primero con SC1; eso sí, experimenta con todos los modos, claro :)

¡¡ESO ESO!! ¡¡QUEREMOS MÁS JUEGOS EN SCREEN 0!! ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D

y yo toda la vida con el open "grp:"

También con el open"grp:" se pueden redefinir los caracteres ;), sin colores, claro...

y como es esa forma? podriais explicarla también por favore?
y cuales son las diferencias?

Si tecleas este programa:


Aparecerá en pantalla algo curioso... :). ¿Como podemos cambiar el juego de carácteres en SC2?, pues basta con cambiar antes de entrar al modo la dirección en la que se encuentra el juego de carácteres que va a usar, pokeando la nueva dirección en las variables de sistema $F920 y $F921.
Esto también es válido para los demás modos de pantalla, por lo que si modificamos con pokes esta dirección, al retornar al basic tendremos todo el juego de caracteres trastocado, para evitarlo no tendremos que olvidarnos de restaurar su valor original antes de salir.

Para demostrar esto podeis probar con:


¡...y la pantalla se os encriptara!

a ciegas, si volveis a teclear:


Volvereis al juego de caracteres normal.