Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Mar 2000
Offline Last Active Dec 22 2015 02:19 PM

Posts I've Made

In Topic: MyClass myClass VS myClass = new MyClass()

20 November 2015 - 04:05 PM

The stack requires that the lifetime of your object be known and fixed at compile-time. Indeed, the compiler depends on it to generate the proper stack framing code. The code you have now can't satisfy those conditions because it must wait some indeterminable amount of time before the window is created, thus requiring late-binding and heap allocation.


However let's say you re-arrange your code like this:

void MainLoop()
    while(!window->OpenGLContext->Inited()) { /* handle exit */ }

    // Guaranteed OpenGL context is initialize
    SpriteBatcher batcher(window->OpenGLContext);
    bool run = true;
        /* main loop stuff */

Your code waits until the OpenGL context is initialized before creating the sprite batcher, which can be created on the stack because it's lifetime can be entirely code-driven.

In Topic: Random errors in Release builds

20 November 2015 - 01:32 PM

I've often found uninitialized variables and/or memory to be the culprit behind these kinds of issues, where things mysteriously break in one build or once deployed, *especially* in release builds.


Start with remote debugging when the issue presents, and then lots and lots of logging!

In Topic: Risen 3: Titan Lords key (for US/NA (Steam)) giveaway

20 November 2015 - 12:52 PM

I've PM'd you back, but the key appears to have been activated :(


Thanks though for the opportunity to try it out :)

In Topic: Risen 3: Titan Lords key (for US/NA (Steam)) giveaway

20 November 2015 - 12:39 PM

I'd take it, if no one else has already :)

In Topic: Integrating a scripting language

19 November 2015 - 05:48 PM

Start by thinking of the scripting VM as its own independent domain, with absolutely no concept of shared state or direct access with your native code. We could even assume it's in a separate process entirely.


Notice how this resembles a client/server architecture. As such, you could use RPC mechanisms to allow them to communicate. Notice how all the mechanics and details of the script/native interaction are now the responsibility of a dedicated communication layer, as opposed to requiring the script code or native code to understand those details at every turn. Shared ownership isn't even a thing.


Next, let's move the script VM to the same domain as the native code and allow them direct access to each other. You no longer need to marshall and communicate a copy of the data across a domain boundary and have it updated remotely; you just set the new value directly and raise a 'changed' event. The state update can be accomplished via injection -- the script owns the data it's going to consume, but passes a reference to native code so it can be populated as necessary. Before the script goes away, it passes a null reference to the native code indicating it's no longer valid. Since we've designed the architecture so that the scope of the script's ownership always encapsulates the scope of the native code's ownership (or vice versa) of a particular piece of state, we don't run into any of the typical shared ownership issues and we could use a weak reference if the scripting language supports it; but at that point it's an implementation detail.


However the cost of such an approach is requiring the native code to have privileged knowledge of the script's data layout, since you're no longer using the same neutral data representations which exist as part of a communication protocol. You trade run-time efficiency, for additional maintenance overhead. However I've often found that to be an acceptable trade-off , since the script-side interaction with an RPC layer can often be a problematic if lots of short-lived temporary objects end up being created often.