Present: hoijui, jK, Tobi, zerver
_Agenda_____________________________________________________________________
- Welcome
- Progress of stuff to be done before release
- GPL (progress)
- OS X (progress)
- MT / LUA
- Buildbot progress
- HL header handling (gl*.h, SDL.h)
- Next meeting
- Anything else? (WVTTK)
_Main Conclusions___________________________________________________________
- jk will do pre-release this week with an *rc tag
- OS X: spring compiles, daftalx got spring-gml to compile by installing mesa
- GML: instead of including GL.h it should include glext.h on OS X
- GML: LUA draw call-ins slow down the game a lot
- buildbot: Tobi switched to ubuntu lucid for the buildbot: newer much more efficient mingw (4.4.2)
- buildbot: only default is built by default (not debug & syncdebug)
- HL: copy gl*.h and SDL*.h headers to an include/ dir in the spring repo
_The meeting________________________________________________________________
Progress of stuff to be done before release
hoijui: for me, it is only these bugs, which we declared as memory bugs (plus the path finder one, in case it is a different one)
hoijui: but as we said, we would do the pre-release before they are fixed
Tobi: I fixed buildbot a bit more on monday (newer, much more efficient mingw) and didn't do any other spring things yet due to exams next week and other RL things
hoijui: ok
Tobi: yeah, originally I planned to do that on monday, but that ended up being buildbot improvement day
jk: Can I make a RC this week?
zerver: I didnt yet experience that memory corruption crash, so maybe it is AI related?
Tobi: [LCC]jK: that would be fine with me
hoijui: how did you test?
hoijui: and as i said, it happend with different AIs
zerver: Just load testing basically,lots of units lots of action
Tobi: [LCC]jK: do you want to make a rc like in the past releases, that has version 0.82?
Tobi: or just release a certain buildbot build as rc?
jk: I would like to tag it 0.82RC
jk: (for linux users)
Tobi: hmm ok
hoijui: i guess that coudl cause problems in some parts
hoijui: as so far, we used only numbers
hoijui: in the common format
Tobi: yeah I was wondering already why we didn't use 0.81rc etc. in the past
hoijui: mm
hoijui: maybe just try, and fix what does not work
jk: any idea what could break
hoijui: zerver, how did you test?
Tobi: one thing I know are the regexes in buildbot
Tobi: (and BuildServ)
jk: or is it just general skepticism?
zerver: Well, I spam "give all" like I usually do
Tobi: but that should be easy to fix
hoijui: installer generator, source packages, version comparison algos
zerver: and make lots of action
hoijui: ahh ok
jk: ah stacktrace translator
hoijui: .. ahh yeah true
hoijui: i mean.. maybe it woudl all work.. i dont know
hoijui: zerver, i will try that too then. you use a NullAI?
hoijui: :D
zerver: just start up with commanders start script
hoijui: why do you try to build that, jk?
hoijui: will never work due ot mingwlib changes
jk: ahh true
hoijui: zerver, ok
jk: still it's a RC, so it doesn't matter that much when the tagging doesn't work as expected
Tobi: I think it's ok to try it, if some stuff is broken on tuesday/wednesday I might be able to take a short look
Tobi: if it's just updating a few regexes then that should be ok
Tobi: I've never really liked using 'major' version numbers for RCs
hoijui: it also needs changeing in GameVersion, right?
jk: yup
hoijui: in addition to the tag
hoijui: ok
hoijui: so.. next topic?
zerver: Yeah, I have nothing against the RC being made
zerver: reconnection is tested and seems to work
Tobi: ok
main points:
- Tobi has fixed buildbot a bit more on monday (newer, much more efficient mingw)
- jk will do pre-release this week with an *rc tag
- hoijui will check for mem-corruption bug with comamdner script and /give all * n
GPL (progress)
jk: I assume, no progress here cause of RL?
Tobi: indeed, all my spring stuff is on hold temporarily until after exams
jk: didn't worked on it either ^^
Tobi: well at least until after monday
main points:
- there was no progess this week
OS X (progress)
Tobi: I know that, spring compiles, daftalx got spring-gml to compile by installing mesa
zerver: ok
Tobi: no clue why spring those dependencies differed between spring and spring-gml
zerver: strange
Tobi: and also no clue whether it linking to mesa means it always software GL
zerver: that will be fast
Tobi: (the error was that it couldn't find library -lGL )
jk: hmmmm
Tobi: he is still looking at compile errors in spring-hl
Tobi: Linking CXX executable ../../../spring-mt
Tobi: ld: library not found for -lGL
jk: perhaps GML links to gl.h? which is mostly totally outdated on most platforms
Tobi: that was spring-mt error
Tobi: see also: http://springrts.com:7778/builders/full ... logs/stdio
Tobi: there are also all the spring-hl errors
Tobi: probably most due to
Tobi: /buildbot/spring/full-macosx/build/rts/lib/headlessStubs/glewstub.h:8:20: error: GL/glu.h: No such file or directory
Tobi: /buildbot/spring/full-macosx/build/rts/lib/headlessStubs/glewstub.h:9:22: error: GL/glext.h: No such file or directory
jk: instead of linking to GL.h it should link to glext.h
zerver: ok, will check it
Tobi: s/linking/including/ ?
zerver: i guess you mean include?
jk: yeah
Tobi: ok
zerver: because MT contains no linker directives in code afaik
zerver: pragma shit or such...
jk: /buildbot/spring/full-macosx/build/rts/lib/headlessStubs/glewstub.h:9:22: error: GL/glext.h: No such file or directory < this is strange
jk: perhaps it is the other way around
Tobi: I suppose it can be figured out at some point
main points:
- spring compiles, daftalx got spring-gml to compile by installing mesa
- GML: instead of including GL.h it should include glext.h on OS X
MT / LUA
zerver: ok well just a quick thought about ways to make MT more noob friendly
zerver: it has issues with LUA draw call-ins slowing down the whole game
zerver: so my thought was whether to by default disable all such call-ins for MT
zerver: and the user has to enable it via confighandler
jk: o_O
zerver: the question is if this gives more or less bug reports
Tobi: doesn't that imply mt will only be useful with BA?
jk: sorry, but when you starting this, then MT becomes a half spring engine and so it shouldn't be included with the installer anymore
Tobi: since ppl wont know about hidden config settings and many other games use some form of Lua draw
zerver: ok
Tobi: how big is this performance impact?
zerver: it depends
zerver: if you turn on xrayshader, teamplatter and such widgets, you might as well run single thread instead
Tobi: but, performance doesn't get worse than single thread?
zerver: much worse
zerver: game is down to a crawl
Tobi: ouch
zerver: draw thread keeps locking mutexes and sim comes to a near complete halt...
zerver: and tbh I have no idea how to remedy this
zerver: other than to make the LUA code MT aware
jk: using a SceneGraph
zerver: ok, well, maybe not such a good idea to disable draw callins then
zerver: was just a thought
Tobi: well, I think putting some note about this in readme or on download page or so is good enough
zerver: yes, problem is no one reads that
zerver: maybe a pop-up messabe on first game start?
zerver: message
Tobi: if performance is slow they might read it
jk: that's why I disliked renamed spring-gml to spring-mt
zerver: yeah
jk: *ing
zerver: why you dislike rename to MT?
zerver: this problem is not GML related
jk: because noobs would think "HEY COOL multithreaded! I must use it!" w/o reading any notes or similar stuff
jk: noobs think multithreaded = 3x faster
zerver: well, after lagging out of 10 games maybe they read notes
Tobi: well since they have to manually configure lobby to start spring-mt they would know how to reset it to spring.exe
hoijui: damn.. sorry, had to leave for some minutes
Tobi: np
Tobi: we just reordered some stuff
hoijui: ah k :D
zerver: WRT the MT thing, I think I will add a logOutput print with that performance warning at game start
jk: add a read text to the loadingscreen?
zerver: yeah, or that
jk: *red
zerver: but noob may have uber fast machine that loads instantly
jk: o_O
hoijui: so basically, only people wiht low tech HW should use MT, and only when playing BA?
zerver: nope, I have a good system and cannot live without MT
zerver: it is so much more responsive when game grows big
main points:
- in GML, LUA draw call-ins slow down the game a lot
- zerver will add a logOutput print for MT, with a performance warning at game start
- zerver can not live without MT
Buildbot progress
Tobi: I put it in a ubuntu lucid (10.4) chroot, has newer much more efficient mingw
Tobi: also I made some preparations for allowing user to choose what profile he wants to build
Tobi: and build only default by default, to save some resources
Tobi: that's it
jk: Tobi, does gcc still uses (too) much memory when linking?
jk: or is it fixed with this?
Tobi: fixed with this
jk: nice :)
Tobi: now uses similar amounts as on my Fedora box
Tobi: so it was really mingw-gcc 4.2.1 issue
Tobi: now it's 4.4.2
main points:
- Tobi switched to ubuntu lucid for the buildbot: newer much more efficient mingw (4.4.2)
- only default is built by default (not debug & syncdebug)
HL header handling (gl*.h, SDL.h)
hoijui: spring-hl currently depends on these headers beeing supplied by the system (on linux)
hoijui: which is .. not optimal
hoijui: one option is, copying them into headlessStubs dir
jk: that would fix macosx compiling too
hoijui: ahh..
hoijui: :D
hoijui: sold?
jk: still I dislike it somehow to have unchanged shared files in the trunk
Tobi: but, spring itself needs those headers too
jk: sure they are OS-independent (in contrast to most mingwlibs) still ...
Tobi: so if spring compiles then macosx should be able to compile too with the system wide headers
Tobi: *macosx spring-hl
hoijui: then lets look at it independently of that
hoijui: an alternative woudl be, having a linuxlib package
hoijui: with just these headers
hoijui: but the i liek the headlessStubs way more
hoijui: .. or .. are there other ways?
jk: copying them to rts/lib/ is a no-go for me
hoijui: where then?
jk: create a new include dir in the base-folder or something like that
hoijui: mmm
hoijui: ok
main points:
- copy gl*.h and SDL*.h headers to an include/ dir in the spring repo, for HL
Next meeting
(same again, next week, 16:00 CET)
Anything else? (WVTTK)
zerver: Your stubs are dummy functions that do nothing, right?
hoijui: yes
zerver: Thing is, GML already has such stubs already.
jk: still they need glext.h for the definitions
zerver: So GML could easily be reconfigured to get the same behavior as your stubs
hoijui: mmm
hoijui: you really have all gl* functions subbed?
hoijui: i mena.. osme of them need to return stuff
hoijui: or say.. i would not want to do that
zerver: I return NULL :)
zerver: or 0
hoijui: in some, we also set the value of a parameter pointer
hoijui: dont know if it crashes wihtout that
jk: shouldn't matter what you return
zerver: ok, it was just a thought that maybe we are doing the same work twice
hoijui: yeah.. i dont know
jk: using the gml-code for it, would reduce the work to maintain it a lot
hoijui: yeah
hoijui: still.. i dont wnat to do that
zerver: ok, never mind
hoijui: done enough of that shit for some months
hoijui: ill do the include/ dir, with a readme in there or something
hoijui: next
hoijui: end?
Tobi: hey I'm off to catch the train, laters
hoijui: Tobi.. arent you late?
hoijui: ok
Tobi: I'm avail next week this time
hoijui: bye!
Tobi: laters
** Tobi left the channel( Quit ).
jk: caio
hoijui: ok
jk: hardware cursor?
zerver: yes
hoijui: well.. i have to admit, it also gets very unresponsive here in late game (debug build), also with HW cursor
hoijui: hmm..
hoijui: or..
zerver: ST framerate can drop to 5, MT below 20fps is extremely rare
jk: hmm mouse was pretty unresponsive in 80-81 because mouse pos was checked each videoframe instead of using the coords in the OS's mousemove events
hoijui: yeah
jk: but that's fixed in 82
zerver: ah, that sucked
zerver: i noticed that gui buttons trigger pressed even on mouse release
hoijui: for me, i felt it is worse in master then in release
zerver: event
hoijui: might also have to do wiht it beeing debug
zerver: so if you click outside a button and then drag it onto the button and release, the click is registered
hoijui: in late game, i have to press for over a second on a button, for it to trigger
zerver: not so good...
hoijui: thats when hte game is very laggy already of course
jk: under linux it still uses SDL, which checks mouse pos also ... in a bad way
hoijui: with ST
hoijui: single
zerver: there are many things to improve obviously
zerver: this is the type of annoyances im looking at right now
jk: I wanted to lurk into X11 event system, but it doesn't seems as easy as for winapi
hoijui: ahh ok
jk: -s +to be
jk: that's why I hate SDL, it gives rarelly and you need to write hacks for everything
zerver: :)
hoijui: hmm
hoijui: could you get rid of SDL if you woudl not need it for the mouse anymore under linux?
hoijui: most used seems to be SDL_GetTicks, which is easy replaceable
zerver: yep, dont use boost though
zerver: because that one sucked real bad
hoijui: HL uses boost
hoijui: its inacurate under windows?
zerver: the boost microsec timer has 15ms resolution
zerver: totally useless
hoijui: HL uses microseconds + nanoseconds
hoijui: guess it would be ok then?
zerver: have to see the code
zerver: in windows multimedia timers are very good
zerver: if your hw supports them, that is
hoijui: http://sl.pastebin.com/ZETgeTx3
hoijui: well.. rts/lib/headlessStubs/sdlstub_cppbit.cpp
hoijui: :D
zerver: ok, cannot say if boost xtime is good, have not tested it
zerver: i suggest you make a loop and output the time to cmdline to see if resolution is good
hoijui: mm.. i am on linux though :D
hoijui: but may test that one day
zerver: i can test it for you, np
zerver: end of meeting then?
zerver: does anyone write minutes?
hoijui: ok..
hoijui: yes me
hoijui: hmm..
hoijui: http://www.boost.org/doc/libs/1_32_0/do ... xtime.html
hoijui: the "Note"
hoijui: looks like it coudl be the 15ms thing again
jk: "For maximum portability, avoid durations of less than one second."
jk: lol
hoijui: "For maximum portability, avoid durations of less than one second."
hoijui: .. :D
hoijui: yeah
zerver: This is a temporary solution that will be replaced by a more robust time library once available
hoijui: well.. anyway... if this function is the only thing left we use of SDL.. it will be solved i guess
jk: we use SDL for window events
hoijui: ahh ok
jk: so removing SDL is a much bigger project
jk: esp.since Auswaschbar used SDL event structs in aGUI directly ...
hoijui: uhh :/
jk: I told him it is a bad idea, but he didn't listed
hoijui: :D
zerver: and we use SDL for keyboard stuff
zerver: and mouse ofc
jk: sure, but we couldn't implement all the things SDL does ourself
jk: we would need to switch to SFML or similar
hoijui: yeah.. nm.. no need for that
hoijui: now
zerver: k, lets how for a RC real soon then
zerver: bye
zerver: *hope
main points:
- SDL will not be repalced soon/ever