• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Xoliul

Compiled Shader looks different

4 posts in this topic

I've written a procedural noise shader. It's pretty heavy but it only serves to Render-To-Texture so that's fine.
One big problem I have is that the compile time is pretty insane, so I'm trying to precompile it using FXC.exe. I have to use the June 2010 DX SDK because it's not an SM4.0 shader (my application, 3DS Max, is still D3D9).

Now the problem with the assembly code that FXC generates, is that it doesn't work exactly the same as the uncompiled code. The values the noise functions generate are in a very different range, resulting in pretty much nothing visible. If my application compiles it with its own compiler, it works fine...

This is a bit of a long shot, but would anyone know what is going wrong?
0

Share this post


Link to post
Share on other sites
You are the guy who makes all the artists happy ?

Are you compiling with the legacy compiler ? Found the following discription over [url="http://msdn.microsoft.com/en-us/library/windows/desktop/bb509710%28v=vs.85%29.aspx"]here[/url], maybe it is helpful:
[quote]
[b] Compiling with the Legacy Compiler[/b]

Beginning with Direct3D 10, some shader models are no longer supported. These include pixel shader models: ps_1_1, ps_1_2, ps_1_3, and ps_1_4 which support very limited resources and are dependent on hardware. The compiler has been redesigned with shader model 2 (or greater) which allows for greater efficiencies with compilation. This of course will require that you are running on hardware that supports shader models 2 and greater.
If you still want to compile shaders using the legacy compiler, use the /LD switch. This supports shader models 1, 2 and 3 and does not contain the improvements and bug fixes found in the current compiler.
Also note that you should consult the SDK release notes associated with your version of the [url="http://msdn.microsoft.com/en-us/library/windows/desktop/bb232919%28v=vs.85%29.aspx"]Effect-Compiler Tool[/url] for behavior affected by the /Gec switch.
[b] Compiling Shader Model 1 with the Current Compiler[/b]

The legacy compiler is not recommended for compiling new shader code due to the limitations caused by pixel shaders in shader model 1 (see [url="http://msdn.microsoft.com/en-us/library/windows/desktop/bb509710%28v=vs.85%29.aspx#Legacy"]Compiling with the Legacy Compiler[/url]). However, there are libraries of existing shaders that were created for ps_1_x.
To use the current compiler to build shader model 1 pixel shaders and effects, use the /Gec switch. This causes the effect-compiler tool to compile all ps_1_x targets to ps_2_0 targets. This can be done without changing any existing shader or effect code. This switch has no effect when used with higher level compile targets.

[/quote]
0

Share this post


Link to post
Share on other sites
Hey Ashaman, I guess that's me yes hah. I've tried using the /LD switch but I didn't fix things. I did so many different compiles with different options so i can't remember what was wrong.

I've progressed a bit, I'm basically re-building the code step by step, compiling it again and again and so far it has worked fine. I think I'm 85% of the way and it is working. I'm not even using the /LD switch at the moment.
0

Share this post


Link to post
Share on other sites
I've found the culprit. Looks like when I add a texcoord input from the application, it breaks the entire thing.

Basically:

[CODE]
// input from application
struct a2v
{
float4 position : POSITION;
};
// output to fragment program
struct v2f
{
float4 position : POSITION;
float4 wposition : TEXCOORD0;
};
[/CODE]

to this:

[CODE]
// input from application
struct a2v
{
float4 position : POSITION;
half2 texCoord : TEXCOORD0;
};
// output to fragment program
struct v2f
{
float4 position : POSITION;
half2 texCoord : TEXCOORD0;
float4 wposition : TEXCOORD1;
};
[/CODE]
0

Share this post


Link to post
Share on other sites
Have you tried to map it to other varying varibles ? Like
[CODE]
// input from application
struct a2v
{
float4 position : POSITION;
half2 texCoord : TEXCOORD0;
};
// output to fragment program
struct v2f
{
float4 position : TEXCOORD1;
half2 texCoord : TEXCOORD2;
float4 wposition : TEXCOORD3;
};
[/CODE]
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0