Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
 

Autor Hilo: ZX Frogger (Leído 80564 veces)

Bubu

  • T-600
  • Mensajes: 2 598
Estoy catando esto del SBC y me estoy liando entera:

Código: [Seleccionar]
; Comprobación HL > DE
CCF
SBC HL, DE
JP P, (si hl >= de)
JP M, (si hl <  de)

Pues nada, no me carbura. Si HL=10 y DE=10 me dice que HL<DE.
Además, si HL=65535 y DE=0 me dice también que HL<DE.
Vaya jaleo...
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

Bubu

  • T-600
  • Mensajes: 2 598
Bueno, ocurre que SBC es resta con signo, así que se comporta de diferente maneras para números mayores que 32767 y cosas así...
Pero a ver qué tal esto:

Código: [Seleccionar]
cp16bits:
 ; Subrutina que compara 2 números de 16 bits
 
 ; Entrada:
 ; HL: número1
 ; DE: número2
 
 ; Salida:
 ; flag NC si HL>=DE
 ; flag  C si HL< DE
 ; flag  Z si HL= DE
 
 ld a, h
 cp d
 ret nz
 ld a, l
 cp e
 ret

¿Funcionará?
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

Bubu

  • T-600
  • Mensajes: 2 598
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

araubi

  • Visitante

Bubu

  • T-600
  • Mensajes: 2 598
AJajjaajja, gracias, araubi. Y además, ya está hecha la subrutina para la gestión de récords. Si el jugador supera uno de los 5 récords, queda registrado en la tabla desplazando los récords inferiores hacia abajo, jiji. Eso sí, como sabéis, en el Frogger no se pone nombre, una pena, pero al ser esto un simulador 100% (o casi, jiji) fiel, pues tampoco le voy a poner lo del nombre.
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

Bubu

  • T-600
  • Mensajes: 2 598
Torpedos, una pregunta que me tiene janderizado (MetalBrain, si estás por aqui esto es para ti): ¿cómo se pué ampliar un sprite dibujado con SevenuP?

Al iniciar un sprite, le tengo que decir el tamaño, p.ej. 32x16. Me pongo a dibujarlo. Y mientras dibujo, me doy cuén de que me hace falta ampliarlo, 8 píxeles más de ancho. ¡¡Pues nu sé hacerlo!! Tengo que tirar el dibujo y volver a hacerlo...
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

doragasu

  • T-600
  • Mensajes: 2 314
  • Si no está roto, ¡yo lo arreglo!
    • Kernel Hacks
Veo que el problema ya está resuelto, así que esto es por molestar más que nada. Aún así, vamos con la matraca. En el Z80, el bit de más peso no tiene por qué usarse para el signo, así que lo que comentas de que tienes problemas con números mayores de 7FFFH no debería de ser así. Lo que comentas del bit de mayor peso para el signo, es para las restas en lenguaje C cuando usas tipos de datos con signo (por ejemplo int o char). Pero en lenguaje de ensamble, nada de eso. Con lo que sí que tienes que tener cuidadín es que antes de hacer la resta, tienes que asegurarte de que el bit de acarreo sea 0. Si no lo haces, al resultado de la resta, se le sustraerá un '1' adicional (es decir, que si haces 4 - 2 con el acarreo a 1, el resultado será 1 en lugar del valor correcto 2. Por último, tras hacer la resta, para saber qué número era mayor, el flag que tienes que mirar es el de acarreo.

Sobre qué opción es más rápida, si una resta de 16 bits o 2 comparaciones de 8, depende de la casuística. Seguramente sea más rápido una resta de 16 bits que 2 comparaciones de 8, pero se da la circunstancia de que probablemente la mayoría de las veces sólo necesites hacer una de las 2 comparaciones, y esto será más rápido que la resta de 16 bits.

Por otro lado, hacer subrutinas con tan poco código como el de la comparación que has puesto, funcionar funciona, pero es MUY LENTO, porque las instrucciones CALL y RET suelen consumir bastantes ciclos (no he mirado concretamente en el Z80, pero a menudo las instrucciones de salto son de las más costosas, sobretodo en arquitecturas con pipeline). Si tienes que hacer muchas comparaciones, yo lo desaconsejaría. Siempre y cuando una rutina tenga poco código, es siempre más óptimo convertirla en una macro.

Bubu

  • T-600
  • Mensajes: 2 598
Pues nu sé... el ejemplo que me hice no me funcionaba. Hacía algo tal que así:

Código: [Seleccionar]
CCF
SBC HL, DE

uséase, primero limpio el carry flag con CCF, y aluego hago la resta. Y pa números grandes se comportaba al contrario que pa números pequeños.

Respecto al tema de la lentitud con CALL, para el Frogger no me preocupa ya que sólo lo uso cuando el jugador finaliza la partida y hay que mirar si su puntuación se registra en la tabla de récords. Si lo tuviera que utilizar en mitad de un proceso continuo, entóns sí que haría la macro.

Gracias, doragasu, por tu observación.
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

Bubu

  • T-600
  • Mensajes: 2 598
Y a continuación, una chorraílla que hi encontrao por ahí, pero que responde a una pregunta que me hacen muchas veces, jiji:

Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

doragasu

  • T-600
  • Mensajes: 2 314
  • Si no está roto, ¡yo lo arreglo!
    • Kernel Hacks
Pues nu sé... el ejemplo que me hice no me funcionaba. Hacía algo tal que así:

Código: [Seleccionar]
CCF
SBC HL, DE

uséase, primero limpio el carry flag con CCF, y aluego hago la resta. Y pa números grandes se comportaba al contrario que pa números pequeños.

¡OJO!, CCF no pone a 0 el bit de acarreo, sino que lo complementa (usease, que lo invierte). Así que la secuencia correcta sería:

Código: [Seleccionar]
SCF
CCF
SBC HL, DE

O si nos ponemos un poco más creativos, podría ser más óptimo por ejemplo:

Código: [Seleccionar]
AND A
SBC HL, DE

Aparte de esto, la clave está en que después de hacer la resta, ¿cómo determinas cuál de los números es el mayor? Debería hacerse comparando con el flag de acarreo. Si está a 1, entonces DE es mayor que HL. Si está a 0, entonces HL es mayor, o bien ambos números son iguales.

Bubu

  • T-600
  • Mensajes: 2 598
¡¡¡Cooooñe, CCF invierte el flag¿?¿?¿!!!

AJjaJAjajaja, ¡¡yo creía que CCF sisnificaba Clear Carry Flag!! Ya me vale...
Pues ese era mi error, ajajajaJaJ, mandan coxones.
Ay... ay...
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

Bubu

  • T-600
  • Mensajes: 2 598
Torpedos, una duda pseudo paranoica: los coches de la 2ª fila empezando por abajo, ¿tienen un efesto de movimiento de las ruedas, o son totalmente estáticas?

[ Guests cannot view attachments ]

Lo digo porque jugando a la versión en la Atari 2600 me ha parecido ver cómo las rayitas blancas y rojas de las ruedas se alternaban, dando así la sensación de movimiento. En cambio en el MAME no lo noto...
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

RiCCo

  • T-500
  • Mensajes: 1 025
Mejor, tapate los ojos y haces como que no se mueven, porque si no, te las vas a ver put apuradas para programar ese movimiento :D

Bubu

  • T-600
  • Mensajes: 2 598
JAjaJAjAa, no, no va a ser tan difícil. Cada sprite lo tengo dibujado en memoria 8 veces (desplazado 1 pixel cada vez). Así las cosas, dibujaría un frame del coche, aluego otro frame con la rueda invertida, el siguiente frame con la rueda normal, el siguién con la rueda invertida, etc.

Pero me gustaría saber si esto ocurre o no en la placa original.
Si algo funciona...  ¡¡No lo toques!!
¡¡Pero ni de coña!!

RiCCo

  • T-500
  • Mensajes: 1 025
Tu tienes la placa original, no?? Pinchala y ves como va. De todas formas, mira que has jugado veces al frogger en mame, y nunca te has fijado en eso??

En la version de Atari 2600 programada por Sega si se ve movimiento
https://www.youtube.com/watch?v=YT0-HyznXdk

Pero en la version arcade no veo que se muevan
https://www.youtube.com/watch?v=u23kf-XBack

Hombre, si no supone mucho el ponerle movimiento, podrias hacerlo, aunque ya no seria como la original y puestos a modificar el original, podrias ponerle boton de pausa :D
última modificación: 27 Marzo 2013, 07:09:12 por RiCCo