devkitpro / deko3d Goto Github PK

https://github.com/devkitPro/deko3d/blob/master/include/deko3d.hpp#L83
lhs.m_handle gets overwritten with rhs.m_handle and destroy is never invoked.

There is an ongoing motivation to port moonlight for the switch e.g. XITRIX/Moonlight-Switch. It already works quite good but one thing that is still missing is gpu accelerated video decoding, mainly through NVDEC, which currently is not reverse engineered for switch homebrew. Could deko3d be of any help in this regard?

I'm interested in switching from OpenGL to Deko3D.

I've made a test project with the exact same shaders, code and directory setup as the deko_basic example. Yet, when i start up the game it just shows a black screen. I'm using the default settings of Yuzu. Is the problem coming from Yuzu or Deko3D?

Would it be possible to grant dkCmdBufCopyBufferToImage the ability to copy multiple image layers? vkCmdCopyBufferToImage can do it with imageSubresource.layerCount > 1. The process is similar to copying 2D slices of a 3D image which it already looks like dkCmdBufCopyBufferToImage can do.

Edit: Actually it looks like the z and depth parameters of DkImageRect can double up for selecting a layer range (in a 2D image anyway, not sure about the 1D case). Is my observation accurate here?

Hello @fincs, Recently I've been investigating the problem of deko_basic not drawing properly in yuzu.

Then I found that the generated macro jit did not call the send function.

Can you provide the macro jit assembly data generated by deko3d?

Long Time No informations :/

This issue seems to be very weird. For some reason textures with a size of 32*8 pixels display wrongly. Instead of the right 16*8 pixels it reads from something else (it's noticable in situations where there are more textures around).

To reproduce it's enough to change this line in the textured cube example: https://github.com/switchbrew/switch-examples/blob/master/graphics/deko3d/deko_examples/source/Example04_TexturedCube.cpp#L189

to

texImage.load(*pool_images, *pool_data, device, queue, "romfs:/Unbenannt.data", 32, 8, DkImageFormat_RGBA8_Unorm);

here is the texture data I used:
Unbenannt.zip

This is the result:

Note that if the height is reduced to 4 pixels, everything works fine (except ofc that only the first 4 lines of the texture are used):

The texture transfer seems to work fine, I already tried retrieving the texture data from vram.