Array curve #1724
Array curve #1724
Conversation
3ea0f4a to
4c2b2f3
Compare
|
is there any chance array curve should be an array of base curves instead of an array of key frame containers? |
4c2b2f3 to
0b01820
Compare
The base curves would have a bunch of duplicate info that we would want to avoid, e.g. they would all have shared pointer to the event loop, their own IDs, and ID strings. Basically, the curve array container should only have this information once. |
Then the IDs wouldn't be unique which would be a problem for the event system. Since all curves are event entities, duplicating the information would either lead to all contained curves being updated or worse, only one curve being tracked by the event loop. It would also be a waste of space, since we have to store a bunch of redundant data which is what we want to avoid with a dedicated Array class. Also, |
0b01820 to
1d653cd
Compare
f68ec30 to
0e637b0
Compare
|
Some additional remarks:
|
alright, currently implementing the changes, really appreciate all the feedback. |
22d7740 to
dda1518
Compare
heinezen
left a comment
There was a problem hiding this comment.
I think I found everything I wanted to comment on :D
libopenage/curve/array.h
Outdated
| } | ||
|
|
||
| // Array::Iterator is used to iterate over KeyframeContainers contained in a curve at a given time. | ||
| class Iterator { |
There was a problem hiding this comment.
Is there a reason why this class doesn't implement CurveIterator and uses a different strategy for iterating?
There was a problem hiding this comment.
One reason would be that std::_Array_const_iterator doesn't have base as a member, which is referred to in iterator.h line:95, and thus unable to inherit from CurveIterator
But to be honest when the choice was made it was arbitrary.
0694bd0 to
7cb1da0
Compare
|
I'm going to do a few tests today and then see if we can merge :) |
| return this->containers.at(index).get(frame_index).make_pair(); | ||
|
|
||
| // update the hint | ||
| this->last_elements[index] = frame_index; |
There was a problem hiding this comment.
out of interest what was wrong with the origonal implementation?
There was a problem hiding this comment.
Nothing in particular. Your code still worked and was fine, in case you wondered about that.
The main motvation for this change was to change the type of the local variable hint from size_t to auto because I got some compiler hints about that. I think these were caused by me changing the element type in the last_elements to be KeyframeContainer<T>::elem_ptr so that it's more explicit. However, that means that the compiler has to deduce more layers of typedefs and check if they are compatible to size_t and that can apparently be a bit wonky when using the member in code, especially in templates. I could have declared hint as KeyframeContainer<T>::elem_ptr too, but changing the type to auto lets the compiler do this automatically and is much shorter to write.
|
I added a few more tests and fixed the docs. |
|
Thanks again for tackling this one :) |
No worries, thanks for the help. |
Closes #1678