collision collide

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
lapalourde75
Posts: 4
Joined: Fri Sep 21, 2018 4:00 pm

collision collide

Post by lapalourde75 » Sun Oct 07, 2018 3:29 pm

Bonjour

je cherche a réaliser une collision simple entre deux tiles
ainsi qu un bocage ou bornage du personnage
avec une explication la plus simple et precise
j ai deja un debut de jeu
un personnage qui se deplace un background
et des ennemi qui bougent

merci Thierry

Hello

I am looking for a simple collision between two tiles
as well as a grove or boundary of the character
with a simplest and most accurate explanation
I already have a start of the game
a character who moves a background
and moving enemies

thank you Thierry

User avatar
qbradq
Posts: 943
Joined: Wed Oct 15, 2008 11:50 am

Re: collision collide

Post by qbradq » Sun Oct 14, 2018 6:18 pm

This should be in the nesdev section i think.

This is a big topic. You can get by with simple rectangle intersection but it costs cpu. Basically you figure out the tiles your character occupies, the inspect your map data to see if those tiles are blocking.

diskoboy
Posts: 5
Joined: Wed Jul 11, 2018 10:31 am

Re: collision collide

Post by diskoboy » Mon Oct 15, 2018 10:02 pm

Pseudo code to check the intersection of two rectangles:

uchar Intersect(R1, R2){
if(R1.left > R2.right) return 0;
if(R1.right < R2.left) return 0;
if(R1.bottom < R2.top) return 0;
if(R1.top > R2.bottom) return 0;
return 1;
}

You can use it to check 2 objects collision. You need to take a different approach, if you want to check collisions with BG.

User avatar
PypeBros
Posts: 34
Joined: Sat Nov 10, 2018 7:35 am

Re: collision collide

Post by PypeBros » Tue Nov 13, 2018 11:21 am

Je peux peut-être te mettre sur la bonne voie

Basically, we would not code sprite-to-sprite collision the same way we do sprite-to-tile collision. The first one depends on test rectangles associated with sprite-based objects, where you use the intersection code below to see whether there is a match. Note that for 10 active objects, you may have up to 10*9 / 2 checks to do, which is already significant on a NES CPU. It isn't rare to see collisions with some objects being performed only every 2 or 3 frames, based on speeds and sizes.
Image

The sprite-to-map collision (to avoid getting into solid structures) will typically use a ground_properties[] array that has e.g. one entry per 16x16 block, possibly directly from ROM. When you're about to move a character to a new spot, you will scan through the entries covering the corresponding locations and decide whether you CANDO(walk) at that location or not.

Image
Depending on the gameplay, sometimes a single bit per cell is enough (solid / *-thru), sometimes you have multiple properties (walk-thru / jump-thru / swim-thru / ...)

The document relating development of M.C. Kids is golden in how to squeeze such tests to fit NES limited bandwidth.
Image - may the source be with you.

Post Reply