Collision boxes if a character is only partly on screen
Moderator: Moderators
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
Re: Collision boxes if a character is only partly on screen
Valid point. Perhaps "Muratori convolution" would have been a better name for the "difference" operation I mentioned in Lemma 1.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Collision boxes if a character is only partly on screen
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.
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.
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
Re: Collision boxes if a character is only partly on screen
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. Which probably isn't terrible when the context is clearly setup, maybe I just never read a good book on convolution.
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: Collision boxes if a character is only partly on screen
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.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 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
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10