Collision boxes if a character is only partly on screen

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Re: Collision boxes if a character is only partly on screen

Post by jeffythedragonslayer »

Valid point. Perhaps "Muratori convolution" would have been a better name for the "difference" operation I mentioned in Lemma 1.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Collision boxes if a character is only partly on screen

Post by rainwarrior »

I think it's just plain old convolution? I dunno what novelty you wanna credit Muratori with.

People do seem to use the term "Minkowski difference" this way for GJK intersection tests in a lot of places, though I couldn't find it in the originating GJK paper so I'm not sure where/when this usage started. Muratori acknowledges this definition of the term in his video, and then wanted to clarify that he thinks it might be better called a "Minkowski sum with a negative", which I kind of agree removes the ambiguity of the definition.

However in other domains (e.g. image processing erosion) the other definition is more useful. A lot of references seem to cite this 1950 journal article on the subject, which may have been the primary source of that usage.
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Re: Collision boxes if a character is only partly on screen

Post by jeffythedragonslayer »

Well, because I think too many things are called plain old convolution already. That wikipedia article says that word can refer to the function itself and the process for computing the function. :cry: Which probably isn't terrible when the context is clearly setup, maybe I just never read a good book on convolution.
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Collision boxes if a character is only partly on screen

Post by creaothceann »

dougeff wrote: Mon Jan 09, 2023 9:42 am Otherwise, you need a 16 bit collision check, which is slow.
tokumaru wrote: Mon Jan 09, 2023 10:55 am If you are using 8-bit coordinates and allowing objects to move off-screen, you may have problems bigger than just collisions, though. You simply can't accurately describe in 8 bits the position of an object with a range of motion of more than 256 pixels...
Assuming that collisions are rare, it'd make sense to do a rough test first to quickly rule out the objects that are definitely not colliding, then do a more thorough check for close objects. So imo it's fine to use >8-bit object coordinates, but only use the most significant byte for the first test.

Assuming it's a game that has many stationary objects, it might even make sense to keep these objects in lists depending on their position. E.g. if the player position is the player's top-left corner and it's a vertical level, you only need to go through the object list that corresponds to player.y SHR n (where n and the level height determine the number of lists). This might not matter for NES games though...
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Post Reply