Where's MT Going?

[zerver]

It's offtopic alright

still you choose to ignore it

Not the way I see it, because I corrected the problems you and tobi outlined, which was people not being able to test and work on their current mods. People can work on their current mods, using the single thread build.

Cool! Now do the same for S44, GRTS, EvoRTS, KP, Cursed, CA!

The LUPS fix is probably a copy-paste thing. No guarantees, but send your mod to me and I'll try to fix it...

[hoijui]

it was more about us engine devs not being able to run the engine without modifying mods. the main argument though, is that we do not agree on your way being the right way. it has to be a branch.

[smoth]

Cool! Now do the same for S44, GRTS, EvoRTS, KP, Cursed, CA!

The LUPS fix is probably a copy-paste thing. No guarantees, but send your mod to me and I'll try to fix it...

That would be over 100 files counting only gadgets and widgets. Not counting all the other crap in gundam. I am not sure if you realize how dependent gundam is on lua.

[zerver]

If I change it so that dual/single state is a mod setting, are you satisfied then?

[smoth]

Why? It pretty much means I get penalized for not being ba. Something that happens enough as it is.

[hoijui]

no. if we later agree on your way not being the right one, but people already using it, and it being woven into the engine.. that is bad. it has to be a branch.

[zerver]

Then lets decide this at next meeting, because I want to continue adapting BA for it.

[hoijui]

you can do that if it is in a branch too.
sure we can discuss it then, but there is no way around it being a branch. if half the team thinks it should be a branch, it should be a branch.

[AF]

What should I know fi Im considering starting a lua based project involving rendering in order to make sure my code isn't going to need major refactoring in 2 or 3 months time to support any multithreading that may result?

[smoth]

you wont know!

[jK]

What should I know fi Im considering starting a lua based project involving rendering in order to make sure my code isn't going to need major refactoring in 2 or 3 months time to support any multithreading that may result?

It would not just affect lua code that affects rendering.
Nor would it solve the performance problems in spring-mt, but what I am talking, no one is listening to me ...

[AF]

I am, but Im just thinking that what would you advise if starting afresh to minimize the need for changes/refactors in the future? Any apradigm or rules we should follow which may be preferable but unnecessary right now but come in veyr handy or required in future?

[jK]

No, I would start fresh because zerver makes it impossible to work on the current code base. My advises are for short term, mid term and long term.

short term
* give LuaHandleSynced an own unsynced LuaState
* give all unsynced LuaStates a event/job queue, to parallelize synced events (GameFrame, UnitCreated, ...).

mid term
add a very basic type of a job queue and parallelize some time intensive things as LOS update & shadow/reflection pass rendering

long term
* extend the job queue and begin to parallelize things all over the engine (sim & unsynced & rendering)
* make copyable sync-state & use a scenegraph

[zerver]

No, I would start fresh because zerver makes it impossible to work on the current code base.

If you think I have put the split in the wrong place (LuaHandle) then think again. Also look at this ~20 LOC commit that changes the behavior into exactly what you want.

http://github.com/spring/spring/commit/ ... 7efc7063d6

Now we just add the job queue, I'm supporting it as long as the queue is entirely on the C side (never touching Lua stuff). The event queue must be cleaned from invalid items in DeleteUnit() etc. The queue should also be implemented for LuaHandleSynced so that the events reach both the synced and unsynced sides.

[KDR_11k]

This example shows changes needed to LUPS in BA 7.19 to support dual states.

You should probably use CA as your Lua testing platform, it's the de-facto Lua repository.

[zerver]

Yeah, CA shows that this EXPORT table does not work without some tweaking. ~5000 exported elements slows down the game to a crawl. One trick is to set the data to nil immediately after SendToUnsynced.

[Forboding Angel]

... but what I am talking, no one is listening to me ...

Oh yes we are, but unfortunately there isn't a whole lot that we can do other than sit on the sidelines and wait it out :-/