Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Laval B

Member Since 30 Jul 2010
Offline Last Active Today, 10:42 AM

Topics I've Started

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.

Behavior of assignment with user data in Lua

17 October 2013 - 09:08 AM

Hello everyone.


I have created and exposed a C++ class to Lua as a user data. Meta function __gc has been written and it works fine. I can make multiple instances (using the new function) of that object in a script and call their methods and they work. However, the behavior of the assignment is not what i need it to be. It looks like variables in scripts are references to objects in the virtual machine. Therefore, if i write a statement like 


x = y


in a script where x and y are both user data of the same type, x becomes a reference to the same object as y. Is there a way to override this behavior ? I know it is possible to override comparisons by defining __eq meta function (ans __le, etc).


Is it also possible to prevent assignment where it doesn't make sense ?


lightuser data in Lua

15 October 2013 - 06:39 AM

Hello everyone.


An application we are working on needs some parts to be scripted. The scripts will only act as callbacks to controle some  part of the execution of some transactions. To do so, it must expose a few objects from the host application. The lifetime of these objects is well controled by the host and they will outlive the execution of the script. The logical choice seems to be the use of lightuser data.


We have exposed these objects using functions and lightuser data and it does work. However, lightuser data don't have their individual metatable. Instead, they all share the same so they all share the same metamethods. It would be great though if we could associate specific methods to each object exposed (like it can be done with full user data) so it would be possible to use object oriented programming notations on those objects from the script.


At the moment, we have to use a notation like this :

function f(user, logger)

   setName(user, "name")
   setGroup(user, "group")

   output(logger, "User is set.")


instead of 

function f(user, logger)


   logger:output("User is set.")


Is there a way to do this with lightuser data ?

Uniform blocks and Uniform buffer objects

04 July 2013 - 10:45 AM

Hello everyone.



I'm thinking about how i would implement a parameter system using OpenGL 3.2+ (core profile) and GLSL. I'm talking about uniform (not including samplers) and not vertex attributes. I'm leaning toward using UBOs and uniform blocks in shaders. Here are a few of points i'm not sure about.


  1. I'm planning to use only one big UBO which will contain all the parameters for all uniform blocks in all programs, specific parameters being updated using an appropriate call to glBufferSubData. So, all uniform blocks a program uses would be associated to the same uniform binding point, let's say 0, using glUniformBlockBinding and glBindBufferRange. Another interesting thing about using only one UBO is that i can bind this UBO at load time and keep it bound during rendering (no need to bind an UBO every time i need to update a parameter). Is it that correct and is there any problem with this method ?
  2. Since association happens only at initialization time, the uniform block index returned by glGetUniformBlockIndex doesn't need to be kept into a variable assuming this association doesn't change, correct ?