Mac os support

[tothbar]

the project looks awesome, im just curious if a mac os port comming in the future?

[Sphynxcolt]

Of course he plans mac support, but right now, the focus is on windows. No one can tell when.

[iami0]

is waiting for Mac version also . plzzzzz'.

[tanis2000]

Porting to macOS would require quite a lot of work as this project seems to be relying on DirectX. It would at least need a port to OpenGL or Metal. And a rewrite of the shaders. At the very least. And that's not a quick task.

[pixtur]

Yes. A MacOS version would be incredibly awesome. This is a long term goal for the project. I wrote some thoughts on that topic in the FAQ.

My hope is, that once the project gets a stable footing on Windows it might attract contributers that get their hands dirty on the Vulcan port.

[tanis2000]

I read the FAQ you wrote and yeah you are totally right that it would be real hard and time consuming to port from D3D to Vulkan. Vulkan requires you to setup your render passes and pipelines. For something as dynamic as this tool it could get complex quite quickly as you would have to create them dynamically every time you mess around with nodes.

On top of that, it would also be awesome if the player could run in the browser. But that would make it even more complicated. At the very least it should support either WebGPU or WebGL. WebGPU is closer to Vulkan, but it is still a different API.

[pixtur]

To be honest, for weg-gl exports cables.gl is probably a better tooll.

[enzyme69]

2022 and no Mac M1 version, sadly I actually wanna try ...

[christo]

It seems fair to say that there is no timeframe estimate nor commitment to implement cross-platform support ever.

This is not intended to be a criticism, just an attempt to realistically summarise the way the cost-benefit tradeoff appears now and by extrapolation, how it will continue to appear unless something fundamental changes. Making Tooll better on windows is always going to be an alternative to rewriting core elements for a cross-platform delivery of the same feature set. Doing that work instead is also likely to introduce a permanent additional maintenance and testing overhead. It's not clear what could significantly change the priority of this large undertaking, if anything.

Put another way, what number of "me too!" comments on this issue would get it on the roadmap for version x.0? Perhaps there's no such number? Would it take a new, committed side team to make it happen? Would it not be easier to make a sister project from scratch that borrows the design paradigm and tries to independently build that alternative framework which would remain at arms-length like Processing and P5.js do?

I offer the above summary to help people who wander in here avoid disappointment and also to avoid that awful train crash of whining comments repeating still not done!? Some people, myself included, may say "never say never" but frankly other people find that overly optimistic and misleading. No dev team likes to feel the negativity that comes from such comments on long-term open feature requests and I wouldn't want the Tooll 3 team to have a polluted experience of the adoration and admiration they clearly deserve.

For the record, Tooll 3 looks fantastic. Well done team. Yes, I wish it would work on Linux and MacOS but my experience tells me not to hold my breath. I'd be delighted to be wrong about this.

Thank you @pixtur for directing those interested in a web-gl Tooll to consider cables.gl instead. That also looks fantastic.

<3

[pixtur]

@christo that's a good summary. I am convinced that a cross platform port based on Vulcan is feasible and together with a packaging system would lift Tooll3 onto a new level indeed. It would be definitely break backwards compatibility but I you knew what you're doing, it should be possible to do in a couple of months.

But on the other hand, I KNOW that there is no possible way this could be done with the current team (Which is basically me and a handful of other enthusiasts). My hope is that eventually motivated and experienced Vulcan and .net developers will join the effort to build help with this.

[JadeGeek]

How about game porting toolkit from Apple, it looks like can run DirectX 11 and 12 app very smooth, will you guys check it out? https://developer.apple.com/games/

[reahari]

@JadeGeek probably not helpful that their tools aren't open source

[tanis2000]

How about game porting toolkit from Apple, it looks like can run DirectX 11 and 12 app very smooth, will you guys check it out? https://developer.apple.com/games/

I will probably check that out once Sonoma gets out of beta. It doesn't really matter whether their tools are open source or not. As an Apple Developer you can access those tools and use them as much as you want. And anyone can become an Apple Developer even without a subscription. It's really not an issue.

[pixtur]

That would be sooo awesome. I had a quick look at the game porting toolkit and it actually looks promising.

[tanis2000]

I do not have much time at hand but I will probably try that out over the next weekend. I will keep you posted with my findings.

[tanis2000]

It looks like 3.7.1 can kind of start but it fails badly when compiling compute shaders when using the game porting toolkit. here is a slice of the log:

Loading symbols...
0234:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 0000000001D258A8, 40) stub
026c:fixme:virtual:NtFlushProcessWriteBuffers stub
0234: thread_get_state failed on Apple Silicon - faking zero debug registers
0274: thread_get_state failed on Apple Silicon - faking zero debug registers
0274: thread_get_state failed on Apple Silicon - faking zero debug registers
026c: thread_get_state failed on Apple Silicon - faking zero debug registers
0278: thread_get_state failed on Apple Silicon - faking zero debug registers
0274: thread_get_state failed on Apple Silicon - faking zero debug registers
0274: thread_get_state failed on Apple Silicon - faking zero debug registers
0274: thread_get_state failed on Apple Silicon - faking zero debug registers
Registering loaded symbols...
Applying symbol children...
0234:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 000000000D674AC8, 46) stub
0274: thread_get_state failed on Apple Silicon - faking zero debug registers
0294: thread_get_state failed on Apple Silicon - faking zero debug registers
0274: thread_get_state failed on Apple Silicon - faking zero debug registers
0294: thread_get_state failed on Apple Silicon - faking zero debug registers
Loading Symbol UIs...
026c: thread_get_state failed on Apple Silicon - faking zero debug registers
026c: thread_get_state failed on Apple Silicon - faking zero debug registers
026c: thread_get_state failed on Apple Silicon - faking zero debug registers
0234: thread_get_state failed on Apple Silicon - faking zero debug registers
Debug: Found no output ui entry for symbol child output 'DataSet' - creating a new one
Warning: Assuming default output position
0274: thread_get_state failed on Apple Silicon - faking zero debug registers
Error: Shader error: Resources\lib\img\internal\render-volume-slice-cs.hlsl:2:1: E5000: syntax error, unexpected NEW_IDENTIFIER
 'render-volume-slice': Resources\lib\img\internal\render-volume-slice-cs.hlsl:2:1: E5000: syntax error, unexpected NEW_IDENTIFIER

Using previous resource state.
Warning: Failed to create compute shader 'render-volume-slice'.
026c: thread_get_state failed on Apple Silicon - faking zero debug registers
Registering Symbol UIs...
Updating UI entries...
Debug: Found no output ui entry for symbol child output 'DataSet' - creating a new one
Warning: Assuming default output position
Creating home...
Error: Shader error: Resources\lib\img\internal\resolve-multisampled-depth-buffer-cs.hlsl:1:1: E5000: syntax error, unexpected KW_TEXTURE2DMS
 'resolve-multisampled-depth-buffer': Resources\lib\img\internal\resolve-multisampled-depth-buffer-cs.hlsl:1:1: E5000: syntax error, unexpected KW_TEXTURE2DMS

Using previous resource state.
Warning: Failed to create compute shader 'resolve-multisampled-depth-buffer'.
0234:err:virtual:virtual_setup_exception stack overflow 2816 bytes in thread 0234 addr 0x6811c52b stack 0x20500 (0x20000-0x21000-0x1a0000)
0288:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
0280:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
0284:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
0294:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
0278:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
0274:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
026c:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet

Do you happen to know which version of d3dcompiler_xx.dll is required by Tooll3?

[pixtur]

Wow. That's already great progress! Are you sure, that 0234:err:virtual:virtual_setup_exception stack overflow is related to the shader pipeline? I'm surprised because the render volume slice shader is an outdated, non-essential experiment. Normally, shaders don't get compiled before usage, which would be after the "Create Home..." line...

Here is what dotpeek says:

(d3dcompiler_47.dll?)

[tanis2000]

you are probably right. I believe the shader does not compile and just gets ignored (actually both of them as there are two failing) but then further down the line something else breaks but there is no stack trace to look at. I will try to see if there is any way to get some more debug output