Suggestion: define default window size as properties at App object level

Nov 12, 2011 at 5:22 AM

In the demos, the window size is fixed as 640 x 480, so far so good. Better practive would have the window size defined in properties in the App object. I would name it uWindowWidth and uWindowHeight. That's easy to do.

This window size may also be referenced in HLSL. How to pass this dynamically ?

-- François Piette

Coordinator
Nov 12, 2011 at 5:43 AM

The window width and height are already properties of the RenderApplication class (m_iWidth, m_iHeight).  In addition, each window tracks its size and shape based on the Win32 window's properties.

The dimensions of a render target would be passed into a shader with a constant buffer, which would be accomplished with the parameter system.  Take a look at some of the examples for passing light position, or colors, or time values from the more advanced samples to see how to do this.

Nov 12, 2011 at 6:15 AM
jzink wrote:

The window width and height are already properties of the RenderApplication class (m_iWidth, m_iHeight). 

Nevertheless, I see constant 640 and 480 hardcoded. Unless you changed it very recently.

I still do not grasp effectively the parameter system. Could you point me to an exact sample (cpp source code line and corresponding HLSL code line) ? This would help me.

Nov 12, 2011 at 7:35 AM

IMO the only place where the window size constant should appear is in the call of ConfigureRenderingEngineComponents. Elsewere, m_iwidth and m_iHeight shall be used.

For example, in ImageProcessing demo, FilteredConfig.SetColorBuffer is called with 640, 480 where is should be m_iWidth and m_iHeight.

Then in App::Update, Dispatch is called with either 640 or 480 depending on the context. In that code, as the comment states, it is assumed that the bitmaps have to correct size. For a demo, it is probably enough to empahasize that assumption in the comment. Maybe be the demo could be enhanced to use the actual bitmap size whatever the window size is. Depending on the relative window and bitmap size, either the tope left corner of the bitmap is shown, or the full bitmap with a background color on the right and bottom should the bitmap be too small. OK, it's a demo which must be kept simple. As I said, it is probably enough tp add a comment to the user that in a real application the developper should take care of that.

Even if the demos are to be kept simple, this doesn't prevent use of properly named constants so that the reader easily understand that in some places 640 refers to the window's width and in some other places, it refers to the bitmap's width. Basically, I don't like "magic numebrs" like 640 and 480 in the code. It is confusing.

Don't take me wrong: I'm not critising your excellent job. I'm just exposing the issues I'm faced with in my real world application.

Since I'm a pure beginner on GPU application, I probably see problems where an experienced developer doesn't see it [anymore]. That's why I report it. The demos could be enhanced (If simple enhancements are possible), or the developper reading the source code could be warned about shortcoming in the demo that he should take car of in his real application.

-- François Piette

 

 

 

Coordinator
Nov 12, 2011 at 1:44 PM

Hi Francois,

Don't be afraid to raise questions or issues or things that aren't clear.  As a user of the engine, I value your (and others) feedback and will try to utilize it to improve the engine as I can.  On the other hand, please also remember that I only get about 30 minutes per day (on average) to work on the engine, so there are limits to what I can realistically get done.  I'm also learning along the way too, and am certainly able to make mistakes - so if you have questions, just ask them!

Regarding the ImageProcessing sample, I think there is a little bit of confusion, plus a shortcut that I took while writing the book sample program.  As you mentioned above, the texture is required to of the proper size (640x480 in this case) and it was indeed hard-coded.  I should have specified it more clearly, but there is also a good reason that the sample is constructed with that limitation.  The processing of the image is done in pieces, where each piece is defined by a thread group.  These thread groups need to be sized at shader compile time, and then the enough groups created to cover the entire image (the number of groups is determined by the Dispatch(...) parameters).  If I allowed arbitrary image sizes, then the dispatch code would need to dynamically determine the number of groups to use.  I thought this would complicate the sample unnecessarily, although more details about this topic should be covered in the compute shader chapter and the image processing chapter of the book.  If you still have questions about it, please feel free to ask.

Regarding the parameter system, take a look at the Word document in the Hieroglyph3/Documentation folder.  This is a work in progress document that describes the general rendering system at a high level, which might help you to understand what is going on.  For a concrete example, take a look at the WaterSimulationI sample in the App.cpp file at lines 142-145, which controls the setting of data for the WaterSimulation.hlsl line 28 parameter.  The CPP code shows the way to initialize a parameter for ALL of the parameter systems (there are multiple parameter managers for the multiple threads) so in simple cases this will be the easiest way to get your data into a shader.  On the HLSL side, you put a variable inside of a constant buffer declaration.  The engine collects the individual parameters and copies them into a constant buffer, then binds it to the appropriate shader stage, where it then gets used by the shader program.

Hopefully that helps to clear things up.  I could extend the sample in the future to produce enough thread groups to process a variable sized image, but I would say that it is a fairly low priority against the other open items that I have at the moment...  Even so, I'll try to get it updated as soon as possible.

- Jason

Nov 12, 2011 at 2:39 PM

Thanks Jason. With your explanations I have successfully added parameters to my shader which can be changed at run time using C++ code. As I expected, this is fairly simple once you know how to do it :-)

-- Francois Piette