Jump to content

  • Log In with Google      Sign In   
  • Create Account

mhagain

Member Since 06 Jun 2010
Online Last Active Today, 04:12 AM

#5293012 c++: sprintf but return chars. Possible?

Posted by mhagain on Yesterday, 03:13 AM

I'm going to be contrary and advise not to do this.  What if your hypothetical getChar fails?




#5293001 how frustum cull big stuff like terrain

Posted by mhagain on Yesterday, 01:43 AM

Generally you can cull terrain by the simple use of a quad tree, which generates the AABBs for you. The benefit of this is for larger worlds you can skip multiple tests with the quad tree as if an entire node fits in your frustum, by rule of thumb all child nodes do as well.

 

...and if an entire node is outside, then so also are all child nodes.  It's only for nodes that intersect that you need to descend and test children, so even if the dataset is huge, it's an exponential reduction with the first handful of tests lopping off a large percentage of it.




#5293000 How to organize worlds/levels as seen in the new Doom

Posted by mhagain on Yesterday, 01:40 AM

I once ran Doom's predecessor (Rage) through GLIntercept and determined that for a lot of it's visibility tests it just uses hardware occlusion queries.  Presumably with some optimization such as reading back the frame after a query is issued, and if a result is not ready yet use the last known good result instead.




#5292832 Fragment Shader HLSL vs GLSL

Posted by mhagain on 22 May 2016 - 01:35 AM

You're comparing a (GLSL) vertex shader to a (HLSL) pixel shader here.  You can't make a meaningful comparison.




#5292459 Moving to OpenGL 3.1

Posted by mhagain on 19 May 2016 - 05:07 AM

In practice what you're going to find is that you only have a handful of vertex format combinations (i.e enabled arrays, strides, offsets) but the buffers they're sourced from change with greater frequency.

 

What you need is GL_ARB_vertex_attrib_binding - it's getting into GL 4.x territory but support for it should be uniquitous nowadays, and it's designed to solve exactly this problem.  Using this model your vertex format specification moves from runtime to load time, and at runtime you just bind a VAO and issue some glBindVertexBuffer calls.




#5292078 Manually loading OpenGL functions on Windows

Posted by mhagain on 17 May 2016 - 08:57 AM

 

To be honest you're making things more complicated for yourself than they need be.  The process of linking to and using OpenGL on Windows is simple so long as you follow the rules and are aware of what functions are available with each GL version.
 
You #include <gl/gl.h>
You statically link to opengl32.lib, via either project settings or #pragma comment (lib, "opengl32.lib")
 
At this stage all of OpenGL 1.0 and 1.1 is available to you without needing to do anything else.  No need for GetProcAddress, no need for wglGetProcAddress.


For typical windows apps, you're correct. For minimal 64k apps though, manually loading OpenGL is not a bad idea. You can allocate a table to store the pointers at runtime, which actually cuts down the number of global variables in your exe (which would have been used to store each function pointer to a glcall you are using). You can also concatonate strings to build up the function names to extract. It may seem like overkill, but it does actually cut down on memory usage. It's a very common approach in the demo scene....

 

 

True, but I'd suggest get it working the right way first, then look to reduce executable size.  At least that way you stand a chance of knowing where your problems are coming from.




#5291400 Identify the pattern

Posted by mhagain on 13 May 2016 - 07:15 AM

No.

 

For example, both normal and position are typically stored as 3-component float arrays.  So given an arbitrary 3 floats, there is no way to tell if they're intended to be interpreted as normal or position.

 

This is entirely the point of glVertexAttribPointer.

 

The documentation for both glVertexAttribPointer and glEnableVertexAttribArray refers to "generic vertex attributes"; i.e. the vertex attributes themselves are generic and they have neither metadata, not usage semantics, nor anything else attached to them to denote how they are used.  How they are used is entirely determined by your program.

 

"Generic" in this case even goes a step further in that you are not confined to the typical attributes used in drawing (position/normal/texcoords/colours/etc): if you want your program to interpret an attribute as "kilowombles per square inch", you can.




#5291088 How to restore states after draw particle

Posted by mhagain on 11 May 2016 - 03:05 AM

ID3D11DeviceContext::ClearState

 

 

This method resets any device context to the default settings. This sets all input/output resource slots, shaders, input layouts, predications, scissor rectangles, depth-stencil state, rasterizer state, blend state, sampler state, and viewports to NULL. The primitive topology is set to UNDEFINED.

 

Personally I never restore state after drawing.  Instead I set the state I want, and all of the state, before drawing, and the code is substantially cleaner and easier to follow/debug.

 

(Exceptions to this should be obvious: resetting rendertargets, etc).




#5291065 Clarification about shaders and Directx11

Posted by mhagain on 10 May 2016 - 09:47 PM

Yes, the documentation for all of the *SetShader calls states:

 

 

Passing in NULL disables the shader for this pipeline stage.

 

However, the Shader Stages page also states:

 

 

The vertex shader stage must always be active for the pipeline to execute.

 

So by running with a NULL vertex shader, one of two things is happening: either your vertex shader isn't actually NULL, or your driver has a bug that is allowing the graphics pipeline to execute without a VS.

 

Either way you're relying on undocumented, undefined or erroneous behaviour.  Instead you should familiarise yourself with the way things are supposed to work according to the documentation, and rely on that instead.




#5290801 how to load compiled effect file?

Posted by mhagain on 09 May 2016 - 08:33 AM

You really should compile the effect file and shaders on the very machine they are supposed to run at.

 

That's not the way D3D shader compilation works.

 

It's a two-step process, step one being compilation of the shader to byte code.  This is hardware-independent, and doesn't even need a D3D device or context to be created.  This is the step that the OP is talking about, and is performed by D3DXCompile/D3DXCreate/D3DCompile/etc.

 

Step two takes that hardware-independent bytecode and compiles it to a hardware-dependent representation.  This is not the step that the OP is talking about, and is performed by device->Create*Shader calls.




#5290794 Manually loading OpenGL functions on Windows

Posted by mhagain on 09 May 2016 - 08:11 AM

I am not saying that you are not right but for glClear, wglGetProcAddress returns NULL and GetProcAddress gets the right pointer. But that seems to be an exception (probably one of the older functions)?

 

If it's in Microsoft's <gl/gl.h> then it's also in their opengl32.dll and their opengl32.lib; it's a GL 1.0 or 1.1 function and it cannot be obtained via wglGetProcAddress.

 

To be honest you're making things more complicated for yourself than they need be.  The process of linking to and using OpenGL on Windows is simple so long as you follow the rules and are aware of what functions are available with each GL version.

 

You #include <gl/gl.h>

You statically link to opengl32.lib, via either project settings or #pragma comment (lib, "opengl32.lib")

 

At this stage all of OpenGL 1.0 and 1.1 is available to you without needing to do anything else.  No need for GetProcAddress, no need for wglGetProcAddress.

 

To access higher functionality (OpenGL 1.2 or higher) you either load them manually yourself, using wglGetProcAddress or use an extension loading library, such as GLEW.  This is the part where you make your secision to not use GLEW owing to wanting to keep the executable size down.




#5290660 Manually loading OpenGL functions on Windows

Posted by mhagain on 08 May 2016 - 09:14 AM

Incidentally, what this also means is that your fallback of LoadLibrary and GetProcAddress won't work for functions higher than GL 1.1.  What was previously happening is that when wglGetProcAddress failed and it routed through your fallback path, it failed to load those functions from Microsoft's opengl32.dll because Microsoft's opengl32.dll does not contain them.

 

This is all part of the OpenGL ICD driver model and you shouldn't even have a fallback path.  Just use wglGetProcAddress in the way it's documented to be used instead: https://msdn.microsoft.com/en-us/library/windows/desktop/dd374386%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396




#5289218 OpenGL Issues

Posted by mhagain on 29 April 2016 - 05:35 AM

Please see:

 

http://www.notebookcheck.net/Intel-Pentium-P6200-Notebook-Processor.40596.0.html

http://www.notebookcheck.net/Intel-Graphics-Media-Accelerator-HD.23065.0.html

https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units

 

Specifically, this is an Arrandale CPU with Ironlake graphics.  It supports Direct3D 10.1 (not 11) and OpenGL 2.1 (not 4.x); it does support shader model 4.1 under Direct3D, but that's not the same thing as the OpenGL version.

 

So since your hardware doesn't support any GL version beyond 2.1, you're stuck with OpenGL 2.1.




#5288796 Returning by value is inevitable?

Posted by mhagain on 26 April 2016 - 12:37 PM

Anyone care to explain what is wrong with the static variable solution? I've used this for years and always thought it was a convenient and fast solution.

 

Compute (Function (x), Function (y));

 

If "Function" uses the static variable trick, does this work?




#5288577 CreateBuffer throws _com_error exception and I can't catch it

Posted by mhagain on 25 April 2016 - 05:28 AM

My reasoning for the parameters: box is NULL (no offset), SrcRowPitch = the total amount of data passed, SrcDepthPitch = 1 since there is just one array of data.


Depth pitch is not the number of depth slices, but rather the number of bytes between each depth slice.  In the MSDN samples, when updating a non-volume resource, depth pitch is set to 0, so you should follow that example and set it to 0 yourself.  The documentation could, of course, have been clearer about that.






PARTNERS