Present: abma, hoijui, Tobi, zerver
_Agenda_____________________________________________________________________
* Welcome
* Release plan
* lua state split (EXPORT and Script.XXX)
* the big refactor
* Anything else? (WVTTK)
_Topics_______________________________________________________________________
Welcome
<abma>hey!
<zerver>hi
<zerver>hoi is in etherpad, but not here
<hoijui>hey
<zerver>hi
<hoijui>i guess you did not start?
<zerver>no, too few ppl
<hoijui>mm
<hoijui>enough now?
<zerver>think so
Release plan
<zerver>thanks
<hoijui>:D
<hoijui>theres some kids .. theatre like thing on audio casettes ehre
<hoijui>si eveyrone here?
<hoijui>really?
<hoijui>absolutely sure?
<hoijui>wonderfull!
<hoijui>:D
<hoijui>=== Release plan ===
<zerver>is tobi afk?
<hoijui>plan is, to have some test games (after meeting) on the release branch
<hoijui>ouh..
<hoijui>yeah lets wait for him
<hoijui>ping [RoX]Tobi, abma_irc
<Tobi>hey
<hoijui>hey
<abma>hey
<hoijui>
<Tobi>working on something else in the mean time so I seem to be a bit half afk-ish
<hoijui>ok
<hoijui>issues known so far with .6 candiadte:
<hoijui>KAIK freeze
<hoijui>bad plasma visuals (in S44)
<hoijui>though the later is in since 0.82 already
<hoijui>and KAIK freeze.. we know the guilty commit, which is not too important
<hoijui>is KAIK only
<zerver>KAIK bug or spring bug?
<hoijui>KAIK
<hoijui>or say..
<hoijui>maybe not.. but the changes are only in KAIK, and they affect only some debug drawing of paths
<hoijui>and if you undo them. it does not freeze
<zerver>k
<hoijui>though.. kloot put multiple things in one commit so i had to separate these changes out
<hoijui>anywya.. that is no big problem
<Kloot>hey
<zerver>lo
<hoijui>need to test FPS bug, rejoin and spec icons
<hoijui>hey! :D
<hoijui>[16:32:21] <[ARP]hoijui_g5> === Release plan ===
<hoijui>ghsted buildings visible by specs i mean
<hoijui>not spec icons
<hoijui>smoth seems to be ok with it, did some gundam tests
<hoijui>Kloot, have you seen the KAIK related mantis report?
<zerver>i have not seen any ghosted buildings as spec with my fixed build
<Kloot>yeah saw it this morning
<hoijui>ok
<hoijui>zerver, what is your fixed build?
<zerver>special build from 0.82 branch
<hoijui>well.. we just have to test these things in the release branch, cause there might have been merge failer or something
<hoijui>ah
<zerver>yeah, test it again
<hoijui>k
<hoijui>guess. next then?
<zerver>and the rejoin particularly needs testing
<hoijui>hmmm
<zerver>it is kind of hard to test that by yourself
<hoijui>yeah :D
<hoijui>smoth will help testing he said
<hoijui>i will..
<hoijui>maybe BD too
<zerver>i have 4 PCs in one room though, i
<hoijui>:D
<zerver>so it can be done
<zerver> :)
<hoijui>next?
<zerver>yup
<hoijui>lets skip comk enhancement with devs..
<hoijui>or shoudl we have it?
<hoijui>today i mean
<zerver>i have nothing to add
<hoijui>mm k
<hoijui>can still do it later if someone wants it
main points:
* need to test the fixes for FPS bug, rejoin and spec icons in the release branch
lua state split (EXPORT and Script.XXX)
<hoijui>ah well..
<zerver>would be nice to have jK here
<hoijui>without jk, and Tobi half afk, i guess.. this makes no sense to discuss either :/
<hoijui>mmm
<zerver>sorry to hear about his tragic loss
<hoijui>mmm
<Kloot>oh wow, I just read etherpad
<zerver>we had a long 15min silence at meeting start out of respect of the dead
<hoijui>so.. we are at end of meeitng laready :D
<zerver>maybe I can say something about EXPORT
<hoijui>yeah sure..
<hoijui>we can also discuss the big refactor stuff
<hoijui>after that
<zerver>don't know I you read my posts, but I tested converting CA to use EXPORT table
<hoijui>i owuld have soem thigns to day htere
<hoijui>i read something.. it is too expensive?
<zerver>yeah, unplayable
<zerver>but I think this table is good to have anyway, it just needs some tweaking of the mod
<Kloot>some?
<zerver>yeah, don't store too much stuff in the table, delete if after SendToUnsynced, etc
<Kloot>CA has 1000 gadgets that need synced->unsyced comms
<zerver>not exacly, i think i touched 10 gadgets with my search and replace
<zerver>in BA 2 gadgets were affected, and it was very playable
<Kloot>hmm, sounds like it does not scale well then
<zerver>well, the whole table is sent on every SendToUnsynced, and also every GameFrame
<zerver>so not very surprising
<hoijui>use git
<zerver>:)
<zerver>put the table on github and only pull the changes
<Kloot>gl with that -_-
<zerver>the way I see it, EXPORT may simpify to send large objects
<zerver>but you cannot permanently store big stuff there
<Kloot>nor lots of small stuff
<zerver>SendToUnsynced does not support tables atm
<zerver>so you can put the table in EXPORT, SendToUnsynced, and then EXPORT.table = nil
<Kloot>right
<Tobi>wouldn't it be possible to make the synced side record the changes, so the copying is only O(number of changed values) instead of O(total number of values)?
<Kloot>tables are the main reason for using the GG route
<Tobi>might be hard to do though
<Tobi>I don't completely recall how versatile things like __newindex are
<zerver>I thought about ways of sending only changes, but my LUA s
<zerver>skill is limited
<zerver>looping through the table to see what has changed wont work, it takes too much time
<Tobi>yeah that is moot
<Tobi>the point is to keep track of the changes while they are being made of course, so the algorithmic complexity of the copying can be reduced :)
<zerver>yup
<zerver>anyway, maybe jK has some suggestion
<Tobi>but it might be pretty hard if e.g. _G.table.X is first changed and then later _G.table is bound to a different value
<hoijui>mmm
<Tobi>then _G.table.X doesn't need to be copied anymore
<Kloot>also depends on whether the changes are of the sort t[k] = t[k + 1] or t[k] = {some huge table}
<Tobi>yeah that too
<zerver>anyway, im happy that CA actually worked with the EXPORT, even though it was unplayable framerate
<Tobi>how often do you copy data?
<Tobi>you changed the Lua to use EXPORT instead of _G already there?
<zerver>[16:43:29] <zerver> well, the whole table is sent on every SendToUnsynced, and also every GameFrame
<Tobi>ah
<Tobi>what about trying to buffer SendToUnsynced too?
<Tobi>so you only need to copy the stuff once per GameFrame?
<Tobi>hmm
<zerver>yeah, maybe
<Kloot>won't that just cause one big blocking operation instead of multiple small ones?
<zerver>problem is, on sendtounsynced you need to record the EXPORT table at that very instant
<zerver>because a moment later, the data may be nil
<Tobi>Kloot: it also reduces the amount of copying
<Tobi>zerver: yeah true
<Tobi>or actually, I thought to copy only the latest EXPORT
<Tobi>but indeed that would change the semantics
<zerver> _G.EXPORT.burningUnits = burningUnits
<zerver> SendToUnsynced("onFire")
<zerver> _G.EXPORT.burningUnits = nil
<zerver>excerpt from CA
<Tobi>for excerpts like that it would actually be cleaner to be able to do SendToUnsynced("onFire", burningUnits)
<Tobi>although that would have the same performance impact (at least for the copying)
<zerver>yeah
<zerver>Regarding Script.LuaUI.XXX, I just need to extablish where the call should be directed in each case, where there is a synced and unsynced part
<zerver>If LuaUI has split states also, the "synced" part of it may invoke Script.LuaRules.XXX
<zerver>the question here if this call should end up on the synced or unsynced side of LuaRules
<zerver>any ideas? otherwise next point...
<Tobi>personally I still think LuaUI should preferably not be split, just the events queued in a buffer so a non-sim thread can process them at its own speed
<zerver>yeah, i did that also
<zerver>but I don't think we shall close the possibility that luaui may be threaded for real
<zerver>and some events have a return value and are a bit tricky to queue
<Tobi>even if luaui-draw won't have access to any sim things (i.e. no LuaSyncedRead), then I still don't like that in each widget one needs to implement a transfer mechanism for the desired data
<Tobi>that is something that should be handled by the engine IMO
<Tobi>zerver: aren't that only non-sim events?
<Tobi>zerver: since sim definitely can not use any value returned by LuaUI, as that would desync
<zerver>WorldToolTip...
<Tobi>sim doesn't need to know what it returns
<zerver>kk, well i did not attempt to queue that event
<Tobi>it is fired somewhere from the gui, I don't know in which thread that runs
<zerver>actually sim invokes it too
<Tobi>I would assume render thread
<Tobi>but then it can not use its return value
<Tobi>or it would desync
<zerver>but im not sure if it uses the return value...
<zerver> :)
<Tobi>by definition sim can not use anything returned by LuaUI for that reason
<Kloot>WTT is a pretty strange "event" anyway
<zerver>well, i have the queue, and optional split of LuaUI as well
<zerver>so everyone is happy, or I hope so
main points:
* zerver tested converting CA to use EXPORT table and had some performance problems
the big refactor
<hoijui>so the big refactor?
<zerver>ya
<hoijui>
<hoijui>i would like to start wokring on it..
<hoijui>eg.. splitting the drawing out of the sim classes
<hoijui>or .. shoudl we do more plannign first?
<Kloot>getting the remaining draw code out of sim classes needs some planning too
<Kloot>projectiles especially
<hoijui>hmm.. becuase there coudl be more cshared code then is?
<Kloot>yeah, the simple way would be to create a RenderProjectile class hierachy
<Kloot>with duplicated data
<hoijui>hmmm
<hoijui>woudl it not be better to first separate
<hoijui>and later do this hirarchy
<hoijui>would make easier tracking if bugs
<Kloot>I meant that would be the simple way to separate things, not the best though
<hoijui>it woudl mean, creating some new files to be removed agian soon after, but.. well.. not really bad
<hoijui>you would do the two steps at once?
<zerver>more at once is probably mode bugs yeah, but also faster
<zerver>more
<hoijui>i would do eg an IProjectileDrawer, and one impl. for each projectile type, with directly copying the code out of the sim classes
<hoijui>then start mergign together what possible, creating new classes, eg: CAbstractProjectileDrawer
<hoijui>or woudl you want a single Projectile drawer class?
<Kloot>I'd prefer to build one the existing one eyh
<hoijui>...
<hoijui>dont get what you mean with that
<Tobi>in the end, a single projectile drawer class may be better I think, as that way rendering of projectiles could be completely orthogonal to their behaviour
<Tobi>well, not necessarily a single drawer class
<hoijui>ahh that is hte approach of alls stuff beeing made wiht properties, instead of classes?
<hoijui>classes/types
<Tobi>not sure what you mean, but I think the answer is no :)
<hoijui>ok :D
<Tobi>what I mean is the projectile classes in sim determine how the projectiles behave
<hoijui>i meant: instead of a cannon projectile type, have a property gravity-following
<Tobi>e.g. starburst / ballistic / torpede / bomb / whatever
<hoijui>mmm
<hoijui>yeah ballistic :D
<hoijui>so we coudl do it like:
<Tobi>and a `renderprojectile' can source any of the sim projectiles
<Tobi>(for it's position, speed, etc.)
<Kloot>I mean extending ProjectileDrawer as it exists now with a std::container<RenderProjectile*> where each RenderProjectile* points to a Projectile*
<hoijui>create a new class ProjectileDrawer, and in the draw(Projectile*) function, have a switch with one case per pprojectile
<Tobi>but render projectile hierarchy can contain things like like `bitmap', `animated bitmap', '3d model', etc.
<hoijui>mm
<hoijui>ok
<Tobi>maybe it's the same as what you meant Kloot?
<Kloot>seems pretty close yeah
<zerver>to get good performance with MT, render projectiles should be deleted by rendering thread, and not depend on sim projectiles
<Tobi>that way you could have any combo of behaviour and rendering, i.e. a torpedo rendered as lightning, a ballistic shell rendered as ICBM missile, etc.
<hoijui>how can htey not depend on sim projectiles?
<hoijui>you mean.. not directly depend on the smae instance of a projectile the sim uses?
<hoijui>that is what we woudl like to solve wiht the multi states
<hoijui>but i think these two changes can be made relatively independend from each other
<hoijui>eg.. first separate all rendering from sim classes, then do the multi states
<hoijui>if you keep that in mind
<zerver>sim must either keep the sim projectile alive until the render thread does not want it anymore, or the render projectile must have data duplication
<hoijui>it must have data duplication anyway
<hoijui>as sim might already set the position for the next frame, while render thread still draws old frame
<zerver>problem with current spring version is that a performance penalty occurs when objects are deleted
<zerver>sim must wait until draw thread is no longer rendering any projectiles, then delete
<Tobi>seems easy to solve
<zerver>with some data duplication, yeah
<hoijui>i though we agreed that data duplication is requried anyway
<hoijui>for having better MT support
<hoijui>question is just, if there will be 2 3 or 4 states
<Tobi>for just the deletion sim could just stuff the to-be-deleted projectiles in an array that is cleaned up a while later (or maybe by the render thread)
<Tobi>but yeah I guess data duplication will be necessary anyway
<Tobi>and that's a little harder to solve :)
<hoijui>mm
<hoijui>but.. it is a separate thing
<hoijui>qutie
<hoijui>quite*
<zerver>yeah, that we spoke about earlier, requires the actual deletion to be unsynced
<hoijui>btw.. oen important thing i wanted to say
<hoijui>we should take track of our branches in some way
<hoijui>as in..
<zerver>you mean a list that describes what branch does?
<hoijui>so we know who has big branches of what part
<zerver>ya
<zerver>probably best if one guy works on projectiles, someone else on units
<hoijui>mmm
<zerver>but we must also conside the suggestion that all object types are merged into one
<Tobi>pseudo code: sim: goes through each projectile for simulation. as side effect, put position/orientation/velocity in a `projectile buffer'
<Tobi>at end of game frame, projectile buffer is marked as ready and a new one is created (reused) for next frame
<zerver>yeah, triple buffered
<Tobi>next draw frame, renderer picks up the last projectile buffer and uses that for rendering
<Tobi>yup
<Tobi>with rendering actually keeping no state about projectiles
<Tobi>but I wonder if that works out properly
<zerver>there are probably plenty of gotchas
<Tobi>i.e. can all types of projectile rendering be implemented without state?
<zerver>units even worse
<hoijui>would be bad if this was a requriement, yeah..
<Tobi>units are a completely different beast, better solve one thing at a time imo :)
<hoijui>why can there not be RenderProjectivles with this approach?
<Tobi>there would be no way for the renderer to know which projectile in the buffer is which projectile in the previous buffer
<hoijui>if not relying on a pointer
<hoijui>and using a separate ID
<zerver>this discussion about merging units, features, ... into a common object type, that did not include projectiles I assume?
<Tobi>(though at the cost of some performance that could be solved by putting a ID in the buffer indeed)
<Kloot>it did
<zerver>Ok, important to have a small base class there
<Kloot>since at the bottom of the pool all those objects have the same requirements for rendering
<Kloot>ie pos/speed/model/some other data
<zerver>so question is, should we merge that first?
<zerver>because then we dont have to invent the wheel 5 times
<Tobi>projectiles already are CWorldObjects, right?
<Kloot>yes
<hoijui>we need better documentation commens describing these classes maybe
<Kloot>actually there is one class in between CProjectile and CWorldObject
<hoijui>do you want to eliminate the feature/unit class?or just move more stuff into base classes?
<zerver>good question
<zerver>another annoyance is the trees, they should be features
<Kloot>they are?
<Tobi>they are, right? (only with a different renderer)
<zerver>oh?
<Kloot>every tree is a cfeature already
<Kloot>but they are renderer by the treedrawer* family
<Kloot>rendered*
<zerver>good then
<Tobi>does sim always know beforehand what kind of data the renderer will need? (or could it be made like that?)
<hoijui>should it not simply copy all the sim state for the renderer?
<hoijui>eg, all mempers of class Unit
<hoijui>members*
<Tobi>I think that is an important question to answer, because it could affect the design a lot
<Tobi>I don't think so, that would probably be way too expensive
<zerver>copy all might be too slow
<Kloot>yeah, eg a huge subset of cunit is never touched by unitdrawer
<zerver>problem arises when Lua drawing wants to access member variable X
<Tobi>exactly
<zerver>I guess we don't want to limit what Lua is allowed to read...
<Tobi>correct
<hoijui>yeah
<Kloot>back to the what-to-copy problem again -_-
<Tobi>yeah
<hoijui>though.. isnt big part of cunit to be moved to unitdrawer anyway?
<zerver>the Lua problem, lol
<Tobi>I see at least two solutions
<zerver>spring is so powerful that redesign is difficult
<hoijui>copying all of CUnit coudl be done with memcpy
<hoijui>if taking care of pointer stuff somehow
<Tobi>one is having Lua specify beforehand what data it needs -> big con: needs Lua changes...
<Tobi>but imo it would be way better already than each widget having to implement the transfer themselves
<Tobi>the other is learning what data is needed and accessing it the slow way the first time it's accessed
<Tobi>e.g. GetUnitHealth is called in draw -> all next sim frames health will be put in buffer, that first call takes a lock and accesses sim directly (or alternatively: rendering blocks until the data is available :))
<zerver>is there a solution other than data duplication
<zerver>could be keep the sim object alive until draw no longer needs it?
<zerver>*we
<hoijui>.. we had that before already
<hoijui>forgot?
<Tobi>data duplication would still be needed to prevent inconsistent read
<zerver>we didnt conclude definitely...
<hoijui>yeah we did
<zerver>if we didnt reuse IDs for objects, it coudl work
<hoijui>no
<hoijui>casue sim might be in frame X+1 and draw in frame X
<hoijui>and hte object is/was in different positions in these two frames
<Kloot>how could the renderer decide that it no longer needs a simobject?
<Kloot>except if sim sets an isDead state variable or sth
<zerver>if it removes it from all rendering structures itself, after receiving a RenderXXXDeleted event
<zerver>we could have like this: never reuse any IDs
<zerver>put all object pointers in buffers that never need reallocation
<hoijui>are yo ustill trying to not have multiple sync states?
<hoijui>memory leack concept? :D
<zerver>:D
<zerver>so, 1000 units per buffer etc
<zerver>when buffer is full, make a new one
<zerver>unit ID etc grows forever
<hoijui>what do you want to solve wiht that?
<zerver>this way renderer can access old deleted units also
<zerver>MT performance
<Kloot>that's not possible since each cunit needs to be stored somewhere and accessed in O(1) time by id
<zerver>unit 50000 --> buffer 50, unit 0
<hoijui>look zerver, the accessing unit from render thread after dead is not the reason why we need multiple states
<zerver>i know, you want to separate for other reasons
<hoijui>ok
<hoijui>best thing would probably be, to check how much memry the sync state of a big game uses
<Tobi>some way I think the copying will be way too expensive too
<hoijui>but if it can be done wiht memcpy
<hoijui>there are not a lot of pointers
<hoijui>still?
<zerver>MT performance and sim/render separation are different things, still linked together in a way
<hoijui>i mean... it is more expensive memory wise, but everythign else will be more expensive CPU wise
<Kloot>zerver: so you want to keep 50 buffers of 1000 units around?
<Tobi>slightly mismatched positions doesn't really matter I think (just minor visual artifacts), most importantly you don't want to get inconsistent reads that really brick things
<zerver>no, create buffers on demand
<hoijui>mm
<zerver>garbage collect old buffers
<hoijui>so how big is the synced state in total?
<hoijui>for a big game
<Tobi>random idea: would it work if we make something like a global volatile int currentSimUnitID and make renderer idle for a bit when it hits that unit in rendering
<hoijui>map with lots of features
<hoijui>.. and haivng only one synced state?
<Tobi>or more on a higher level: data dup isn't needed if we can somehow guarantee that rendering never access an object X while sim is messing with it
<hoijui>there could be multiple such untis
<hoijui>units
<Tobi>yes
<hoijui>maybe units will be processed in paralell, or at least by multiple threads
<Tobi>is that statement correct or .. ?
<hoijui>no...
<hoijui>it means we are only accurately rendering in a 2 frames range
<zerver>volatile will not work, needs mutex
<hoijui>would give ugly stuff with fast moving projectiles eg
<zerver>problem is also that the sim updating of one unit may mess with another units data
<hoijui>and there might be values which are less forgiving then position
<Tobi>is mutex the only solution? aren't there solutions with semaphores or so? or would they by definition be as expensive as a mutex?
<hoijui>but if the synced state is.. say 100MB or 200MB
<hoijui>tripplebuffering woudl still be ok, no?
<hoijui>as much as i know, these are all the same
<Tobi>requires 6-12 GB/s memory bandwidth
<hoijui>ahhh
<zerver>it would need currentSimUnitID and currentDrawUnitID
<Tobi>assuming read and write can not overlap
<zerver>mutex takes up to 1000 cpu cycles
<Tobi>and semaphore?
<zerver>semaphore is more expensive IIRC
<Tobi>and what about lockless threadsafe data structures?
<zerver>they need some locked object, but not mutex
<zerver>in my gmlVector, i use an atomic count, because that is faster than mutex
<Tobi>seems in academics that kind of thing isn't considered a lock, just a synchronization primitive
<zerver>yeah, it has major disadvantages if you try to use it as a mutex
<Tobi>since I just found a paper about a lock-free linked list, that uses only an atomic compare&swap instruction as synchronization primitive
<zerver>that's why it is faster...
<zerver>that list probably suffers from the same drawbacks as my vector
<zerver>this is OT :)
<Tobi>not really, I'm just thinking out of the box for a bit / zooming out of the way we were thinking all the time
<Tobi>to see if maybe there is a completely different way that we missed till now
<zerver>if we could avoid the duplication, it would surely help
<hoijui>possible problems without duplication:
<Tobi>though this _is_ slightly OT, what are those drawbacks?
<hoijui>not accurate to the frame reads
<hoijui>inconsistent read or management costs for nto accessing one object with two threads at the same time
<hoijui>right?
<zerver>yeah, MT reads lot of partially updated data
<hoijui>the first one is negliable you think?
<zerver>if you watch the rendering closely, there is graphics corruption here and there, lines drawn across the screen...
<hoijui>mm :/
<hoijui>wel i seldomly used MT so far
<hoijui>sounds like it could cause GFX driver crashes too
<hoijui>more easily, no?
<hoijui>giving inconsistent values
<zerver>yeah, if the driver cannot handle NaNs and such
<Tobi>so that is why for some arbitrarily fine/coarse grained object we need to be able to guarantee that sim doesn't mess with it while rendering wants to use it
<Tobi>worst case could be taking a lock on complete sim (silly ofc), better already would be if we could guarantee this per sim object
<hoijui>or some widget or gadget wants to use it
<hoijui>not gadget
<zerver>widgets again
<zerver>thats unsolvable as i see it
<zerver>if Lua rendering wants to draw object X, how can we know about it in the first place?
<hoijui>so there are multiple unsinged parties interested in sycn state (renderer, widgets, AIs) and possibly multiple sim parts updated at the same time (with MT sim)
<hoijui>unsinged=unsynced :D
<zerver>so Lua is maybe the main reason data duplication is the only way
<Tobi>you don't know about it in the first place, but possibly you can learn and assume it will be needed in the next frame too
<Tobi>and just do it the slow way for a few frames in the mean time
<zerver>sounds a bit shaky i must say
<hoijui>and keep statistics of usage of each member of each sim object?
<Tobi>hasn't this been solved many times already or are we really the only engine facing this problem?
<hoijui>is that feasible?
<hoijui>hehe :D yeha Tobi..
<hoijui>good question
<hoijui>i once made a short search
<hoijui>did not find much but
<zerver>a regular game probably would not use data duplication
<zerver>but this is an engine, with lua being the chief complicating matter
<Kloot>side point: aren't all writes atomic for 32-bit datatypes?
<Tobi>Lua is being used in other engines too, e.g. supreme commander
<zerver>yes
<zerver>32 bit aligned writes are atomic
<Kloot>if so, how could one thread read a NaN while another modifies something like unit.pos.x?
<zerver>IIRC
<zerver>it cant
<hoijui>but you can read two values, and divide them
<zerver>but it could read bad floats and make a singular matrix or div by zero or something and...
<hoijui>to get NaN
<hoijui>which may only happen if they are from different states
<hoijui>mm
<zerver>anyway, need to eat
<zerver>we should probably no begin this big refactor yet
<zerver>too many loose ends
<Kloot>div0's should always be guarded against, matrices cannot be singular except in code that inverts them
<Tobi>"If you think you can be clever and avoid locks, don't. You aren't. That's the general "you" which includes me and everybody else." (random quote from stackoverflow.com
)<hoijui>:D
<Tobi>SC uses render split design too
<Tobi>"Rendering and game simulation are synchronized via a minimal-locking queue mechanism; these locks are minor and introduce almost no performance hit."
<hoijui>hmm ok
<hoijui>and lua?
<hoijui>:D
<Tobi>nothing about that
<hoijui>mmm :/
<hoijui>maybe spliff can tell us somethign about lua
<Kloot>probably in SC only game logic can be manipulated through lua
<hoijui>he used to mod SC before commign here
<Tobi>hmm that maybe true yeah
<Tobi>this is where I found that btw: http://www.gamedev.net/columns/events/g ... sp?id=1345
<Kloot>at least I highly doubt it exposes direct3d access to modders
<hoijui>i remember reading that page
<hoijui>ouh await...
<Tobi>hard to find more info
<hoijui>when we want to be able to make sim itsself MT
<hoijui>as in.. multiple Sim threads
<hoijui>we need duplication anyway, right?
<hoijui>as we need a fixed old state to base calculations on
<Tobi>yeah that is true I think
<hoijui>as the order in which the new state is calculated woudl not be determinisitc
<Kloot>question is if we _should_ ever want that :)
<hoijui>yeah
<hoijui>what is a common memory bandwidth these days?
<Tobi>question is then whether complete copy of the sim state costs less then what multithreading gives
<Kloot>personally I've debugged enough sync errors in ST code to know I don't want to ever have to deal with MT too
<Tobi>yeah I have to agree with that
<hoijui>:D
<Tobi>its not that I have had much time now either way, but I think I definitely won't ever look into MT-sync bugs
<hoijui>it shoudl not give more or more complex sync erors..
<hoijui>shoudl even simplify some stuff, as we have a clear old state
<Tobi>I think it will only be simplification if the design is improved; just adding old state won't simplify much
<hoijui>and if we coudl disable data duplication for old machines (single core) casue tey likely have slow memory also..
<hoijui>mm... but i can't see hwo it would make it more complex either
<hoijui>hey jk!
<Tobi>DDR2 has theoretical memory bandwidth of 12.8 GB/s according to wikipedia
<Tobi>*dual channel DDR2
<hoijui>mmm
<Tobi>I would say, if the sim state we want to copy becomes bigger than, say, 25 MB, we're doing it wrong
<hoijui>that shoudl work then...so it is basically moving the performance bottleeck from the CPU to the memory bandwidth, when using multiple states
<hoijui>mm ok
<Tobi>welcome jk
<hoijui>for MT sim, coudl we still not copy everything?
<hoijui>i mean... somewhen, we sure want to have sim MT capable
<hoijui>with eg 32 3GHz cores in 3 years or so
<hoijui>maybe "tag" each member as one of: never copy, copy for unsynced, copy for MT Sim
<Tobi>personally I would rather have better designed sim that's more easily modded first :)
<hoijui>mm ok
<hoijui>sounds good
<hoijui>thats,, moving stuff to superclasses, adding new superclasses if needed and such?
<hoijui>moving rendering code out...
<Tobi>but I don't know if I will have time for any significant contributions anytime soon...
<hoijui>ok
main points:
* todays computers are too slow for some of our ideas
Anything else? (WVTTK)
<hoijui>maybe we shoudl try now to solve the addr2line problem?
<hoijui>maybe try to make a python script wiht only the bare translation line, callign addr2line and a print() of the result
<hoijui>i coudl do that too i guess
<hoijui>are there other ways then using popen?
<Tobi>subprocess module
<Tobi>but if that was an issue you would probably have gotten no output at all
<hoijui>mmm
<Tobi>I'll take a look, indeed something must be wrong
<hoijui>
<Tobi>[ARP]hoijui_g5: did you mean to change stacktrace translator in 7f082dbc36507a313d987f5e2ec0e9f3bf94d8a2 ?
<Tobi>"fix some CppCheck warnings, doxygen comments and some formatting"
<hoijui>ouh sh.. :D sorry
<hoijui>no of course not
<hoijui>should i revert it?
<hoijui>or you
<Tobi>you can do it
<hoijui>quite a stupid way to keep track of temporary stuff :D
<hoijui>ok
<Tobi>:)
<Tobi>I see why it is wrong, it takes the debug symbols for the wrong AI indeed
<Tobi>kinda sucks they are all called SkirmishAI.dll
<hoijui>ahhh
<hoijui>:D
<hoijui>bibim said hte same :D
<hoijui>can this be fixed?
<hoijui>though... i reemmber it also failing for spring.exe since this change (-j .text)
<hoijui>maybe that was only due to the old addr2line?
<hoijui>though you said it worked with all of them, manually
<hoijui>will see
<Tobi>yeah but that manual check was only with the RAI SkirmishAI.dll
<Tobi>not with spring.exe
<Tobi>but I'm gonna eat too now :)
<hoijui>ok.. bon appetit!
