View previous topic :: View next topic |
Author |
Message |
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Sat Oct 14, 2006 11:55 am Post subject: |
|
|
clay: The docs are here http://www.digitalmars.com/d/statement.html#foreach .
Phr00t: This iteration is as efficient as the current one, since we're basically still doing the same thing.
While it is doable to make it possible to iterate through any combination of our lists, it is unfortunately not trivial and probably hard to get in a 'clean' way, syntactically.
I'm still in favour of allowing
Code: | foreach(ship; object_holders.ships)
... |
and similar to make things as simple as possible.
-- edit --
Actually, it's not as difficult as I expected!
Code: | class ObjectsHolder
{
class foreach_adaptor
{
this(int choice) { ... }
int opApply(...) { /* iterate as indicated by 'choice' */ }
}
foreach_adaptor iterate_over(int choice)
{ return new foreach_adaptor(choice); }
} |
Last edited by ChristianK on Sat Oct 14, 2006 1:48 pm; edited 1 time in total |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Phr00t
Joined: 03 Mar 2006 Posts: 203
|
Posted: Sat Oct 14, 2006 12:26 pm Post subject: |
|
|
OK --
If all these holder classes, opApply functions etc. are just trying to fix draw order, I don't think it is worth changing the current system. The only draw order bug that still exists is when objects are created for quests. This can be fixed by making quest objects added to the beggining of the SpaceObjects linked list, instead of at the end (should be a very small function addition to the current dlinkedlist?).
If you cannot easilly restrict what lists you traverse, then I don't see any other benefit from the holder / opApply functions. It sounds like it will be less efficient because you will have multiple loops to go through each list, when it is more efficient to go through one big list (if you have to go through all the smaller lists anyway). |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Sat Oct 14, 2006 2:00 pm Post subject: |
|
|
In my opinion the holder class fixes much more than just draw order. It seems to make things nicer and should get rid of one or two gigantic switch-statements too. Plus, iterating over selected sublists isn't as complicated as I had expected (see edit).
I very much doubt the overhead caused by iterating over multiple lists instead of one list is measurable. We can do some tests if you like though.
So.. unless clayasaurus wants to revert too, I'd vote for continuing this change. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Phr00t
Joined: 03 Mar 2006 Posts: 203
|
Posted: Sat Oct 14, 2006 2:18 pm Post subject: |
|
|
OK... I personally don't think there is anything wrong with the switch statement? However, if you both feel it would be better to do this holder class, and you can handle implementing it, go ahead. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Sat Oct 14, 2006 2:58 pm Post subject: |
|
|
I think it is better design to split different objects into different lists. I just need to figure out a way to do it without breaking things : )
Oh, and there won't be any performance overhead, because while there are more lists, each list has less data in them and you can pick and choose which list you want to iterate through. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Sun Oct 15, 2006 1:39 am Post subject: |
|
|
Phr00t: I didn't mean to imply there was anything wrong with a switch statement. It works and is even pretty fast.
However, splitting the lists seems to clean up code and allows more intuitive expressions. So I think it's a gain, overall. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Sun Oct 15, 2006 5:47 pm Post subject: |
|
|
Heya
The implementation of this is going to be done in 'baby steps.'
I just committed the first baby step to SVN.
Changes...
1) Total abstraction of SpaceObjects and SpaceParticles into GameObjects struct
2) Foreach iterator to iterate through all space objects
I tested it by buying a new ship, completing a quest, and attacking another ship which attacked me back.
This change should allow me to split up the objects into multiple lists without huge changes in restructuring existing code.
~ Clay
[edit]: I improved the transpath art as well |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Phr00t
Joined: 03 Mar 2006 Posts: 203
|
Posted: Sun Oct 15, 2006 7:52 pm Post subject: |
|
|
Great!
I'll check it out hopefully tomorrow -- I'm pooped tonight! Went on a 6 mile "crop walk" today ![Razz](images/smiles/icon_razz.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Oct 17, 2006 2:37 pm Post subject: |
|
|
i'll be busy for a couple of days so I don't know when I will fully implement this.
~ Clay |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|