Karoshi MSX Community

Estoy siguiendo el tutorial de iniciación a la programación. Estoy en el capitulo 6 de sprites. el tema es que tengo el sprite . defino 1 nada mas para probar. y lo saco en pantalla asi :
ld   hl,tblATRsSPRs   ; Tabla de los ATRs de los SPRs en ROM
ld   de,SPRATR   ; Destino la Sprite Atribute Table
ld   bc,(NUM_ATR*4)   ; Numero de Bytes
call   LDIRVM      ; 05Ch - BIOS - Copy block to VRAM, from memory

pero ahora quiero moverlo. al leer los 4 bytes de atributos y,x,nºsprite y color. como hago para que se vaya moviendo?
gráficamente aunque sea sin pulsar teclas por ejemplo de 0-255 en sentido vertical.
que tengo que borrarlo y volverlo a poner en la siguiente coordenada??

decidme como va para seguir avanzando. Gracias

Buenos dias in the morning!

Lo ideal es que reserves una zona de memoria donde estaran esos atributos para el sprite, en ram

Ld hl,tblATRsSPRs
Ld de,tblATRsSPRsRAM
Ld bc,4
Ldir

Asi solo tendras que tocar en esas direcciones cada vez que quieras modificar el sprites.
En cada interrupcion ejecutas el call ldirvm de antes, pero con ld hl,tblATRsSPRsRAM.

El sprite por hardware no hace falta que lo "borres" para moverlo. Con cambiar sus propiedades el vdp ya se encarga de todo.
Ni siquiera tienes que actualizar los valores cada vez. Yo lo hago como te he explicado porque asi te ahorras el estar pendiente del acceso a vram. De eso se encarga la interrupcion.

Otra forma de hacerlo seria con esa tabla intermedia en vram, y ejecutando el ldirvm solo cuando sepas que se ha modificado algun atributo: cuando se pulse el cursor y se mueva el sprite

Lo que te comenta assembler yo creo que es la forma más cómoda de hacerlo. Además, si a la hora de mover sprites siempre toqueteas en RAM y haces el volcado con LDIRVM tras el halt, te aseguras que no haya tearing, que sí que te podría pasar si movieras las coordenadas directamente en VRAM con WRTVRM (imagina por ejemplo que cambias la coordenada X de un sprite justo cuando está a medio pintar en la pantalla: lo verías mitad sin desplazar mitad desplazado).

Te pongo yo también algo de código de ejemplo:

; Tamaño de la tabla de atributos de sprites (en número de sprites)
   SPRATR_COUNT   equ 1
; Tamaño de la tabla de atributos de sprites (en bytes)
   SPRATR_SIZE      equ SPRATR_COUNT * 4 + 1 ; (+1 para albergar un SPAT_END)
; (...)

; En ROM:

INICIALIZACION:
   ld   hl, SPRATR_0
   ld   de, spratr_buffer
   ld   bc, SPRATR_SIZE
   ldir
; (...)

BUCLE:
   halt
; Vuleca el buffer de SPRATR utilizando la BIOS
   ld   hl, spratr_buffer
   ld   de, SPRATR
   ld   bc, SPRATR_SIZE
   call   LDIRVM
; (...)
   jr   BUCLE

; (...)

SPRATR_0:
   .db   96 -1, 128, 0, 15
   .db   SPAT_END

; En RAM:
spratr_buffer:
spratr_player:
spratr_player_xy:
spratr_player_y:
   .byte
spratr_player_x:
   .byte
spratr_player_pattern:
   .byte
spratr_player_color:
   .byte
; (...)
   .byte ; (para albergar un SPAT_END)


Como ves, declaro un montón de etiquetas aparentemente innecesarias, pero me gusta hacerlo así, y utilizar "la que corresponde" en cada caso, por dos razones:
- legibilidad: me parece más claro, por poner algún ejemplo, ld a, [spratr_player_x] que ld a, [spratr_player + 1]. O ld de, [spratr_player_xy] que ld de, [spratr_player_y], que se ve por la propia nomenclatura que estoy cargando el par de coordenadas (x,y) y no sólo la y
- flexibilidad: si el sprite del jugador pasa de ser el primero a ser el quinto, por poner un ejemplo, sólo tengo que cambiar el orden en el que están declaradas las variables y el resto del código seguirá funcionando tal cual.

Ya nos contarás! :D

gracias. lo pruebo y sigo avanzando. Lo siguiente supongo que serán las colisiones.

os cuento.

lo tengo rulando pero me he encontrado con algún problema.


la variable que creo es la tblATRsSPRsRAM
si le pongo esto no me va.
tblATRsSPRsRAM:    
.ds 4

ahora si lo pongo en c000 si me va
tblATRsSPRsRAM   equ  $c000

en vez de ds 4 que tengo que poner??

luego el sprite que numero horizontal o vertical me coge como ultimo.?? cero no, que es uno??  le he puesto que a 15 empieze otra vez o debo poner cp 0??

el retardo le he puesto un HALT , esta bien asi o habría otro diferente mas menos fino o efectivo??

os pongo el listado abreviado

ld   hl,SPR1      ; Origen = Bytes de nuestro sprite
   ld   de,SPRTBL   ; Destino = Sprite Pattern Table
   ld   bc,(NUM_SPR*32)   ; Numero de bytes
   call   LDIRVM      ; 05Ch - BIOS - Copy block to VRAM, from memory
   ld   hl,tblATRsSPRs   ; Tabla de los ATRs de los SPRs en RoM
   ld   de,tblATRsSPRsRAM   ; Destino la Sprite Atribute Table en ram
   ld   bc,(NUM_ATR*4)   ; Numero de Bytes
   ldir

; Show screen
          call    ENASCR
@@SHOW:
   or a
   ld   hl,tblATRsSPRsRAM   ; Tabla de los ATRs de los SPRs en ROM
   ld   de,SPRATR      ; Destino la Sprite Atribute Table
   ld   bc,(NUM_ATR*4)      ; Numero de Bytes
   call   LDIRVM         ; 05Ch - BIOS - Copy block to VRAM, from memory
   halt
   ld hl,[tblATRsSPRsRAM]
   dec h
   cp 15
   jr z,RESETX
   ld [tblATRsSPRsRAM],hl
   jp @@SHOW
RESETX:
   ld h,240
   ret

gracias

sigo avanzando. Como tengo el sprite de 16x16 pues se lo quito a los márgenes para que rebote

izda:
@@SHOW1:
   or a
   ld   hl,tblATRsSPRsRAM   ; Tabla de los ATRs de los SPRs en ROM
   ld   de,SPRATR      ; Destino la Sprite Atribute Table
   ld   bc,(NUM_ATR*4)      ; Numero de Bytes
   call   LDIRVM         ; 05Ch - BIOS - Copy block to VRAM, from memory
   halt
   ld hl,[tblATRsSPRsRAM]
   dec h
   ld a,h
   jp z,dcha
   ld [tblATRsSPRsRAM],hl
   jp @@SHOW1
dcha:
@@SHOW:
   or a
   ld   hl,tblATRsSPRsRAM   ; Tabla de los ATRs de los SPRs en ROM
   ld   de,SPRATR      ; Destino la Sprite Atribute Table
   ld   bc,(NUM_ATR*4)      ; Numero de Bytes
   call   LDIRVM         ; 05Ch - BIOS - Copy block to VRAM, from memoryhalt
   halt
   ld hl,[tblATRsSPRsRAM]
   inc h
   ld a,h
   cp 255-16
   jp z,izda
   ld [tblATRsSPRsRAM],hl
   jp @@SHOW

esta bien asi??

ahora probare a moverlo con los cursores

Buenas jrcp_kun,


Creo que debes estar utilizando el compilador asMSX y por defecto estarás haciendo una ROM.
Si es así, lo correcto sería algo así (según lo que entiendo que estás intentando hacer en tu ejemplo):


supongo que no te funciona porque estarás declarando la etiqueta en una zona de la ROM y no en la RAM.
Por eso cuando pones:
... si te funciona. Porque estás haciendo que la etiqueta tblATRsSPRsRAM indique la dirección $C000, en la que por defecto está la RAM.

Antes de declarar todas las variables, tablas, etc. que vayan en RAM debes indicar al compilador que quieres que se declaren en la página 3 ($C000) que por defecto contendrá la RAM.
Si miras el código de ejemplo que ha puesto TheNestruo:


... verás que indica que una parte va en la ROM y otra en la RAM.
Pues para la parte de la RAM debes asegurarte de ponerle ORG $C000 antes de empezar las declaraciones ... algo así:



En el caso concreto de tu ejemplo, deberías poner todo el código y tablas en ROM al principio del código,
después indicar que empieza la zona de la RAM (con el ORG $C000) y acabar con la declaración de todas
las variables (por el código que has puesto parece que ahora sólo tienes tblATRsSPRsRAM).

Creo que así debería funcionar ... espero que te sirva de ayuda.  :)

Llego tarde, pero bueno.

En la seccion de snipplets del foro tienes un ejemplo de como mover un sprite, para que le eches un vistazo,

http://karoshi.auic.es/index.php/topic,422.0.html (http://karoshi.auic.es/index.php/topic,422.0.html)

Gracias. Es codigo ese me ayuda a entender el tema.  No domino lo de la ram pero estoy aprendiendo.
A ver si depuro un poco el tema para ir enseñando mis logros de conocimiento e ir mejorandolo.
Ahora me podeis decir donde estudiar o mirar el tema colision de sprites?? Para ir avanzando en mis pruebas. Si podeis me poneis un codigo sencillito porque no soy muy profesional. Y ahora que me salgo del curso guiado me costara mas asimilar.

Tambien queria saber si el scroll vertical tipo konami cartucho. Lo hace dibujando la vram directamente o hace un sprite y lo mueve??
Gracias

Si se te ha "acabado" el tutorial de Pepe Vila, yo te recomendaría que le echaras un vistazo a lo siguiente:
- Karoshi Open Source: Classic Pong y Classic Minesweeper (en este mismo foro). Son juegos "pequeños", el código está muy bien estructurados, tiene una legibilidad envidiable y seguro que puedes aprender montones de historias de ahí (¡gracias Pitpan!).
- Jumping (el juego de Pepe Vila). Es un juego más grande, así que puede que te cueste un poco hacerte con su código de buenas a primeras. Pero está muy bien documentado y, al ser también de Pepe Vila, sigue el mismo estilo de código al que te han acostumbrado los tutoriales (¡gracias Pepe!).
No hace falta irse mucho más lejos para tener código didáctico y de calidad ;D

Yo hace tiempo andaba como tú y abrí un hilo llamado "rincón del novato en ensamblador" o algo así. Recuerdo que subí un mini-Pang! con el que, precisamente, había hecho pruebas de mover sprites, colisiones con los bordes y colisiones entre ellos. Seguramente sea el peor sitio para fijarse, porque era novato y no sabía muy bien lo que hacía... pero a lo mejor te vale.
Para el tema de colisiones entre sprites mira en la sección de snippets que me suena que hay un snippet de, precisamente, cómo mirar colisiones entre objetos (escrito por nanochess, si no recuerdo mal).

¡Ánimo!

Edit: no había visto tu última pregunta.
El scroll inicial de los cartuchos de Konami se hace escribiendo la tabla de nombres (es decir: son caracteres). No sé si con volcados vía LDIRVM o escribiendo posiciones concretas con WRTVRM.
Si utilizas Windows, prueba el emulador meisei (de hap, sólo MSX1) porque tiene un visor de VRAM que resulta ideal para ver cómo están hechos los juegos (y combinado con la pausa, el rebobinar, y el ralentizar/acelerar... es la caña para aprender cómo están hechas un montón de cosas)

el código del jumping no se donde esta. si me guiais asi puedo usarlo de guía con los otros

En la web de Dimension Z Games (la web de Pepe Vila) lo tienes:
http://www.dimensionzgames.com/?page_id=178&did=3