Jump to content

  • Log In with Google      Sign In   
  • Create Account


Scourage

Member Since 29 Jan 2000
Offline Last Active Jul 01 2014 01:31 PM
-----

Posts I've Made

In Topic: Tips for Programming a GUI

13 April 2014 - 09:43 PM

You should also look at the "Immediate Mode" GUI talk on Molly rocket (https://mollyrocket.com/861). It's a slightly different way of thinking about GUI development. In my opinion it's easier to use as an end user, but not necessarily easier to build.

It's great for simple in game menus, but apparently can be used In fairly complex systems. Unity uses an IMGUI in their editor.

Cheers,

Bob

In Topic: How to communicate between c++ and c#?

03 April 2014 - 08:59 AM

Binding C# to C++ is hard and painful.  I recommend not doing it (I will give SWIG another look).  

 

I recently needed to bring a rather large c++ API into Unity (C#).  To do this I built a very minimalist C API (just 4 functions: init, shutdown, send message, tick), which I use P/Invoke to call.  I then pass messages back and forth between managed and unmanaged code using this API.  Messages are code generated classes (from a simple message definition) that serialize to buffers and then passed through the sendMessage function to the other side.  The code generator actually generates C++ and C# versions of the class so they know how to serialize/deserialize on either side.  There's definitely a performance hit for this approach, but it is the cleanest way I came up with that still allows me to expand what is passed between managed/unmanaged code with a minimal amount of work.

 

You might also want to consider doing something similar but with TCP sockets.  I've sat in a couple of sessions at GDC recently where people are building remote debug/edit capabilities into their game engines by passing messages over a socket, even if it's all within the same application.  

 

Cheers, 

 

Bob


In Topic: Exporting "to WebGL"!?

27 March 2014 - 06:32 PM

You may want to look at glTF, it's a runtime format from Khronos.  It's designed originally for webGL.  Currently the way to get models in the format is to convert from Collada using their tool, but I'm working on a Blender import/export for it.

 

cheers, 

 

Bob


In Topic: Multithreaded drawing and logic

24 March 2014 - 10:47 AM

Multithreading is hard, but it's not impossible.  You do need to think of your game slightly differently in terms of data and processes.  I like to do things with events, commands, and worker threads.  I don't have any mutexes or locks in my system, but I do design my data structures so that they are contention free for the duration of the worker thread's processing. I use lockless queues to pass events/messages between threads (typically updates from my entity system to the main thread for dispatching later in the frame/next frame).

 


The result of one unit's update might depend on another, so this isn't a solution for lockstep multiplayer games.

 

I've run into that before, what I've done is maintain several buckets of entities to update based on a parent.  I've never really got further than 4 or 5 deep.  I then update all the entities in bucket 1 (since they don't depend on each other or a parent), then 2 (their parents are all up to date), etc, etc.  This requires a little extra book keeping, but definitely possible.

 


Sending them off to the GPU in each worker thread? They share the same GL context and would have to constantly switch with wglMakeCurrent. Plus what if they require different shaders?

 

You don't have to actually call any GL commands from the worker threads, just get everything ready to draw (cull and uniform setup).  If you're doing some cool multidraw-indirect stuff, you can have each thread touch the command buffer, but that requires some rather specialized data structures and beyond what I know about.  In my rendering engine, I've encapsulated rendering of objects into a command class. Worker threads generate all the command classes in parallel (each renderable object generally caches and reuses it's render commands).  The command classes get their uniform data updated (not calling glUniform, just holding the vector/matrix ready to call glUniform).  When the worker threads are all done, I then combine each worker threads command list, sort by render state and then process the entire list calling exec on each command.  This is where the GL calls are actually made.  You could even push the entire sorted command list into a separate thread just for rendering.  

 

Cheers, 

 

Bob


In Topic: Multithreaded drawing and logic

23 March 2014 - 08:44 PM

Another option is to change your threading model. You could run your update phase in a multithreaded fashion, using worker threads to update multiple groups of entities at the same time. Then if it's time to render the scene, create all your draw calls (also could be done in a bunch of worker treads) and send them off to the gpu.

Cheers,

Bob

PARTNERS