Jump to content

  • Log In with Google      Sign In   
  • Create Account


We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.

Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


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?