CustomShader not recognized by TrueSpace

[zzador]

Hello everybody,

I'm currently working on a complete SDK bundle (Mingw32 Compiler, TSXAPI & IUP (GUI-Lib)) for quick & easy developement of Extensions & Shaders. Compiled TSX-extensions working fine so far but I have problems with the shaders. Regardless of the shader I build they get never recognized by TrueSpace (i.e. the never show up in the shader lists). Inspection of the generated DLL shows that like in all the working shaders there is only one export:

Code: Select all

LIBRARY "GlossyShader.tss"
EXPORTS
tsxShaderInitialize

However "tsxShaderInitialize" never gets called!

Shader is located in folder [ts4dir/SHADERS/MATERIAL]

The shader is also linked against "tsxapi.lib", the arch is x86 (not x86-64) and all resources are correctly included.
I tried nearly everything now. I even tried another compiler (PellesC) but the same problem here.
I'm a little bit lost here. What am I missing?

[borgcone]

... Regardless of the shader I build ...

Is there any difference between your dll and the sample dll in SDK (i.e. CustomColor.dll)?
I'm not so familiar with custom shaders. If I would be in the situation you are in, I would check using the SDK sample source codes, the already built dll, its location, and its exported symbols, etc.

[zzador]

Yes, I already did that. I used the already packaged TSS (Planet.tss and Spots.tss) which are colorshaders. They both export only one symbol:

Code: Select all

LIBRARY "Planet.tss"
EXPORTS
tsxShaderInitialize

Code: Select all

LIBRARY "Spots.tss"
EXPORTS
tsxShaderInitialize

For the sample shaders in the SDK I could not compile as intended cause I'm an avid enemy of Microsoft's Compiler package (e.g. VC++) but I managed to compile it under MinGW32-GCC and PellesC. The normal TSX-Extensions from the SDK are compiling & working fine in TS4.3. It's only the shaders and the mere fact that Truespace seems to have no error-log and even doesn't throw an error at startup makes the problem very hard to solve imho.

[borgcone]

Shader is located in folder [ts4dir/SHADERS/MATERIAL]

Did you try upper/lower case for the folder name?
trueSpace Custom Shaders.doc (ver. 4.2.) in the "sdk_ts43g2" says:

Custom shaders must be copied into following subdirectories of the trueSpace directory (directory where tS is installed):
“Shaders\Material” - material shaders
“Shaders\Global” - global shaders

[trueBlue]

Shader is located in folder [ts4dir/SHADERS/MATERIAL]

Did you try upper/lower case for the folder name?
trueSpace Custom Shaders.doc (ver. 4.2.) in the "sdk_ts43g2" says:

Custom shaders must be copied into following subdirectories of the trueSpace directory (directory where tS is installed):
“Shaders\Material” - material shaders
“Shaders\Global” - global shaders

Note also the use of backslash \

[zzador]

Renaming the shader directory changed nothing. Truespace "sees" his own bundeled shaders in the directory and shows them within the app (planets.tss, spots.tss and CustomChecker.tss). If I remove one of them they won't get shown in the app. So Truespace definetly traverses the right folder. The path-slashes where just typed by hand and I used the wrong ones.

Update: I got a customshader compiled with MinGW32 working "halfway". I made a super small Color-Shader without any dialog (GUI-interface) and gave it the name "my_color_shader". I then moved the bundeled shaders (planets.tss, spots.tss and CustomChecker.tss) to a Backupfolder and only placed my testshader.tss in the "Shaders\Material"-Folder. After Start Truespace has found my shader and I can use it but it is shown with the wrong name "Custom Checker" instead of "my_color_shader". The String "Custom Checker" is nowhere located in my testshader.tss so it must come from Truespace since the removed shader had that name.

I'm starting to believe Caligari did some evil magic when implementing the custom shader dll interface. Instead of a simple call to LoadLibrary() and GetProcAddress() they might checking if the DLL has a special structure before they load it.

[borgcone]

I experimented/checked a bit today. The result below might not contribute for the right solution. My insufficient understanding and the difference between environments might rather mislead to increase confuse. Just for your information.

The already-built SDK sample "CustomColor.dll" was not recognized (i.e. its icon with caption "Custom checker" is not added in the shader lists) by tS4.3, tS5.1, and "tS6.6 of tS7.61" . My environment in Japanese could add unnecessary noise to the result, though.

I got the same result even if its name is CustomColor.tss". (The document says; "a special file extension is not required but there is used *.tss by default")

I checked today:
- SDKs that don't have the already-built CustomColor.dll: sdk_ts41, sdk_ts42, sdk_ts51, sdk_ts52, sdk_tS60, sdk_tS65, sdk_tS66, sdk_tS761B8
- SDKs that have it: sdk_ts43g2

So only already-built DLL I used is; sdk_ts43g2\Samples\Shaders\CustomColor\Debug\shaders\CustomColor.dll

- My tS4.3-trial-Japanese didn't have the "Shaders" folder initially. I made it and a subfolder "Material".
- My tS5.1-trial-English (expired) has only "Spots.tss" in the "Shaders\Material\" folder.
- My tS5.1-Japanese also has only "Shaders\Material\Spots.tss". Its icon with caption "Axion Spots Shader" appears in the color shader list (and it gives pattern like cow). After I removed the Spots.tss from the "Material" folder and restart the tS, actually its icon disappears from the list. After I restored the file, the icon appears again. However adding the already-built CustomColor.dll (or renamed "CustomColor.tss") causes no change.
- My tS7.61 has two TSS file (Spots.tss and vomatshader.tss) and four LUA files in the "tS\Shaders\Material\" folder. The Spots.tss's appearance and function are same with tS5.1. Removing and restoring Spots.tss (followed by tS restart) also behave as with the tS5.1.

I'm using tS cores below:
- tS4.3 trial version (Japanese, named "trueSpace PRO". I don't know the difference between it and the English version.). Windows Vista Ultimate SP2.
- tS5.1 trial English version (expired). Windows Vista Ultimate SP2.
- tS5.1 (product version in Japanese, named "trueSpace REAL". I believe it is tS5.1+ConversionPak.). Windows 8.1
- tS7.61 installed in "C:\". Windows 8.1

Another (irresponsible) guess. The interface of its property panel (dialog) could disturb the recognition?? I recommend you try to separate (remove) code of right-click callback.

2.7 Sample code
2.7.1 Using custom checker
Behaviour of the custom checker shader is similar to built-in shaders, i.e. it has one property panel (dialog) which contains its parameters. This panel can be displayed by rightclicking on the color shader preview. Parameters of the shader are: even color, odd color, size. Click on the colored button in the panel to change color ? Windows common color dialogbox will be displayed. Size parameter can be changed using the keyboard only. To register changes press “Apply” button.

[borgcone]

Oops sorry, ignore my paragraphs (especially about dialog).

The String "Custom Checker" is nowhere located in my testshader.tss so it must come from Truespace since the removed shader had that name.

The string "Custom Checker" is defined in the SDK sample source "sdk_ts43g2\Samples\Shaders\CustomColor\CustomColor.rc".

(Edited to add)
Sorry, ignore also my redundant line "The string ... defined in...".
As you said, It seems that something is caching the name. Loading/executing something twice from your code does not bring happier result?

[zzador]

Yes, you're right. After some inspection I could locate the name "Custom Checker" in the Resource-File "customcolor.rc". Changing that name also changes the name that is shown in Truespace. Strange cause I already provide the shadername in "tsxShaderInitialize".

Here is my current update:
I got the TestShader now fully working WITHOUT GUI. Once I link against IUP.lib (GUI-Library) and packageing "iup.dll" together with my shader the shader is not loaded anymore. I have to check how Truespace behaves if IUP is linked statically with the shader dll but my first tries ended in failure cause the static IUP library seems to introduce a reference to "WinMain" somewhere which is not present in a DLL.

Here are the Error-Messages if I try to link my shader.dll against the static IUP-Library:

Code: Select all

C:/Users/******/Desktop/Privat/mingw32/i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x17): undefined reference to `__mingw_winmain_nShowCmd'
C:/Users/******/Desktop/Privat/mingw32/i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x28): undefined reference to `__mingw_winmain_lpCmdLine'
C:/Users/******/Desktop/Privat/mingw32/i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x31): undefined reference to `__mingw_winmain_hInstance'

[zzador]

Problem SOLVED!

It seems the main-shader code (compilation-unit with "tsxShaderInitialize") gets manually relocated after the DLL is loaded. My guess is based on the fact that all the shader variables need to be located in the main unit too. All my "normal" shaders had the location of the shader variables in the IUP-dialog and the main unit used them from there. My TestShader however had no dialog so I let the variables in the main unit. After turning it around in my other shaders (i.e. the dialog uses the shader variables from the main unit) all shaders are working well with IUP-Dialogs now.

Thanks for the help so far.
I will post the 4.3 SDK as soon as it is finished.