It is currently Tue Nov 13, 2018 6:16 pm

All times are UTC - 7 hours

Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: collision collide
PostPosted: Sun Oct 07, 2018 3:29 pm 

Joined: Fri Sep 21, 2018 4:00 pm
Posts: 4

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

 Post subject: Re: collision collide
PostPosted: Sun Oct 14, 2018 6:18 pm 
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 943
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.

 Post subject: Re: collision collide
PostPosted: Mon Oct 15, 2018 10:02 pm 

Joined: Wed Jul 11, 2018 10:31 am
Posts: 1
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.

 Post subject: Re: collision collide
PostPosted: Tue Nov 13, 2018 11:21 am 
User avatar

Joined: Sat Nov 10, 2018 7:35 am
Posts: 9
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.

Image - may the source be with you.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 7 hours

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group