Forum

SharedTexture broken in current alpha29?

vvvv beta bug
#1

Dear devvvvs,

as I was trying to share a texture from a Direct3D11 application with vvvv, it didn’t work. At first I thought I was doing something wrong, such that D3D9ex applications couldn’t open the shared texture.

Then I tried receiving the same shared texture in beta28.1, and everything works like a charm.

Also, when I share a texture FROM vvvv with a Direct3D11 receiver, the receiver would successfully receive and display my shared texture, whereas 4 times out of 5, the ‘SharedTexture connected to a quad’ that I put in the same patch as the one I am sharing the texture from (just for checking), wouldn’t show.

Since the other application successfully uses that same shared texture, it feels as if the SharedTexture node has a bug introduced somewhere.

opening with /allowmultiple /dx9ex in alpha29.x gives white output most of the time, works flawlessly in beta 28.1 (12.9 kB)

#2

interesting…
i indeed had to fix something there as i found it not working every other time (when the the handle was to big). your patch works for me in any case…i am reloading it and it always still works, no matter what the handle is.

do you get tty output when it does not work? can you see a relation between handle-number and times when it is not working?

but also strange…i don’t get it to fail anymore with b29 as it used to before i added the fix…

#3

I was wrong,

I do have the same problem in beta28.1

There’s no relation between big and small handles, it seems that, when it works the first time, it will work every next time (if I add more slices). When it returns an all white texture, the first time, everything will keep failing afterwards.

It’s often when opening a patch (I open it with setpatch most of the time as you can see in the Wyphon examples in the other thread, don’t know if that matters). Then if I create a new SharedTexture node, connect all outputs from the Wyphon receiver node (handles last, if that matters), and then connect all of that to the quad, it starts working most of the time, so it feels like a initialization thing…

#4

hm…so could you please try to make a very simple example that reproduces the problem for you. possibly without wyphon stuff so we keep it debuggable.

#5

Hey Joreg,

the example in my first post reproduces it for me, but as I said not always.

but there’s also this in tty:

00:01:24  *  : can't draw whole geometry at once: * for example you have spreaded a texture / renderstate / texturestate.. switching to slicewise rendering.
#6

hm… that tty warning is not related. still cannot reproduce…
but so you say anyway that b28.1, b29 and a29.1 all show the same behaviour for you?

#7

Yes, with the patch I posted here earlier.

Sometimes it does work though…

Edit: sorry let me check if I haven’t mistakenly sometimes started without dx9ex…

Edit2: now I can only see this behaviour in alpha29.1, 9 times out of 10 (the one pulled via git), so the ‘problems’ in 28 and 29 could have been me forgetting to start with d3d9ex

#8

k. so i do:

can you please do the same and report?

#9

Now I can’t seem to reproduce.

Let’s assume for now my local repository got messed up somehow, unless someone else reports similar problems…

© vvvv group