D3D11 Format about spout2 HOT 28 CLOSED

Yes the format of the sharer resource view must match the received texture.

However, this looks like an old version because Tutorial04.cpp in the master branch is different to that shown in your image.
Please try again with the examples in the current master. Version 2.007 does not require "CreateSender" any more. Sender creation and update is handled within the SpoutDX class.

.

from spout2.

However, When the texture format is different from the set format, DEMO/ spoutReceiver.exe will display correctly.
In the case of the receiving end, there is no guarantee that the sender user will get the format right.

from spout2.

Suppose this:

The DEMO/SpoutReceiver. exe will display when the sender has the wrong format, but SpoutDX will not display due to the inconsistent format

from spout2.

If you set the sender format using SetSenderFormat, you should also change the format of the back-buffer texture.

The sent texture format is detected by the SenderTexture function and the sender's information is changed to match. The Tutorial07 receiver will read that format and set the shader resource view to the same format.

If you set the sender format different to the backbuffer texture, the SenderTexture function will detect that difference and re-create the sender using the sent texture format instead. In the receiver you will either get a continuous flashing as the sender is re-created every frame or you may get no received image at all.

It should work OK if you remove that line. Does it fail to receive in your case? Here I can't find any problem.

from spout2.

SetSenderFormat is called specifically to simulate a scenario where the texture sent by the sender does not match the format. Just to show that DEMO/SpoutReceiver.exe works,SpoutDX doesn't.

from spout2.

Because I cannot control the data sent by the sender and the format, I can judge whether the data sent by the sender is normal or not by DEMO/SpoutReceiverexe, but the problem is that DEMO/SpoutReceiver.exe can be displayed normally. The receiver inside SpoutDX will display incorrectly due to the different format

from spout2.

master: root\SPOUTSDK\SpoutDirectX\SpoutDX\Tutorial07
This latest DirectX receiver doesn't seem to receive any data, even in the correct format

from spout2.

I don't think the sender should send the format and width of the texture, these information can be obtained from the texture, I think it is more reliable to get the format from the texture than using the user set format

from spout2.

First of all, forget about the Spout Demo Receiver. It's OpenGL and the driver adapts to different D3D11 texture formats.

You are correct. The sender does not need to send the width, height or format of the texture. The receiver can retrieve this information using "GetDesc".

You say that the "latest DirectX receiver doesn't seem to receive any data, even in the correct format".

Please confirm that you have removed the line you added :

sender.setTextureFormat(DXGI_FORMAT_R8G8B8A8_UNORM)

If this is removed, the receiver will detect the sender format and adjust the shader resource view to match.

I can't fault it here.

from spout2.

thanks, I use DEMO/ spoutsender.exe as the sender and master\SPOUTSDK\SpoutDirectX\SpoutDX\Tutorial07 as the receiver. The receiver cannot display the image of the sender

from spout2.

I just went home and took the home computer to test that it was normal. I will go to the company tomorrow to check. I'm sorry

from spout2.

I redownloaded a copy of the code on the Master branch to confirm that no changes were made, but the company still did not receive any images on this computer

from spout2.

I don't see frame-rate displayed on the Spout Demo sender window, so this could be an older version. Please download the latest update Spout 2.007f here https://github.com/leadedge/Spout2/releases.

Open the new copy of SpoutSettings to confirm that your settings are the same. Close it and use the new version of the demo sender. "Help > About" should show Version 2.047. Now you should see the fps and frame number displayed.

After testing with the latest demo sender, open SpoutSettings again and check "Threaded optimization" OFF. I have had problems with this set to Auto.

If "Spout Demo Sender -> Tutorial07" works OK on the home computer, is Tutorial04 also received?

If you are testing with two computers, there could be a difference with the hardware and drivers.

In SpoutSettings. Click "Diagnostics", then "Copy" and paste the results here for both computers so that we can see any differences.

Finally, to see any error messages, enable line 141 in Tutorial07.cpp

EnableSpoutLog(); // Enable Spout logging to console

from spout2.

If the sender is changed to the sender in 2.007 F, it is normal, and the sender in 2.006 used before cannot receive the image

(1) Is this reasonable?

(2)2.007 demo/receiver is normal, OpenGL receiver and D3D11 receiver are different?

(3) I did not test whether I received Tutorial04 on my home computer yesterday, and the Sender used in the test last night was DEMO/ sender.exe in master, not version 2.006

(4) I plan to upgrade the SDK of SpoutDX in the near future. Which version of SDK is worth recommending

from spout2.

I see that the Demo Sender reports a laptop GPU. If this is the case, you should select NVIDIA "High Performance" in SpoutSettings and check that in your NVIDIA control panel this setting is global and not application specific.

The log from Tutorial07 is normal and the received texture format is 87 (DXGI_FORMAT_B8G8R8A8_UNORM) as expected from the OpenGL sender.

SpoutSender.exe in master is up to date - Version 2.047

When you use the 2.006 demo sender, I suspect a driver problem. When the Sender starts, it switches the system to memoryshare mode where images are transferred by shared memory instead of textures. Tutorial07 will then not have any texture to receive. The 2.006 demo receiver will receive images by shared memory and appear to be OK.

Memoryshare is removed in 2.007 and shared textures are always used. If you still have problems, there could be other driver issues. If you copy/paste the diagnostics from both your computers here we might be able to confirm that.

2.006 is retained only for applications that already use that code and cannot be changed. Do not use it otherwise.

Master and Beta are even at the moment so it does not matter which one you choose. There are some updates to come for the beta branch but they are minor.

from spout2.

(1) It seems that the settings are high-performance processors, but there is still no image
(2) If Memoryshare is removed in 2.007, and some users’ computers set the sharing mode to Memoryshare via Setting, will the new version of SpoutDX fail to receive textures?
(3) If there is a difference between the OpenGL/Direct3D receiving end, we cannot use DEMO/SpoutReceiver.exe as the basis for verifying whether the user sending end is correct. Is there any other way to verify whether the user sending end is normal?

from spout2.

If a user sets 2.006 memoryshare mode there is no effect for a 2.007 application. But then a 2.007 application will not share images with the 2.006 application.

Yes - OpenGL and DirectX receivers are different. OpenGL Spout applications use the GL/DX interop. The graphics driver handles copy between OpenGL and the shared DirectX texture. DirectX applications use the shared texture directly.

I see that you are still using the demo sender version 2.018. This is a 2.006 application. Please try again with the latest version 2.047.

If that works I think I know the problem. A 2.006 sender does not produce frame count information, so the 2.007 receiver will not detect whether the frame is new. You can confirm this changing line 938 :

// if (receiver.IsFrameNew()) {
etc.
etc.
// }

The default condition is one of the changes made recently but there has not been a new release yet. Download the complete repository and use the source files from that rather than the release zip file.

from spout2.

2.047 As the sender, the message can receive the image normally

2.007 The receiver comments out whether the detection frame is new and can receive the image, you are right

There is also a question that will not use the width and height of the format sent by the sender in the future version?

from spout2.

But then a 2.007 application will not share images with the 2.006 application.
Will the new version be compatible with the old version, or must the sender also be 2.007+

from spout2.

Yes - OpenGL and DirectX receivers are different. OpenGL Spout applications use the GL/DX interop. The graphics driver handles copy between OpenGL and the shared DirectX texture. DirectX applications use the shared texture directly.
If SpoutDX is used as the receiver, how do you verify that the sender is correct

from spout2.

Currently we have a problem with the texture and format mismatch sent by the sender, so I simply changed the code

from spout2.

OK I will look at this. Currently, the texture size and format is tested in ReceiveSenderData() if the sender texture share handle is different and globals are re-set.

Your questions -

Will the new version be compatible with the old version, or must the sender also be 2.007+
If SpoutDX is used as the receiver, how do you verify that the sender is correct

With the current code in the master branch, a DirectX receiver will ignore frame count information and receive the DirectX texture as usual.

There is also a question that will not use the width and height of the format sent by the sender in the future version?

The receiving texture has to be the same as the sender so I am not sure of what you mean here.

from spout2.

With the current code in the master branch, a DirectX receiver will ignore frame count information and receive the DirectX texture as usual.
Does the main branch refer to this? I still detect a new frame when I see it here
https://github.com/leadedge/Spout2/blob/master/SPOUTSDK/SpoutDirectX/SpoutDX/Tutorial07/Tutorial07.cpp

There is also a question that will not use the width and height of the format sent by the sender in the future version?
Is this the interface that will be removed void SetSenderFormat(DXGI_FORMAT format);

from spout2.

Yes that is the one to use.

But you also need to use the master branch version of SpoutGL/SpoutFrameCount.cpp. You will see that "m_bIsNewFrame" default is true.

SetSenderFormat remains for compatibility with older code but it could be removed in future.

from spout2.

This code only changes the default values, but the receiver will also fetch the new texture based on the frame count.
If you do not make this change, you will still not receive the 2.006 screen
// if (receiver.IsFrameNew()) {
etc.
etc.
// }

https://github.com/leadedge/Spout2/blob/master/SPOUTSDK/SpoutGL/SpoutFrameCount.cpp

from spout2.

2.006 applications do not have any frame count information.

If "m_bIsNewFrame" default is true, receiver.IsFrameNew() will return true and the subsequent code will be processed.

A 2.007 application can disable frame counting. In future revisions I might make frame count permanent, but it does consume time. It depends on what the application does to process the frame and how long that takes. So at the moment you can disable to find out.

from spout2.

Okay, thank you very much!
Looking forward to your modification.

from spout2.

I have moved these changes from Beta to Master branch. I have also restored the "Frame count" option in SpoutSettings and prepared a new user release. These changes should resolve the 2.006 incompatibility problems. Of course, further report is welcome if you have any difficulty with this or find other problems.

from spout2.