ID- OMG Artifact blog 2

I have been working on ID for colliders. The thing is, whenever an enemy is deleted, its collider will need to be deleted as well. Because I have used containers of colliders that check each other for overlaps, I was thinking that there must be some way to identify them so that the correct collider is deleted. What I have done so far is I have managed to get rid of the correct collider in my testing project. But it was not all that straight forward a job as I had hoped it would be.

The containers I use are called vectors. They can keep multiple data types in one place, simply put. For example, I could have a bunch of string objects in them which would mean I could keep a bunch of words or even sentences or simple letters saved in one vector.

I have pointers to collider objects in them. This was actually a part of the problem.

I will do a short description of pointers with illustrations to help explain the problems I ran into.

A pointer is a data type that points to the memory location of an object. Using a pointer you can access the object’s value indirectly trough its location in the memory. There are two main types of memory used when programming, at least in c++. They are called the Stack memory and the Heap memory. The stack keep objects temporarily and remove them automatically when you exit a so called scope. A scope is between two of these brackets: { } any object created inside those two will be deleted when you come to the second bracket. They are in every function at least once. But if you want something to exist even outside the brackets you can use pointers to set objects to the heap. There they will survive outside of the brackets, and you can access them in other parts of your program. The thing is that you will have to delete them yourself when you don’t need them.

Simple illustration:
pointer

Back to the collision identification again. I made the colliders “know” which shape they belonged to by giving them “enums”. Simply put, an enum is a number expressed with a word so that for example the collider belonging to a player is branded “PLAYER” instead of 1, or 0. much easier to read the code this way.

Before every frame is drawn (frames are like pieces of paper with different drawings on them and when you flick them over at a high speed you can make the pictures together look like moving objects such as a stick man running) and if a shape has moved by user input for example, the collider’s position has to update to the shape’s position making it follow the shape around. I used the collider’s directly to do this, instead of using them trough their vector container. And when a PLAYER and an ENEMY collider collided I removed the ENEMY collider that had been involved in the collision from inside the vector container. It was deleted properly but when it was time to draw the next frame the program crashed! I just could not get it at first. I tried 4 different ways to delete the collider from the vector, all of them perfectly fine really, but it just crashed every time. I added a condition to the position update that stated that only if the pointer to the collider was not pointing at nothing, it would update, but no. It crashed.

I finally had an idea, why don’t I use the vector to update the position? I kept the condition, only now I said only update if this particular element of the vector is not pointing at nothing. And then it worked perfectly fine. No crash and the collider I wanted to remove is gone and all other colliders are colliding as they should.

So why on earth did this happen? Well I have a theory: When I put the pointers to the colliders into the vector, I make sort of a copy of the pointers so that there are other pointers to the same memory, and when I delete the element of the vector, I destroy what ever it is the pointer points to and I set this pointer to point to nothing. But then there is still this first pointer to a collider, the one I made before putting it inside the vector still pointing at this “empty” place in the memory. This is called a “dangling pointer” and will make programs crash when it is used. The condition that only update when pointing at nothing (as it first was, before I changed it to updating using the vector) was false because it was still pointing at the same memory address, except now there was no collider there, and tried to update nothings position to the shape’s position. If this is the case, no wonder it crashed.

Here is an attempt to illustrate a dangling pointer:
DanglingPointer
The pointer below is the original pointer trying to use the deleted object. The pointer on top is the one in the vector that has deleted the object and been set to point to nothing.

Now I have to make this work in the real project, and so far I have managed to do so as long as there is only one enemy. If there are more enemies, a similar problem appears causing program crash. I am still working on it. We have managed to make a working alpha version despite this. It is actually starting to look like a game now. More art work is used.

phisy

2 thoughts on “ID- OMG Artifact blog 2

  1. You have given a rather foggy explanation of what you did and you have only barely given any explanation on how you did it and your reasoning behind what you did. Don’t take me wrong, it is an extremely interesting blog post, I’m just not sure what you did or why.
    The illustrations are interesting as well, but the last one tells me nothing of what you did. It would be nicer and easier for me to understand your code if I got an image of it.
    The post is quite nice for someone new to programming to read to get a bit of information on pointers and memory allocation(although you do not mention it more than in passing). You did explain a bit of what you did before and give a reason to why it might not have worked which can be really helpful for someone who doesn’t know that much and reads your post.
    There is also at least one grammatical error in the post, at the end you write “causing program crash” but it should be “causing a program crash”. So do keep in mind to try and avoid such things. There might be more but I usually manage to miss such things when I read a text(my brain automatically correct it and I just don’t notice unless I look at it without reading it).

  2. Very insightful post (even for me as a graphical artist)
    You explained your thoughts around the problem very well.

    As gustafte above said, your explanation of what you’ve done, how you did it and why is a little bit undefined.
    But I think your post only needs a bit of rephrasing.
    I can see why, how and what but right now you’ve explained it as “this happened”.
    Maybe if you use phrases such as “I decided to use a pointer because of – [explanation of pointer and what the good sides of having a pointer here]”
    This because in our game [why pointers are good in this game]

    I hope you understand what I mean.
    If you don’t, talk to me about it when we meet 🙂

Leave a comment