This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

collision collide

collision collide
by on (#227113)

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


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
Re: collision collide
by on (#227530)
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.
Re: collision collide
by on (#227566)
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 < return 0;
if( > 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.
Re: collision collide
by on (#228847)
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.

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.

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.