Jump to content

  • Log In with Google      Sign In   
  • Create Account

Laval B

Member Since 30 Jul 2010
Offline Last Active Today, 03:36 AM

Topics I've Started

Variable size strucs

11 October 2015 - 06:28 AM

Hello everyone


I'm trying to optimize the drawitem structure i use for my renderqueue. I use a struct that basically containes the same elements as the one posted by Hodgman in this post http://www.gamedev.net/topic/666419-what-are-your-opinions-on-dx12vulkanmantle/#entry5215127. I'm trying to reduce the footprint of the struct and to get all the members to be contiguous in memory to improve cache efficiency.


Replacing the pointers by 16 bits unsigned integers which are indices into arrays will considerably reduce the size of the fixed-length part of the struct (i compile for 64 bits).


I don't know how to deal with the variable part of the struct. I though about using variable size structs like the one bellow :

struct DrawItem
   u16 shaderPermutationId;
   u16 depthStencilStateId;
   // ...
   u16 textureCount;
   u16 textureIds[];
   // Cannot put more arrays or anything else after that.

But like the comment says, it's not possible to have any member after a variable size array.


I'm interested to know what could be done.

Managing input layouts

27 September 2015 - 02:19 PM

Hello everyone


When loading a vertex shader, i'm using the reflection api to build the corresponding input layout. In order not to create unnecessary layouts, i want to cache them in an associative container which in turn requires a key. What would be a good way to build a key that will match a layout using only the data used to create the layout ?

Terrain LOD

17 August 2015 - 10:38 AM

Hello everyone.
I'm an currently working on the design of a terrain system for my engine.  The goals are to be able to render large terrains with good quality in real time. I'm mostly working on the geometry pipeline so far. The literature is quite abundant but i mostly retained the ideas from the following papers :
So far the geometry pipeline will looks like this :
- Terrain will be rendered using a heightfield (texture).
- The terrain grid will be a minimal vertex buffer containing only the x and z coordinates.
- The displacement will be done in the vertext shader.
- Vertex normals will also be computed in the vertex shader.
- The redering will be done using a quadtree that will be used for both culling and lod selection. The quadtree is basically only managing index buffers.
In order to avoid T-Junctions between adjacent nodes with different lod, a certain number of index buffers permutations will be used (9 of them) just like it is described in [1].
The problem is that for this algorithm to work, the difference in lod level between two geometrically adjacent nodes on the terrain must must be at most 1.
What would be a good way to impose this restriction ? Right now, i'm out od ideas or at least good ones ...

Codebase with multiple back-ends

20 December 2014 - 11:16 AM



Different parts of my codebase will use various back-ends e.g. the rendering system can used Direct3D11 or OpenGL, the audio system can use OpenAL or FMOD, etc. Since The choice of those back-ends is made at compile time, the specific implementations have their own header and source files. There is also a set of headers that include the porper implementation depending on some defines. E.g. OpenalAudioDevice.h/.cpp implement the OpenAL version of the AudioDevice, FmodAudioDevice.h/cpp implement the FMOD version of the same class and the header AudioDevice.h includes the appropriate implementation depending on some defines.


The problem i have with such a setting is that i don't want to compile and link the implementations i don't use for a given configuration. I'm not sure how i could do that in a practical way.


I'm using Visual Studio 2013 and C++ for Windows implementation but i'm planning to have a version for OSX using Xcode. Also, some of these choices will be determine by the platform e.g. Windows will Direct3D only, OSX will be OpenGL only. FMOD or OpenAL on the other hand can be chosen on both platforms.

Qt and OpenGL

28 November 2013 - 05:04 AM

Hello everyone.


I have started porting our map editor from a MFC sdi application to a Qt application and i'm having issues with OpenGL. By the way i'm quite new to Qt. I'm nusing Qt 5.1.1 with Visual Studio 2012 toolchain and Qt Creator 2.8.1.


I have a QApplication with a main window derived from QMainWindow. The main window contains a few docking windows on the right, left and bottom docking area. For the main widget of the main window i subclassed QGLWidget for rendering. For some reason this widget is all black.


The QGLWidget subclass overrides only the initializeGL, resizeGL and painGL methods. The code for these methods is minimal :

/// One time initialization.
void SceneView::initializeGL()
    glClearColor(0.25f, 0.25f, 0.25f, 1.0f);

/// Called when the widget is resized.
void SceneView::resizeGL(int w, int h)
    // Setup viewport, projection etc.
    glViewport(0, 0, (GLint)w, (GLint)h);

/// Called when the widget is redrawn.
void SceneView::paintGL()

Whatever the clear color i chose, the widget is always black.


I have tried creating the widget with and without parent, creating the widget alone (only window in the application) and it didn't change anything. I have tried to call swapBuffers (which, according to the documentation i shouln't do) and it didn't work.


Also, i have notices that, when resizing either one of the docking widget, there is some flickering (only when the widgets are docked). This doesn't appen if i replace the central widget by a QTextEdit for example.


Anyone have any idea what the problem could be ? Some of the examples used basically the same method and they work.