• entries
271
969
• views
189764

# Fixed (hopefully) part II

105 views

Hey everyone!

Well, I thought I had fixed that damn bug, and for awhile, it seemed that I did, but it would seem all I did was make it happen less often. While the bug has been gone from my computer since yesterday night, I found it was crashing often on the school computers I was using today, so I had to sit down and look at the code for hours, and I may have found the problem(or one of them [grin])

The Bug (prehaps)
Well, all the objects in A22 are stored in a STL vector(yes I know, lists are better for insertion/deletion, blah blah blah[wink]) Anyways, whenever an object's readytodie variable is set to true, the engine deletes the allocated memory, and removes the object via the erase() function, as seen below:

for(int i = 0; i < activeobjects.size(); i++){if(activeobjects->readytodie ){delete activeobjects;activeobjects.erase(activeobjects.begin() + i);}}

Well, to my understanding, when using the erase() function, all the object stored past the removed object have their index's moved down by one, and the vector is resized. Anyways, what I think is happening(correct me if this makes no sense, I don't claim to be an STL expert...) Is that when an object is deleted, all they other objects move down to fill in that slot, but the index ("i") remains pointing at the same "slot" in the vector, which has been filled by a new object, but when the for loop "loops", the index is incremented, and that object's removal check is skipped over, resulting in an error... for some reason. So now whenever something is erased, I decrement the index by one, and set it to the new objects index. I'm really stretching here, but it seems to be working for other computers now, so maybe that was it, but who's to know? Anyways, if anyone sees a flaw in my logic, let me know, because I'm pretty clueless when it comes to this stuff.

School
As you may have read in Mark's journal, we both started our last year of high school this Wednesday, and as such, we both will be having less time to work on Angels 22. OTOH, we have a "gifted" computer class we're both in, so we'll be able to work together in there, which should help out alot.

Angels 22 Demo
Okay, here's a new, hopefully more bugless, version of Angels 22. Nothing has been added, but hopefully it won't crash as much anymore, so if anyone who has been having problems with it could try it out, and see if it still crashes, or shows those wierd grey overlays, that would be great.

Angels 22 *fixed-ish*

Well, hopefully I'll have a screeny of some new stuff soon, Mark and I have been planning some missions out, so once we have one of those finished, we should be able to show you guys how the actual missions will play (the current demo has a fraction of the total gameplay we have so far). Anyways, thanks for reading, Peace Out!

Played really well and the gray flickering was gone. The only problem I had was it would give me errors when I was shooting some buildings that on their last stage (happened twice and I was only shooting one missle both times.)

I'm not sure if landing on the strip was possible before, but that's cool and very handy!

To tell you the truth, I'd use a map with an integer key instead of a vector. Then you don't have to change the index when you remove anything.

Keep up the good work!

This is the code I use to do similar in an STL container. This is basically the same as the fixed version of your's:
void Events::RemoveEventsBefore(
double a_Time
)
{
Events::iterator l_IT;
for(l_IT = begin(); l_IT != end();) {
Event* l_Event = *l_IT;
if(l_Event->GetTime() < a_Time) {
Event* l_Event = *l_IT;
l_IT = erase(l_IT);
delete l_Event;
} else {
l_IT++;
}
}
}



The erase function returns an iterator pointing to the next position to check (or end() if there are no more). I don't think my code is a particularly good way of doing it to be honest as it's not very clear.

If you used smart pointers you could use the remove_if function (it's a non-member function, not part of vector) as then the objects would automatically be deleted.

For speed you could write your own removal function. Instead of calling erase, delete the object at that address, move the last object to the empty slot and then erase the final slot. This will reduce the amount of memory operations occuring. The only downside is that it will reorder your objects but that may not be a problem.

It crashed twice and both times it was when I was destroying the buildings after finishing the level. I love how you get ammo and health when you land on the runway!

Impressive. One thing I did notice was that the dot on the radar respresenting the player actually goes outside of the GUI 'frame' when you exceed a certain altitude.

Is it just me, or does it smell unwise to modify the contents (ie. removing an item) of a container WHILE you're iterating through that container? Or maybe it's just those C# ForEach warnings going off in my head. Oh, well. If problems still persist, try implementing a 'dead list' that gets all to-be-killed entities added to it, and then deletes them from the main entity list after it's done iterating over it.

Good luck!

Oomph.. Yeah, its still there.. I ran sacked everything and was just simply flying around firing off some MK82's.

Hopedagger hit the nail on the head... in fact removing an element will invalidate any iterators you already have and that's why the function passes back a new iterator for you. I've always gone for flags to say when something is dead and then removed it in a loop that's guaranteed to not invalidate any iterators at a lower level on the call stack.

A little bit of code from something I wrote, note I use pointers in the containers hence the explicit delete.

	itEnt = mPlayerEnts.begin();
while ( itEnt != mPlayerEnts.end() )
{
if ((*itEnt)->mAlive)
{

(*itEnt)->Update(elapsedTime);
++itEnt;
}
else
{
delete (*itEnt);
itEnt = mPlayerEnts.erase(itEnt);
}
}



## Create an account

Register a new account