I've got a problem. Check the edit.
(I know that the activeObjectsCount isn't being decremented so it'll just increase to beyond 255 and cause out of bounds.)
I've tried a couple of different ways to deal with the pointers in the activeObjects array.
I want to do it this way because having a list of pointers referencing the active objects in the objectArray eliminates the need to loop through the entire objectArray.
I clearly don't understand enough about pointers and / or arrays. I've tried to delete the element, I've found that doesn't make sense since it's not a dynamic array.
Could I do this with an array of Obj pointers? I've tried making a dynamic array of object pointers but the compiler kept complaining at me in every way I tried to do it. except if I did:
Obj *activeObjects; activeObjects = new Obj;
but that doesn't make sense to me. it points at directly to a new object not it's address? What?
I do realize that I could do this with one of the standard containers, but I want to do it with arrays for educational reasons.
Also, I'm sorry if I explained it badly. It's 9 am and I haven't slept yet, and I'm sick on top of that.
Edit: After some more research, it seems like what I want to do is impossible? I'd have to create a new pointer array and copy the elements every time I wanted to add or remove elements? Guess I've got to switch to lists then.
is what I'm doing here terribly expensive / ineffective? cause I was running debug with 1 std::cout in one of the for loops and the fps was roughly 5.
Removing the std::cout fixed the fps, but I'm still concerned. Switching transforms like that, does that cost a lot? Also, my rectangles are scaling but not rotating? I know all of them are in use, so the second list is not needed and is slowing down my program but only a small part of them will be in use later on.
(stl) Lists are quite slow, but they shouldn't drop your fps that low.
Arrays are the fastest solution, albeit not the most dynamic.
To create an array of pointers this is the syntax you should use:
Obj **activeObjects; activeObjects = newObj*[length];
An easy and fast way to remove an object using a collection like a vector is by moving the element to the back and then removing the last element.
This won't preserve the order, but it's quite fast. It can even be done using a simple array, although it won't automatically handle resizing in case the container is too small.
edit: fixed grammar errors, in both my post and code.
I tried using an array of pointers but I just couldn't get it to work.
The length is varying, it could be 40 or over 200 and I don't know what to do with all the pointers pointing to inactive objects. I don't want to loop through them, that's what I'm trying to prevent.
I tried removing elements from the array of pointers but that crashed and gave me errors no matter what I tried. All my searching has given me that I have to create a new array with the elements I want and get rid of the old one. (Is that perhaps how vectors work?)
Rather than starting a thread with a big[, ugly] code block you should first describe what you're trying to do, why, and what the thread is about (i.e., what you want to discuss or need help with).
Second, you should be try to be disciplined with your code. Every space, tab, brace or semi-colon should be intentional. We don't want to read through code that jumps around like this:
Obj objectArray[255]; Obj *activeObjects[255]; if(doLogic && al_is_event_queue_empty(event_queue)){ doLogic = false; if(Input::mouse[1])
If you're concerned about performance then something like this doesn't make sense:
You are needlessly invoking std::list::back repeatedly. It makes better sense to create the object first and push it into the list afterward.
That said, taking the address of an std::list element is also probably wrong and dangerous. If you want pointers to things then you need to be in control of the pointers. You could use operator new to allocate your objects and store their pointers in your collections instead. You should use smart pointers to help with that to avoid memory leaks or ugly and error-prone cleanup code.
Yes, the STL containers allocate new buffers when they run out of space. It's good for you to practice this yourself for educational purposes, but should encapsulate the functionality into an object, just as the STL does. You don't want to be manually manipulating these low-level arrays everywhere. You want to put that in a single place and reuse it. It's hard to get right and you only want to have to get it right one time.
It's not really clear what you call "inactive". If things may move from one state to the other, an efficient method would be to manage two different std:lists of pointers : a list of actives, and a list of inactives.
When something becomes inactive you remove it from the first list (without deleting the actual object), and add it to the other one. The first list loses a pointer, the second list gains a pointer. The value of these pointers is the same : the address in memory of the actual object, which doesn't change in the process.
When the object is no longer needed at all, you delete it and remove it from whichever list it's in.
The value of these pointers is the same : the address in memory of the actual object, which doesn't change in the process.
If you allocate it on the heap with new.
Rather than starting a thread with a big[, ugly] code block you should first describe what you're trying to do, why, and what the thread is about (i.e., what you want to discuss or need help with).
You're right, I'm sorry. The whole post ended up being a huge mess.
My code isn't like that, I just copied some of the stuff I thought relevant. I should have spent some time making it look less messy. Again, I'm sorry.
You are needlessly invoking std::list::back repeatedly. It makes better sense to create the object first and push it into the list afterward.
Oh, I thought since back returns an address and using that to mess with the element in the list wouldn't be that bad.
It's not really clear what you call "inactive".
Oh, uhm what I mean is that when the lifespan integer reaches 0 it should no longer do anything. It should not be pointed to in the active list and when more objects are needed it can use the objects that has a lifespan of 0 or less.
I really didn't have a problem with the array of elements since it's constant. But the array of pointers pointing to the various elements in the object array. When those objects have their lifetime set to 0 they are ready to be used again and should no longer be pointed to until they are used again.
I couldn't find out what to do with the pointers pointing to the elements with a lifespan of 0 or less. I want to remove them from the array, shrinking the array by one and when more objects are created they will have a pointer pointing to them.
An integer will count how many are active and I will only have to loop through the active ones instead of going through the entire list of objects and checking which ones have a lifespan of 0 or less.
I hope I've made myself clearer.
Perhaps a better question for you guys would be: How would you manage an array containing pointers to objects within a different array, how can I add or remove elements from the array containing the pointers.
You need to learn the STL, and
you need to learn C++,
and about dynamic memory.
Use either a std::list, or a std::vector. Both will work fairly well for your purposes here. Use erase(iterator) or swap pointers for a vector and pop_back().
Oh, I thought since back returns an address and using that to mess with the element in the list wouldn't be that bad.
In practice the performance penalty is probably negligible, though only a profiler can really identify whether it's a problem. Performance isn't the main reason to change it. It's just a bonus. The main reason is readability and maintainability. It's much easier to read code that does only what it needs to do. If you see the same expression repeated over and over again then it's probably a good sign that you should refactor the code.
When those objects have their lifetime set to 0 they are ready to be used again and should no longer be pointed to until they are used again.
"No longer be pointed to" is basically the definition of a memory leak. At least with heap-allocated memory, and you don't want to use pointers to stack-allocated memory unless you're passing it deeper into the call stack. So you may need to clarify what you mean here.
I couldn't find out what to do with the pointers pointing to the elements with a lifespan of 0 or less. I want to remove them from the array, shrinking the array by one and when more objects are created they will have a pointer pointing to them.
An integer will count how many are active and I will only have to loop through the active ones instead of going through the entire list of objects and checking which ones have a lifespan of 0 or less.
I hope I've made myself clearer.
Perhaps a better question for you guys would be: How would you manage an array containing pointers to objects within a different array, how can I add or remove elements from the array containing the pointers.
Arrays can't really be resized. An array is just a contiguous sequence of memory, and typically all you can do is ask for a new contiguous sequence of memory. So you basically have two options: reallocate and copy the array whenever the number of elements changes (an expensive operation) or just use an is_active method to skip over inactive objects when you process the array. An alternative option is to move inactive objects to the end of the array and keep a count of active objects. That way you know that you only need to process the first num_active elements and can skip the tail. Which one is best will be context specific.
Actually, bamccaig, in C, arrays could be resized, if you use realloc. It's not guaranteed, but many implementations of realloc may just make the reserved area your pointer points to bigger if that is possible.
A for the original poster: Why not learn C first before learning C++?
You'll only have to learn about pointers and malloc realloc/calloc and free then.
Some untested code to show the idea: