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!


Member Since 23 Dec 2012
Offline Last Active Apr 22 2014 01:18 AM

Topics I've Started

Best Language for Cross-Platform Content Pipeline

07 January 2013 - 02:29 PM

I'd like to make a content pipeline for some of my games/engines/etc I'm working on, and I'm not quite sure what would be the best language to use.  I'm using C++ for the actual runtime, but this seems very unproductive for tools.  I've seen C# recommended several times for Windows-only content pipelines, but I'd like to know if there's anything more cross-platform.


Here are some features that an ideal language would provide:

  • It also should provide some abstraction of OS-specific functionality such as directory iteration, etc.  It should also be easy to use high-level features such as regular expressions and other text-manipulation techniques.
  • Integrating this language with Lua should be simple, as I want to use Lua as a data-description language for several resource types.
  • Calling external processes shouldn't be too hard -- for example, I might want to use the Cg toolkit's cgc program to compile shaders.

I suppose C++ could work if I used heaps of boost libraries -- this does seem a bit cumbersome though, and I imagine it would cause a large hit on compile times.


Anyone have any suggestions for a good language to use?

Dealing with bind-to-edit in OpenGL

23 December 2012 - 05:46 PM

Hi all,


I'm looking for an elegant way to design a rendering API abstraction layer, but I keeping running into problems because of OpenGL's bind-to-edit model.  For example, one thing I want to do is cache/shadow the current render state to avoid redundant state changes, but bind-to-edit makes this especially difficult.


Here's some pseudocode (I'm pretending there is only one texture unit, for the sake of simplicity):

class Texture {
    void Create()
        glBindTexture(GL_TEXTURE_2D, m_name); // the wrong texture is now bound
        ... // code to create texture
    GLuint GetGLName() const { return m_name; }
    GLuint m_name;

class GraphicsDevice {
    void SetTexture(Texture* texture)
        if (texture != m_texture) {
            glBindTexture(GL_TEXTURE_2D, texture->GetGLName());
            m_texture = texture;
    Texture* m_texture;


As you can see, the texture class needs to bind itself in order to create the OpenGL texture object, and so the the GraphicsDevice class now thinks a different texture is bound than the one that actually is.


The obvious way to fix this problem is to add a glGet(GL_TEXTURE_BINDING_2D) call in Texture::Create so that the previous texture can be bound afterwards, but glGet() calls are supposed to be avoided, right?


The only other solutions I can think of involve various ugly techniques such as circular dependencies, global variables, etc.


Is there a better way of solving this problem?