Compiling as a dll...for the engine
by Bobby Leighton · in Torque Game Engine Advanced · 06/21/2006 (9:52 am) · 10 replies
I heard that i might be able to use the TSE as a dll....could anyone tell me the advantages of this or perhaps why this is a bad idea....I really would like to be able to do many things with the engine and im looking for anyway that i can get a WIDER use from the engine...for example ...im looking for a way to instead of useing the standard HLSL language for the shaders i would like to be able to add the ability to use .FX files they export directly from rendermonkey...but I assume that there would have to be many changes to the stucture of the engine to support these file...or i may be wrong as i am not an expert...........I would also like to be able to combine the TSE with other things written in C I just assume that it would be aeser to call a DLL instead of individual calls for certian functions...but Im not shure if ive been misinformed as to the use of a DLL....could someone help?
#2
06/22/2006 (9:50 am)
Now that makes sense...about the assembly shaders and I hope I can find some examples..its seems the lower levels i go with languages the more it makes sense to me codeing seems to be harder...but i wonder why compiling the shader engine as a DLL would be a violation of the EULA ...I did some searching on the subject and it returned that the fellow who owns Minions of Mirth had mentioned doing it this way but he seems to speak in riddles as to the reason this is a good idea...however now that ive looking at it I think you correct in stating that it would be a lot simpler to make apps that do that traslating instaed of trying to build the function into TSE that seems to be harded.... 
#3
If you don't understand the engine enough to modify it to your liking yet, you'll probably not be able to make any use of it as a DLL either. That is not the easist way to "combine it with other things written in C", I assure you. That's the worst way possible, since TGE is not a library nor a simple graphics engine, and I simply cannot see how that would make you closer to loading .FX files directly.
If you want to load .FX files as materials directly, the best way would be coding a new class (fxMaterial or something) derived from the Material class, which takes .FX files as inputs, parses them, and then extract the shaders code, copile them, and setup render passes and textures based on it.
06/24/2006 (7:09 am)
From my knowledge on the engine, I don't see what you could gain from compiling the engine as a DLL, other than a lot of trouble. If you don't understand the engine enough to modify it to your liking yet, you'll probably not be able to make any use of it as a DLL either. That is not the easist way to "combine it with other things written in C", I assure you. That's the worst way possible, since TGE is not a library nor a simple graphics engine, and I simply cannot see how that would make you closer to loading .FX files directly.
If you want to load .FX files as materials directly, the best way would be coding a new class (fxMaterial or something) derived from the Material class, which takes .FX files as inputs, parses them, and then extract the shaders code, copile them, and setup render passes and textures based on it.
#4
06/24/2006 (11:05 am)
Your right it would cause a big problem...I was reading another post and when i saw that the question was never answered i decided to ask the question myself...i really didnt see the merit in it but the guy that did minions of mirth was asking if anyone had done it...i didnt understand what he was talkin about i figured you guys would ....but what i really need is someone to help me write a exporter for rendermonkey i figured we could give it to the community when its done...it would be nice if we all could develop a shader in RM and then push a button add the files in Torque...ya know?..if anyone wants to help...lmaceleighton@msn.com
#5
06/24/2006 (11:23 am)
IIRC, RenderMonkey already exports their shaders as the same file TSE expects--you just have to tie them in via a CustomMaterial (script definition).
#6
06/24/2006 (2:28 pm)
Yeah ive copied the hlsl to thier seperate files...for example i used the basic fire shader that is in the example that come with the program...copied the files added the definition...i followerd the tutorial that is in the resources section however it doesnt explain what the code is for or what it affects....i wish there could be a generic template that we could just use to fill in values.......QUESTION:once i define the shades properly and make them availible(thats what ive done)should i be adding in the mission script the variables from the shader...like using the fire one there are 3 textures and BASE a OPACITY and a NOISE...where do i relate those files to the model i want in flames...sorry for rambling...and spelling
#7
(I assume you already know how to define a shaderData and stuff).
Now, how do you know which texture is #0, which one is #1 and so on? It's defined by the order at which the sampler variables are defined on top of the HLSL file.
Alternatively, you can specify which texture # your sampler variables will use in the HLSL:
For shader constants, check the shdrConsts.h file in the example/shaders folder. It contain a list of all constant registers used by TSE. You can have a general idea of what they're used for by their names (you can also do a global search on the source to see what's getting passed onto those registers).
06/24/2006 (5:45 pm)
The texture files are specified in the customMaterial:new CustomMaterial(whatever)
{
mapTo = "someTexture";
texture[0] = "base";
texture[1] = "opacity";
texture[2] = "noise";
shader = someShaderData;
};(I assume you already know how to define a shaderData and stuff).
Now, how do you know which texture is #0, which one is #1 and so on? It's defined by the order at which the sampler variables are defined on top of the HLSL file.
Alternatively, you can specify which texture # your sampler variables will use in the HLSL:
sampler2D base : register(S0); sampler2D opacity: register(S1); sampler2D noise : register(S2);
For shader constants, check the shdrConsts.h file in the example/shaders folder. It contain a list of all constant registers used by TSE. You can have a general idea of what they're used for by their names (you can also do a global search on the source to see what's getting passed onto those registers).
#8
Now lets say I have set up the shader properly...now in the Mission File where i can see the object that i before specified a Materials.cs script so that its using the shader....that should be it..right...or is the somthing that should be done in the Mission File....im just making shure ive covered all my bases....Id feel preety dumb if i was ignoring somthing like that Iv just noticed that the Atlas shader uses the mission script to relay certain info...thank you for anyhelp in advance and thank you for the patience you have given already!!
06/25/2006 (9:55 am)
That makes a bit more sense...and this does seem to be the way i set it up for the most part...but i can see now that i will have to go in a change the register values to the ones that Torque is probably using...that helps alot to know that i am on the correct track....Now lets say I have set up the shader properly...now in the Mission File where i can see the object that i before specified a Materials.cs script so that its using the shader....that should be it..right...or is the somthing that should be done in the Mission File....im just making shure ive covered all my bases....Id feel preety dumb if i was ignoring somthing like that Iv just noticed that the Atlas shader uses the mission script to relay certain info...thank you for anyhelp in advance and thank you for the patience you have given already!!
#9
A good way to test if your customMaterial is mapping properly is to create a very simple shaders that do only the basic vertex transformation and output a single fragment color value.
Also, if you're serious about using customMaterials, I posted a thread about a small change that allow you to make a shaderData re-compile it's shader during runtime.
here:
www.garagegames.com/mg/forums/result.thread.php?qt=44608
With that you can depend a lot less on renderMonkey to edit your shaders.
06/25/2006 (11:42 am)
There's no need to do anything to the mission. As long as the shader has compiled properly (check the console, it output shader compilation errors and warnings there too), and the customMaterial is properly mapped to a texture, all instances of that texture should display the shader.A good way to test if your customMaterial is mapping properly is to create a very simple shaders that do only the basic vertex transformation and output a single fragment color value.
Also, if you're serious about using customMaterials, I posted a thread about a small change that allow you to make a shaderData re-compile it's shader during runtime.
here:
www.garagegames.com/mg/forums/result.thread.php?qt=44608
With that you can depend a lot less on renderMonkey to edit your shaders.
#10
06/25/2006 (5:40 pm)
Thank you I believe this will help save some time...I like having feedback that I understand 
Torque Owner Kevin Johnson
Another route you could go is write up a small app to automate .FX->TSE Material, or perhaps a plugin for rendermonkey to export what you need.
BTW tse doesnt just do hlsl, it supports assembly shaders as well -
good luck
k