Synced --> UnSynced Mess... help plz

[Argh]

The issue:

Every gameframe, I need to write a bunch of data to a synced table that's global.

On the unsynced side, I need to access that data by iterating through the table with spairs and use it to write exactly ONCE to another area.

How do I prevent unsynced from writing to that other area more than once while waiting for the next gameframe?

[aegis]

what exactly are you trying to do? anything wrong with using something like SendToUnsynced to write it?
if you trigger the write from an event, it will only happen once per gameframe

[Argh]

On the synced side:

Code: Select all

local myList  = {}
gadgetHandler:RegisterGlobal("myList", myList)

function gadget:GameFrame()
--do some logic
	if foo == 1 then
		myList[#myList+1] = {blah = 1, blah2 = 2, blah3 = 3}
	end
end

On the unsynced side:

Code: Select all

DrawGenesis()
local myList = SYNCED.myList

glActiveFBO(fbo1, true, function()  -- START PARTICLE FBO
	--do some graphics stuff

	for i,k in spairs(myparticleList) do 
		--do some more graphics stuff, using k.blah, k.blah2, etc.
	end
end

end

[Argh]

anything wrong with using something like SendToUnsynced to write it?

Yes. I was using a local table to collect those events. Then I found that I was having sections of the table overwritten even as they were being written in the DrawGenesis() function. There are two FBO loops; the first one had the right data... the second one did not (and it was obviously getting overwritten). And no, I can't use just one FBO (I wish that wasn't true, but there's a strict limit of 4 texture-writes in GLSL).

Hence wanting to keep the table in synced land and forcing all Gadgets to write to it in strict order.

[aegis]

still unsure what you're asking.

[Argh]

I'm asking, "how the heck do I prevent that unsynced code from reading that synced table multiple times and re-writing that data". I only want it to happen once per gameframe, it isn't cheap.

Unsynced can't write to a synced table to erase it; so... I need a flag or a signal of some sort that prevents it from reading the table again until the next gameframe, basically, or a way to erase the table after I am 100% sure that unsynced has gotten to use its contents.

The problem is, I'm not sure how synced is supposed to tell unsynced to lock / unlock an operation (i.e., we're all done writing to that synced table for this frame, you're now allowed to read the data).

[jK]

as aegis already said, use SendToUnsynced when you write to the table.

[Argh]

But it's overwriting the table as it's getting written in DrawGenesis()... the table changes between the first and the second time it iterates through it, causing errors. Which is why I'm looking for another solution here. If the table wasn't able to be touched by anything else while I was performing actions in DrawGenesis(), that would solve the problem, but I can't seem to find any method in Lua that explicitly allows me to lock a table and prevent write access.

Look, this problem only comes up when I'm sending hundreds of messages (I wish I could just send the entire table in one message, that'd make things a lot more straightforward)... is there some sort of upper limit on SendToUnsynced that's causing the problem?

And how is the unsynced side supposed to tell the synced side that it's written the entire table's contents and it is ready for the next batch? After all, I don't want that table cleared on the unsynced side until it's 100% done.

[jK]

Unsynced side CANNOT override anything in SYNCED.

And nobody said that you should send any data with SendToUnsynced, you should just use it to trigger the event in the unsynced side (which reads the table from the SYNCED metaobject).

[Argh]

What I'm telling you is that SYNCED is causing UNSYNCED tables to get overwritten. Not the other way around.

[Argh]

And nobody said that you should send any data with SendToUnsynced, you should just use it to trigger the event in the unsynced side (which reads the table from the SYNCED metaobject).

OK, so basically just send a message that says, "hey, we're all done writing for this frame"?

OK.

[Argh]

Code: Select all

popsList = {}

if (gadgetHandler:IsSyncedCode()) then
function gadget:Initialize()
	gadgetHandler:RegisterGlobal("popsList", popsList)
end
end

Code: Select all

function gadget:GameFrame(f)
popsList[#popsList+1] = {1,2,3}
end

The following in two Gadgets results in 'can't get length of global 'popsList' (a nil value)'. So, eh... wtf. I've declared it global, what else do I need to do?

[aegis]

why does iterating through the table change it?

[Argh]

It's not. It's getting written to while the unsynced operation in DrawGenesis() is operating- it takes some time to return from each FBO process, and while that's happening, the data's getting overwritten somewhow.

I can run the two FBO events every time a new synced event occurs, because that's really expensive- 'opening' a FBO is a very expensive operation. So I have to queue it, and run it when there are a lot of events ready to go. Hence the problem. If I could squeeze it all into one FBO, I'd do so, but I can't do that, either, because I have to write to 8 textures, and GLSL won't let me write to more than 4.

Maybe if I put it all in a BeginEnd...

[Argh]

No, that certainly doesn't work.

However... I have proven that it's overwriting the data.

If I structure the code like so:

Code: Select all

if #table > 2 then
for i,k in ipairs(table) do

glActiveFBO(fbo1, true, function() 
--do stuff involving i or k
end)

glActiveFBO(fbo2, true, function() 
--do stuff involving i or k
end)
end
end

...then it all works perfectly. But it's really slow

[aegis]

can't copy to a temporary local table just for the fbo process?

[Argh]

I tried that, it just seems to reflect the changes in the table during the process. It seems like that should work, that's the intuitive thing... but it doesn't.

That said, by getting rid of ipairs, since everything's getting written in exact order (1,2,3) anyhow, I should be able to speed it up again to the point where it's not terrible. There may be other speedups, too- maybe I can write a single shader that has a switch activated via uniform, so that there's only one shader call for the entire thing. That might give me enough speed back to make it moot, idk. I'm just glad I've finally found something that works, this has been driving me crazy since I got the texture-atlas stuff working.

[Argh]

Meh. Even combining the shaders didn't make enough of a dent. glActiveFBO is really expensive

However, maybe combining them and getting rid of that overhead will speed things up enough that a local copy won't get overwritten before it finishes.

[Argh]

Nope. Speed's back, but it's right back to the same errors. This sucks. Double-tried a local copy... total fail.

What's gl.RenderToTexture good for, btw? Maybe that's another way to attack the speed issue...

[aegis]

you need to do a deep copy to isolate