[Wesnoth-bugs] [patch #1141] Graphics optimization

Follow-up Comment #9, patch #1141 (project wesnoth): I've attached a slightly more correct patch... still no comments, sorry, I'll get to them this weekend at the latest... The std::unique call should be fine. First, two events will only be equal if the rectangles that they are from are equal. S

[Wesnoth-bugs] [patch #1141] Graphics optimization

Follow-up Comment #6, patch #1141 (project wesnoth): Ha, I had actually tried splitting the screen in two.. still slow. So, I've tried another way of calculating rectangles that I had been thinking of. Technically, this way doesn't scale as well as the quadtree approach, but in practice seems t

[Wesnoth-bugs] [patch #1141] Graphics optimization

Follow-up Comment #4, patch #1141 (project wesnoth): You're right, what I was saying about SDL rectangles didn't really make any sense. Doing some testing, it seems that it is very slow when we have the rectangle {0, 0, w, h}. I do not know why. Making it a pixel smaller in any direction makes

[Wesnoth-bugs] [patch #1141] Graphics optimization

Follow-up Comment #2, patch #1141 (project wesnoth): Yeah, there is a lot of wasted space int quadtree::tree. It was just easier to do it this way for testing. That will definitely be changed. You are right that "+ 1" would make much more sense for the halting condition. And why 48? No reason, t

[Wesnoth-bugs] [patch #1141] Graphics optimization

Update of patch #1141 (project wesnoth): Assigned to:None => cjhopman ___ Reply to this item at: ___ Message se

[Wesnoth-bugs] [patch #1141] Graphics optimization

URL: Summary: Graphics optimization Project: Battle for Wesnoth Submitted by: cjhopman Submitted on: Thursday 03/26/2009 at 07:51 Priority: 5 - Normal Status: None

[Wesnoth-bugs] [bug #11031] Movement display of a selected enemy unit is not restored after using keys for multi-turn movement range

Update of bug #11031 (project wesnoth): Status:None => Fixed ___ Reply to this item at: ___ Message sen

[Wesnoth-bugs] [bug #11031] Movement display of a selected enemy unit is not restored after using keys for multi-turn movement range

Update of bug #11031 (project wesnoth): Status: Fixed => None ___ Reply to this item at: ___ Message sen

[Wesnoth-bugs] [bug #11031] Movement display of a selected enemy unit is not restored after using keys for multi-turn movement range

Update of bug #11031 (project wesnoth): Status:None => Fixed ___ Reply to this item at: ___ Message sen

[Wesnoth-bugs] [bug #12841] Unique unit id assertion fails - MP campaign

Update of bug #12841 (project wesnoth): Status:None => Fixed ___ Follow-up Comment #3: This is fixed by SVN revision #32279.

[Wesnoth-bugs] [bug #12812] AOI-Linaera assertion error while orc moving, fatal crash

Update of bug #12812 (project wesnoth): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #3: See bug #13632

[Wesnoth-bugs] [bug #12951] Repeatable segfault of unknown origin

Update of bug #12951 (project wesnoth): Status:None => Fixed ___ Reply to this item at: ___ Message sen

[Wesnoth-bugs] [bug #12668] LoW: The Chief Must Die - errors after loading saved game twice

Update of bug #12668 (project wesnoth): Status:None => Fixed ___ Follow-up Comment #3: In fact I'm gonna mark this fixed, the crash is the same behavior as bug #13003. The other bug

[Wesnoth-bugs] [bug #12668] LoW: The Chief Must Die - errors after loading saved game twice

Follow-up Comment #2, bug #12668 (project wesnoth): I believe this is related to bug #13003 ___ Reply to this item at: ___ Message sent via/by Gna! http://gna

[Wesnoth-bugs] [bug #12951] Repeatable segfault of unknown origin

Follow-up Comment #2, bug #12951 (project wesnoth): So, I didn't actually mean to delete the attachment that I did :/. This bug might be related to bug #12990. If so, it might be fixed now. ___ Reply to this item at:

[Wesnoth-bugs] [bug #12990] Segfault while attacking

Update of bug #12990 (project wesnoth): Status:None => Fixed ___ Reply to this item at: ___ Message sen

[Wesnoth-bugs] [bug #13005] Game crashes with 'assertion failed'

Update of bug #13005 (project wesnoth): Status:None => Duplicate ___ Follow-up Comment #1: Duplicate of bug #12632 ___ Reply to

[Wesnoth-bugs] [bug #13003] BfW tends to crash or abort on specific map

Update of bug #13003 (project wesnoth): Status:None => Ready For Test ___ Reply to this item at: ___ Message sen

[Wesnoth-bugs] [bug #13003] BfW tends to crash or abort on specific map

Update of bug #13003 (project wesnoth): Item Group:None => None of the others ___ Follow-up Comment #2: I can reliably recreate this and have attached a savegame to do so. A bit tricky, what you need

[Wesnoth-bugs] [bug #12990] Segfault while attacking

Follow-up Comment #2, bug #12990 (project wesnoth): #0 0x009f02d4 in config::all_children_iterator::operator* (this=0x7fffabfdc450) at src/config.cpp:394 #1 0x009f37eb in c

[Wesnoth-bugs] [bug #11522] Asserts in unit_map.cpp, apparenty invalid iterators are used

Update of bug #11522 (project wesnoth): Item Group:None => None of the others Status:None => Fixed ___ Reply to this item at:

[Wesnoth-bugs] [bug #11452] Some [ai] settings making the AI not recruit

Follow-up Comment #3, bug #11452 (project wesnoth): Bug happened to me. In the unit list, it appears that all units have been clobbered, except for those that I have, either in-play or in my recall list. ___ Reply to this item at:

[Wesnoth-bugs] [patch #1046] unit map improvements

Update of patch #1046 (project wesnoth): Status:None => Done ___ Reply to this item at: ___ Message se

[Wesnoth-bugs] [bug #11486] assert in unit_types.cpp line 1004 (related to unit types lazy loading?)

Follow-up Comment #3, bug #11486 (project wesnoth): Yep. Doesn't actually seem to have anything to do with encountering a new unit. It's just that that is when you are most likely to look up the description. I believe that, once "dummy_unit" has been placed into types_ a call to build_all will tr

[Wesnoth-bugs] [bug #11486] assert in unit_types.cpp line 1004 (related to unit types lazy loading?)

Follow-up Comment #2, bug #11486 (project wesnoth): Did a bit of digging. Happens when it tries to build "dummy_unit". ___ Reply to this item at: ___ Message se

[Wesnoth-bugs] [bug #11486] assert in unit_types.cpp line 1004 (related to unit types lazy loading?)

Follow-up Comment #1, bug #11486 (project wesnoth): I've had this happen twice now. Here's some more info. Log output followed by backtrace. (file #4222) ___ Additional Item Attachment: File name: bug 11486 Size:13 K

[Wesnoth-bugs] [patch #1054] gui2 text box history

Follow-up Comment #6, patch #1054 (project wesnoth): Behaves a little friendlier now. Actually, just a stray behavior fixed, (file #4221) ___ Additional Item Attachment: File name: history.patch Size:10 KB

[Wesnoth-bugs] [patch #1054] gui2 text box history

Follow-up Comment #5, patch #1054 (project wesnoth): Oops. Bug fixed. First patch is everything. Second patch just fixes the bug, requires previous patch file 4215. Only change is to ttext_box.up(). (file #4219, file #4220) ___ Addition

[Wesnoth-bugs] [patch #1054] gui2 text box history

Follow-up Comment #4, patch #1054 (project wesnoth): Just removed mutable from pos_ in ttext_history. I had been playing with making down() and up() const, but ended up not doing that. (file #4215) ___ Additional Item Attachment: File nam

[Wesnoth-bugs] [patch #1054] gui2 text box history

Follow-up Comment #3, patch #1054 (project wesnoth): Saves history to preferences file, and some other small changes. Toughest part is mimicing your style, I tried. If there are specific things I can do to make it look more consistent with the rest just let me know. (file #4210)

[Wesnoth-bugs] [patch #1046] unit map improvements

Follow-up Comment #6, patch #1046 (project wesnoth): So I had changed the ids to use a counter. But then you have the problem that you must save that counter value when the game is saved, otherwise you will get id clashes after loading. So, for now, I went back to the random padding. This patch

[Wesnoth-bugs] [patch #1054] gui2 text box history

Follow-up Comment #1, patch #1054 (project wesnoth): Oh, if the line history = "whatever" is not in the wml then the text box gets a history object that doesn't do anything, rather than have the special code to deal with whether or not it has a history clutter up the text_box. __

[Wesnoth-bugs] [patch #1054] gui2 text box history

URL: Summary: gui2 text box history Project: Battle for Wesnoth Submitted by: cjhopman Submitted on: Sunday 04/13/2008 at 03:36 Priority: 5 - Normal Status: None

[Wesnoth-bugs] [patch #1046] unit map improvements

Follow-up Comment #4, patch #1046 (project wesnoth): And a bit more... It would also be possible to do this just with a multimap * > > implemented basically the same. The downside to this would be that it doesn't allow fast lookup by unit_id, and I think it would be useful to add the ability to

[Wesnoth-bugs] [patch #1046] unit map improvements

Follow-up Comment #3, patch #1046 (project wesnoth): Yeah, I was going back and forth between having it set the id or not. Also, I have changed both the underlying id generation and the unit_id generation(in the unit_map) to use a counter rather than the random number generator. Just makes more s

[Wesnoth-bugs] [patch #1046] unit map improvements

Follow-up Comment #1, patch #1046 (project wesnoth): to clarify, i append the two random numbers. This second patch cleans up the unit map code some more. Only changes from the previous are in unit_map.hpp and the changes are only to the iterator_counter. (file #4159) __

[Wesnoth-bugs] [patch #1046] unit map improvements

URL: Summary: unit map improvements Project: Battle for Wesnoth Submitted by: cjhopman Submitted on: Tuesday 04/08/2008 at 20:23 Priority: 5 - Normal Status: None

[Wesnoth-bugs] [patch #1041] Bug fix bug #11418

URL: Summary: Bug fix bug #11418 Project: Battle for Wesnoth Submitted by: cjhopman Submitted on: Thursday 04/03/2008 at 03:31 Priority: 5 - Normal Status: None

[Wesnoth-bugs] [patch #1035] WML preprocessor messages for undefined macros

URL: Summary: WML preprocessor messages for undefined macros Project: Battle for Wesnoth Submitted by: cjhopman Submitted on: Monday 03/31/2008 at 18:56 Priority: 5 - Normal

[Wesnoth-bugs] [patch #1033] New formulaAI formula: close_enemies

Follow-up Comment #5, patch #1033 (project wesnoth): Parsing unit list would almost always be faster, as it gets rid of the slow find in the inner loop. Even in the example you gave it is likely that parsing the unit list would be faster. As an estimate, it's probably faster to check ~5-10 units

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Follow-up Comment #11, patch #1020 (project wesnoth): 1) I decided to leave the normal iterators as they are now, since for those if valid() returns false the iterator is not necessarily invalid, but it might be... and I didn't want to break any existing code 2) I was unsure of this point, but i

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Follow-up Comment #9, patch #1020 (project wesnoth): so I agree that the assert() would be better, so that is done. also, am now using the revision_number_ in all iterators. have not implemented the unit_map_observers (file #4037) ___ Ad

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Additional Item Attachment, patch #1020 (project wesnoth): File name: unit_map_new_iterators.patch Size:14 KB ___ Reply to this item at: ___ Message sent via

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Follow-up Comment #5, patch #1020 (project wesnoth): #4033 slight change to unit_map and addition of another type of iterator... new iterators unit_iterator - type 1 unit_by_loc_iterator - type 2 types as in sapient's forum post http://www.wesnoth.org/forum/viewtopic.php?p=236079#p236079

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Additional Item Attachment, patch #1020 (project wesnoth): File name: unit_map_new_iterators.patch Size:14 KB ___ Reply to this item at: ___ Message sent via

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Follow-up Comment #4, patch #1020 (project wesnoth): #4032 fixed some warnings -- initializing members in correct order ___ Reply to this item at: ___ Message s

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Additional Item Attachment, patch #1020 (project wesnoth): File name: unit_map_unit_iterator_fixed.patch Size:10 KB ___ Reply to this item at: ___ Message sent

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Follow-up Comment #3, patch #1020 (project wesnoth): #4029 is just a minor change and removed the erroneous extra line in formula_ai.hpp ___ Reply to this item at: __

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Additional Item Attachment, patch #1020 (project wesnoth): File name: unit_map_unit_iterator_better.patch Size:10 KB ___ Reply to this item at: ___ Message sen

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Follow-up Comment #2, patch #1020 (project wesnoth): also... the changed line in formula_ai.hpp shouldn't be in the patch... ___ Reply to this item at: ___ Mess

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

Follow-up Comment #1, patch #1020 (project wesnoth): oh - see http://www.wesnoth.org/forum/viewtopic.php?p=236063#236063 for background. ___ Reply to this item at: _

[Wesnoth-bugs] [patch #1020] unit_map::unit_iterator

URL: Summary: unit_map::unit_iterator Project: Battle for Wesnoth Submitted by: cjhopman Submitted on: Saturday 03/22/2008 at 20:20 Priority: 5 - Normal Status: None

[Wesnoth-bugs] [patch #1017] bug fixes for formulaAI

Follow-up Comment #1, patch #1017 (project wesnoth): Error was when testing on windows. ___ Reply to this item at: ___ Message sent via/by Gna! http://gna.org

[Wesnoth-bugs] [patch #1017] bug fixes for formulaAI

URL: Summary: bug fixes for formulaAI Project: Battle for Wesnoth Submitted by: cjhopman Submitted on: Friday 03/21/2008 at 16:20 Priority: 5 - Normal Status: None