Estoy tratando de crear un juego de serpientes en un Xilinx Artix7 FPGA, y una de las cosas que quiero comprobar es si la serpiente ha chocado consigo misma. Necesito realizar esta comprobación entre las actualizaciones del juego para saber en la próxima actualización si el juego ha finalizado.
La serpiente en mi juego está formada por segmentos discretos, así que para verificar si la serpiente ha chocado consigo misma, solo verifico si el primer segmento (la cabeza) se superpone con el segundo, el tercero, el cuarto, etc. . Mi plan es hacer esto secuencialmente con un reloj mucho más rápido que el reloj del juego.
La cosa es que creo que solo puedo comprobar si la cabeza colisiona con cada segmento otro . Sin embargo, ¿hay realmente alguna ventaja ganada por esta "optimización"?
El juego, si se ejecuta a unos 50 FPS, tendría un período de actualización de 20 ms. El reloj que soporta la placa Basys3 es 100 Mhz, que es un período de 10 ns . Esto significa que en el intervalo entre las actualizaciones para el juego, puedo pasar por 2 segmentos millones , que es mucho más de lo que la serpiente podría tener. Dado que el juego realmente no necesita ser más rápido que 50 FPS, encontrar la respuesta dos veces más rápido no hace nada porque lo único que haría es simplemente sentarme y esperar la próxima actualización.
Otra cosa en la que pensé era que tal vez podría configurar el comando create_clock en mi archivo XDC (restricciones) para que sea más lento, pero ¿hay alguna ventaja al hacerlo? ¿Consume menos energía o algo así?
Lo último en lo que podría pensar es si utilizara una versión combinatoria de la verificación de colisiones como tal
(head == seg1) || (head == seg 2) || (head == seg3) || ... || (head == segN)
Con mi optimización, solo tomaría la mitad de hardware, pero aún más que la versión secuencial. Ya que es combinatoria, la respuesta estaría disponible casi instantáneamente, pero nuevamente, ya que tengo tiempo para matar, tampoco veo una ventaja allí.
¿Es esta una optimización inútil?