3 ms·
Just skimmed, but isn't collision detection in sprite hw usually incorporated in the overlay logic instead of just checking coordinates? If you have round sprit
by l33tman 6y ago
Just skimmed, but isn't collision detection in sprite hw usually incorporated in the overlay logic instead of just checking coordinates? If you have round sprites you don't want them to collide as rectangular shapes. The logic of collisions at the pixel level is more intuitive as well.
Did you look at the sprite implementation in the various C64 and Amiga FPGA re-implementations? I haven't, I'm a bit curious on how they do the pixel merging (the trivial implementation I think is a prioritized 1-8 mux controlled by some priority selection logic)
- WillFlux 6y agoIf you're referring to the original URL https://projectf.io/posts/fpga-graphics/ https://projectf.io/posts/fpga-graphics/, then there are no sprites involved. We define a square mathematically, then check whether it has collided with the edge of the screen. It's a quick way to produce animated graphics with minimal knowledge and code. The second post on Pong https://projectf.io/posts/fpga-pong/ https://projectf.io/posts/fpga-pong/ includes collision checking between the ball and paddles at the drawing level. I plan to cover full sprite collisions and overlap in a future post. In the meantime, there is a post that covers sprites with transparency: https://projectf.io/posts/hardware-sprites/ https://projectf.io/posts/hardware-sprites/ I haven’t looked at the FPGA re-implementations, but I am familiar with Amiga hardware: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node00AE.html http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_gui...