0
\$\begingroup\$

I am writing a game in a c++ console application. I would like to detect whether or not there is a collision between two objects, and displace them accordingly. All sprites are simply strings drawn on screen (Ex. a sprite with x 5, y 5, width 3, height 3 and the image "XXXXOXXXX" would create a 3-by-3 box of X's with a O in the middle). All objects have a x, y, length, and width which can aid in looking for potential collisions; however I would like to look at the actual string for finer collision detection. I am relatively new to the concept of continuous collision detection and I am having trouble finding the answer via Google. Does anybody know how I would go about doing this? Thanks in advance.

\$\endgroup\$
8
  • \$\begingroup\$ Is this a console application in the sense that it is rendered through characters printed to the console? \$\endgroup\$
    – Stephan
    Commented Nov 28, 2017 at 15:58
  • \$\begingroup\$ @Stephan yes, Im using conio's gotoxy and cout to draw ascii art sprites to the console \$\endgroup\$ Commented Nov 28, 2017 at 19:11
  • \$\begingroup\$ Is your physics still real under the hood, or is everything based on the row and character position in the console? \$\endgroup\$
    – Stephan
    Commented Nov 28, 2017 at 19:15
  • \$\begingroup\$ @Stephan there is only direction and speed at the moment \$\endgroup\$ Commented Nov 28, 2017 at 19:36
  • \$\begingroup\$ Is it in xy coordinates with a character position resolution? \$\endgroup\$
    – Stephan
    Commented Nov 28, 2017 at 19:37

2 Answers 2

0
\$\begingroup\$

Collision Detection is essentially looking for intersections of lines defined by points. A square bounding box consists of 4 points, the lines between being checked for intersection of lines between other pairs of collision points.

The only conceptual difference between a traditional bounding box and pixel-perfect bounding boxes, is that traditional BB's have fewer collision edges to check.

Pixel perfect boxes effectively have a new point for every non-transparent edge pixel. Some efficiency can be gained by eliminating bounding points that are co-linear and non-terminating(not on the ends of the line) with other points, which reduces the number of line segments that must be checked for intersection. If for some reason such an efficiency doesn't happen, there is no difference in "pixel-perfect" and simply iterating over the tiles that will occupy previously unoccupied space.

In your case, since you're "rendering" text in a console window, worrying about this is over complicating things. Maintain a list of characters that are considered "blocking", and when you move your 3x3 object, you only have to check the 3 cells immediately adjacent in the horizontal or vertical directions for "blocking characters". In the case of a diagonal movement, you have to check the 5 space that will be newly occupied by your 3x3 object. If part of your 3x3 is considered "non-blocking" or not part of your bounding box, simply ignore the cell that it will move into when doing your checks. If any of the tiles have a blocking character, you interrupt the move and don't change the position of the object.

TL;DR In a nutshell, you only have to check the spaces in the world that will be occupied against the corresponding characters in your object that will occupy them. So long as none "collide," move your object and rerender.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ That makes a lot of sense, my only problem is i plan to add smaller sprites (Ex. 1x1) That move more than one space at a time, so I want to avoid those collisions going undetected with one another. However, I am now realizing that perhaps I could move it one space then check, and repeat based on the objects speed. Is this a commonly used method? (And thanks for the description on pixel-perfect boxes) \$\endgroup\$ Commented Nov 30, 2017 at 16:04
  • \$\begingroup\$ You're spot on.Unless you don't want it to move if it can't move the full distance. In which case you want to check all the spaces between before you move at all. I wrote my answer under the assumption you'd only move one space at a time. \$\endgroup\$
    – Stephan
    Commented Nov 30, 2017 at 16:06
  • 1
    \$\begingroup\$ that makes sense, I think i have a good idea of what to do in my head now... Thanks for the help :) \$\endgroup\$ Commented Nov 30, 2017 at 16:18
0
\$\begingroup\$

For a school assignment we made a class to wrap up the characters in, essentially creating bitmaps where instead of coloured pixels we used characters.

This greatly simplified things such as drawing stuff at the right place etc, and should also help you with your collision detection issues.

By viewing the characters as pixels your engine can use any techniques used in 2D games. This way you can effectively ignore that you are working with ascii-art instead of sprites.

\$\endgroup\$
1
  • \$\begingroup\$ that's essentially what I'm doing, my problem is I don't understand how to check the position between the individual "pixels". My mentioning of bounding boxes is just so I can split up the collision check into two stages to save runtime \$\endgroup\$ Commented Nov 30, 2017 at 13:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .