Present: abma, hoijui, jK, Kloot, Tobi
_Agenda_____________________________________________________________________
- MemPool
- Release plan
- how close to merge is Kloot's path finding branch?
_Main Conclusions___________________________________________________________
- readd MemPool
- disable EFX/EAX/Reverb when Pulse is used
_The meeting________________________________________________________________
>> hoijui joined!
>> Tobi joined!
>> jK joined!
>> Kloot joined!
jK: @hoij it seems you missunderstood me about mempool (not that the removal wrong, but mempool was functional as wanted)
jK: mempool didn't missed the gc, it was the gc! -> 99% of gcs just alloc a huge single block of memory and then reassign memory in that block for single objects
jK: so the job of the gc is not the free unused memory
jK: the job is to give a continuous block of memory
jK: this way the program saves much time it would else spend with alloc/dealloc small blocks
jK: e.g. alloc'ing and free'ing 1 million classes can stress the OS/mem/CPU very much
jK: the problem with mempool is that it wasn't KISS like
jK: e.g. you can use std::vectors to create such continuous memory blocks with much less trouble
jK: sure you wouldn't share it with other parts of the engine code, but that's not such a problem (our vertexarray implementation doesn't do so either)
>> abma joined!
jK: "share it" = share unused mem
abma: hey!
abma: irc-bridge doesn't work?
jK: hi
jK: others ones are still on their way through subdimensions
abma: ah, ok :D
abma: did meeting already start?
jK: nope
Tobi: be sure to run a benchmark of CMemPool when trying to use it
Tobi: quick test I do now shows malloc is slightly faster
Tobi: on 100* (10000 * alloc + 10000 * free) for sizes of 10 to 100 bytes
abma: on win32, too?
Tobi: 53 ms vs 68 ms on 10 bytes up to 159 ms vs 176 ms with 100 bytes
Tobi: no clue
abma: without having an real idea whats happening, was just a hint
Tobi: ugh there is actually a bug in the mempool in HEAD^^
Tobi: with that fixed it is faster :)
Tobi: (UseExternalMemory actually returns DontUseExternalMemory ...)
Tobi: new result is MemPool wins with 17 ms vs 54 ms for 10 bytes up to 23 ms vs 155 ms for 100 bytes, so that looks more worthwhile
jK: does the LOS Handler alloc such many objects?
Tobi: nah, don't think so
jK: too bad imbazcek never fixed the malloc alternative, it may give more than micro optimization
Tobi: I think LOS handler allocs once per LOS map update for a unit
Tobi: (not counting STL allocations)
jK: that's where KISS comes into play
jK: LOS Handler itself is `unclean` (=hard to maintain) code, and it is more worth to rewrite parts of it than doing micro optimization in its malloc
hoijui: ahh k...
hoijui: so you will revert the remove of mempool, Tobi?
hoijui: start meeting? :D
hoijui: !ring
hoijui: ping Tobi, Kloot jK abma
abma: +1 for start :)
hoijui: why did you not start the meeting?
hoijui: nm
jK: zerver is not here and my question was pointed at him
hoijui: ok.. i though we decided to start meetings if 4 devs are around
hoijui: can skip questions that need a certain dev that is not around
jK: still the remaining ones were added by ya
Release plan
Tobi: LosHandler is actually quite ok imo since I split it in a bunch of classes (relative to many other parts of Spring at least) , just could use explanation of the algos somewhere
hoijui: release plan.. i guess we can have my other question here...
hoijui: should i make a test release
hoijui: the oens i only announce in that forum thread
hoijui: plus some yellign in some channels
hoijui: for me, master is now non crashy in the usual game, instead of crashing every time
hoijui: or do we still have too many too ugly bugs?
abma: only the ba-bug is a bit anoying
hoijui: whats that?
Tobi: [ARP]hoijui_g5: k I will revert it
hoijui: widgets?
abma: yes
hoijui: thanks
jK: hmm true the LosHandler is much cleaner now, still it's missing like 1000 lines of comments
abma: "Red Build/Order Menu" http://springrts.com/mantis/view.php?id=2393
hoijui: mm ok
abma: [LCC]jK: in the mantis report of #2393 you wrote i should compile with DEBUG2 - it's compiled with DEBUG3?! + gdb stacktrace was already attached: http://pastebin.com/GieCGV3M (?)
jK: the stacktrace is incorrect
abma: ok, then i'll retry
abma: so... next?
hoijui: aehhh no
jK: also could you just use `bt` w/o `all`?
hoijui: i mean.. we did not decide whether therer are too many bugs still
jK: there is normally just one thread crashing in spring
abma: [LCC]jK: sure
hoijui: you want this bug fixed first?
abma: hm, you're right, doing a test-release with this bug should be ok
abma: but please make a big fat note about that :)
hoijui: ill make the post in the test thred and then tell some guys in the lobby..
Tobi: did recent STL have a hashmap already?
hoijui: cranphin reports that untis do ignore orders since the removal of AI_SELECT
jK: C++0x has
hoijui: b182bcbd686aef8e5913044abd3539489f1b2d6f is the last oen that works for him.. for me that does not happen though (he is on windows)
hoijui: but i cant see how that woudl happen
abma: [ARP]hoijui_g5: BA doesn't currently work too, because of the two lines of SetUnitLineage().. so maybe the problem is a bit smaller with the crash about many duplicate bug-reports
hoijui: mmm
abma: uh, yes true..
hoijui: yeah after the test release, i'll ask beherit if we can get a new release that works well wiht master
abma: [ARP]hoijui_g5: craphin is right
hoijui: current release is also missing game-ends script stuff
abma: this has to be fixed before release
jK: don't see any problem with AI_SELECT
abma: before test-release
hoijui: you neither cna controll units?
hoijui: aabma, all commands given to untis are ignored?
hoijui: ahh true..
hoijui: i get the same
abma: yes...
abma: only FPS mode works
abma: so we've a ego-shooter now :D
hoijui: i got a SIGSEGV too :D
hoijui: thought you can not shoot at enemies in ego mode :D
hoijui: but AI can still give commands
hoijui: AI now OWNS YOU!
abma: hm, the attack order seems to work
jK: everything works fine here
hoijui: :D
abma: i don't believe that you tested everything
hoijui: move orders to my com did not work, nad i got a SIGSEGV after trying t give like 10 in a row
hoijui: am recompiling latest, then will try to reproduce and give stacktrace
jK: move commands and everything else work fine, only with targetting there is something wrong
abma: which game do you use to test?
jK: k found the typo for the taregetting one
jK: -e
abma: here it doesn't work for BA and ZK
hoijui: KAIK alsohas a problem here, in master
hoijui: seems ot throw na exception in Update
jK: someone of you have to remove the last AI_SELECT usages in the AI interface
hoijui: ok..
hoijui: you dont compile AI stuff?
jK: no, neither got any idea where those functions get used nor how AI handle the output
abma: [LCC]jK: which game did you test?
jK: e.g. if KAIK is really crashing, it must use the result of newCommand
jK: and to me it seemed the return value shouldn't matter ...
jK: (there is another AI_SELECT usage in the AI interface, I was even less sure if it is safe to remove it w/o stubs)
jK: I always test with zk based tech demos
jK: -zk +ca
hoijui: ok.. ill have a look
hoijui: hmm.. tried wiht Comanders instead of a nAI
hoijui: and move commands still do not work
jK: broken movetypes?
hoijui: build commands do not work either
hoijui: but when you give it an attakc command, it does move until it is close enough
abma: as already said only attack command + fps mode seems to work...
hoijui: reclaim works too
jK: only thing I can say it works fine here
jK: (except attacks commands were randomly dropped)
jK: -s
hoijui: now i got a freeze in rts/System/Sound/AudioChannel.cpp
hoijui: got that before already
hoijui: mm k
abma: git describe
abma: 0.82.3-1847-gcf1d73b
jK: you guys have strange setups
hoijui:
hoijui: you have magic bug fixing setup
jK: lol
hoijui: ahh yeah.. sound is still choppy of course
hoijui: thats also not too nice for a test release
jK: blame pulse
hoijui: well...
hoijui: you want to say, we go that route again?
jK: the fault is 100% not in spring itself (because only <<<<1% of the sounds in spring uses streams at all)
hoijui: dont try to change that and tell everyone to disable pulse?
abma: [ARP]hoijui_g5: about the coppy sound: http://springrts.com/mantis/view.php?id=2368
hoijui: well.. maybe not, but it can be prevented inside spring
hoijui: as it works in rrelease version of spring
abma: disabling efx could help to fix that...
abma: see last note of bug report
hoijui: that is not a fix
hoijui: see secodn last note
abma: excludefx = eaxreverb in /etc/openal/alsoft.conf seems to solve it
jK: pulse instead is receiving spring's buffers and dividing them into stream packages, but with EFX it's too slow to reach them fast enough to ALSA -> lag
hoijui: if we coudl do somethign to make it work wiht pulse
hoijui: we shoud do that
hoijui: cause otherwise we get lots of the same complaints again
hoijui: mmm ok
hoijui: so the solution then is, to disable EFX by default
hoijui: at least on linux
jK: that's not a _solution_
abma: from end-user view its a solution
hoijui: it is a solution for the problem of getting a lto of annoying complains
jK: it's like disabling textures in opengl ...
hoijui: ah...
hoijui: you on ubuntu, abma?
abma: yes
hoijui: latest version?
abma: yep
hoijui: that os X one :D
hoijui: mm k
hoijui: and it sitll has that problem?
abma: yes, choppy sound with pulse
hoijui: or well.. have a better idea, jk?
hoijui: mm :/
abma: and pulse is default for openal...
hoijui: we shoudl make a bug report in the pulse issue tracker, and disable it on linux by default in spring
hoijui: for now
hoijui: k?
jK: detect pulse correctly and give bug fat warning similar to intel one?
hoijui: mmm
jK: *big
hoijui: if we can detect that...
hoijui: if we can detect it. maybe give that fat warnign, plus disable FX (but not in hte config)
hoijui: ?
abma: detection should be possible as its already logged to infolog.txt :)
hoijui: so FX gets auto enabled for them if they unuse pulse
abma: with LogSubsystems=Sound
hoijui: ah nice
hoijui: didnt know
hoijui: so?
hoijui: jk?
hoijui: is that ok path for you?
jK: yup
hoijui: ook
hoijui: Kloot, are oyu here? (as next topic is for you)
Kloot: ya
hoijui: k
how close to merge is Kloot's path finding branch?
Kloot: not close enough
hoijui: ok
Kloot: also after seeing community responses to pathfinding changes I am not going to finish it anytime soon
hoijui: mm.. ok
hoijui: well... pathing is not too good in master as it is now.. i mena.. it has some problems that amke it not good enough for a release
hoijui: and ... we kind of agreed on that you are the only oen wokrign on path finder stuff as long as you have that branch
hoijui: (also in master)
Kloot: what problems?
jK: esp. performance ones
hoijui: i remember something like.. untis running into builindg forever
hoijui: buildings*
hoijui: features*
hoijui: i mean.. htere are untested changes.. na we know how delicate that stuff is so.. its no wonder.. just mean... i am pretty sure that changes have to be done before a release
Kloot: mkay, better document as many cases as you can w/ steps how to reproduce and compile them into a mantis report
hoijui: so if you do not plan to merge your stuff before release, it will result in merge comflicts again... totally your decission .. i mena..
hoijui: ok
hoijui: yeah.. hopefully we can get godde to test some too again
hoijui: he made very good reports
hoijui: next topic is for zerver so..
hoijui: we are kind of at the end now
jK: k will do the minutes
hoijui: thanks
hoijui: so we wait with the test release until sound & command stuff is fixed, and hten try to get BA fit for that test release
hoijui: and likely have lots of test releases again