Jump to content

  • Log In with Google      Sign In   
  • Create Account


Scourage

Member Since 29 Jan 2000
Offline Last Active Jul 10 2014 10:36 AM
-----

#5146806 Tips for Programming a GUI

Posted by Scourage on 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


#5144111 How to communicate between c++ and c#?

Posted by Scourage on 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




#5142725 Exporting "to WebGL"!?

Posted by Scourage on 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




#5141591 Multithreaded drawing and logic

Posted by Scourage on 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


#5138790 C++ or C# For Game engine with OpenGL and SlimDX

Posted by Scourage on 13 March 2014 - 06:43 PM

I think C# is a fine choice, especially for learning how a game engine works. OpenTK is a great library to use to get started.  It has openGL/AL/CL bindings + all the utility, input, math classes you can shake a stick at.  My game engine uses an OpenGL 4.3 context just fine with OpenTK and I haven't run into any limitations, aside from my own capability.

 

I've integrated Lua into my C# game engine and if you're looking at other languages, There's the iron languages (IronPython, IronScheme, etc) which integrate really nicely into C# since they're all managed languages using the same runtime.  

 

Cheers, 

 

Bob




#5135032 Fastest map-like collection for <GUID, BaseClass*> lookup

Posted by Scourage on 27 February 2014 - 07:49 AM

I've found 64bit unsigned ints are more than enough for any GUID I've had.  I tend to use them as bit fields as well to help identify type and which machine they come from, so I could imagine I could get away with 32 bits in a simpler game.  The nice thing is that the comparison is simply an integer comparison, which is really fast.

 

As for quick look-up, you need to think about how many objects you have total.  If you have less than 100 objects, a simple array of objects may actually be faster than using std::map (which if I recall, is a red-black tree data structure).  However, if you have many objects (10000-1000000) you may need to test which is better, a std::map or some kind of hash table.

 

Cheers,

 

Bob 




#5133577 How to "reset" a singleton?

Posted by Scourage on 22 February 2014 - 09:36 AM

I have to agree with Danicco, this does not sound like a good use case for Singletons.  Maybe your gamestate manager might be a singleton, but the individual game states probably shouldn't be.  

 

Your gamestates probably should inherit an abstract base class with the following functions (pseudo code follows)

class AbstractGameState
{
  void onEnter() =0;
  void onTick(Time dt)=0;
  void onExit()=0;
};

Now your derived classes implement these functions and as you transition between states, you call onExit() of the state you're leaving and then onEnter() on the state you're going in to.  OnExit() will give your states the opportunity to either save state for when you come back to that particular state, if thats what you want. OnEnter() will give your states the opportunity to either reload a saved state, or reset the state, again depending on what you want.

 

Inside your game state manager, you can have a transition function to manage this for you:

void transition(AbstractGameState* toState)
{
   myCurrentState->onExit();
   toState->onEnter();
   myCurrentState=toState;
}

Cheers, 

 

Bob




#5132978 What can you use C# for?

Posted by Scourage on 20 February 2014 - 10:21 AM

I'm a fan of C#.  It's cross platform, compiles very fast (compared to c++) and you can get more done with less lines of code than C++.  In those regards, it's a more "productive" language.  I use it for all my prototyping, and sometimes the prototype is the final project since it performs well enough.  I thought it was pretty easy to learn, and is more than capable for any number of projects from Game editors, Rendering engines, to simulation backends.

 

The OpenTK library provides bindings for openGL/AL/CL as well as all the math primitives (vector/matrix) that you could need.  It also provides input and windowing API's as well.  

 

Xamarian and Unity both use C# and are able to target mobile platforms.  Unity can target browsers and consoles as well.  If you're looking for a pure browser based game, then C# may not be the right tool.

 

cheers, 

 

Bob




#5128798 Need help choosing language

Posted by Scourage on 04 February 2014 - 01:17 PM

 

Scourage, no, I haven't considered Javascript or HTML5, I don't understand the phrase, "browsers have lots of great debugging tools," at all. Wouldn't a compiler tell you if you had any errors? What do you mean C# is more "productive?" Do you mean you can type less to do some of the same things, or that it runs faster? I'll look into Javascript, HTML5 and OpenTK as well, first glances seem promising, but I think I'd like a larger toolkit than just HTML. Thanks for providing me some interesting options though.

 

 

Javascript isn't "compiled" like C++ is, it's interpreted at run-time like Python.  All modern browsers (Chrome, Firefox, Safari, IE) have built in debug tools.  They have the ability to edit code while it's running and continue.  You can also profile your code, setup breakpoints, inspect variables. It's a rather nice environment to build a game.

 

When I say C# is more productive than C++ I mean it takes less work to get a similar result.  I had the pleasure (read: somebody forced me to) of rewriting my game engine from C++ to C#.  I found that it took about 40% less lines of code for the exact same functionality.  I know lines of code is typically a really bad metric, but since it's an apples to apples comparison (same features, same developer implementing them) it works here.  40% less code is a lot less opportunity for bugs.  I really think that when working on solo projects, staying productive is important to keep from getting bored with a project and not finishing. 

 

Cheers, 

 

Bob




#5127245 Need help choosing language

Posted by Scourage on 29 January 2014 - 12:00 PM

If you're looking at 2d games and want to distribute on the net, have you considered using Javascript and HTML5?  Some of the nice things about developing games in javascript is that browsers have lots of great debugging tools, it's easy to distribute your games (just a URL) and the browser is a fairly capable platform now.

 

I would also recommend C# since it's performance is pretty good, it's significantly more productive than C++.  If you go the .net route, definitely look into OpenTK.

 

Cheers, 

 

Bob




#5090797 multi-thread

Posted by Scourage on 01 September 2013 - 09:52 AM

Bottom line: introducing multi-threading can cause you to spend a lot of time thinking about and developing things in a way that probably isn't very intuitive. If you don't absolutely need it and know what you're doing need it, then it may be better to spend time on the actual gameplay.

When I wrote my game engine, I needed it to scale with the number of cores, processors and machines. My general approach was to write my game as a set of serial tasks (update, network, physics, audio, render), but allow each step to spread out to use many worker threads when needed. Some of the systems were running their own internal threads and used the serial part to transfer queued messages (network, audio and renderer did this). I was able to show my system scaled almost linearly with the number of cores.

I spent a lot of time developing data structures that allowed for contention free processing without locking. Entity state, spatial data structures, profiling, event management all needed double buffering and special control structures to make things work properly. I spent even more time debugging this stuff.

If you really want to multithreaded your game ill be happy to discuss how I did it in more depth, but if you're on the fence, then you're probably better off not.

Cheers,

Bob


#5051985 Windowed Mode Using C++ & Free GLUT ....

Posted by Scourage on 10 April 2013 - 07:02 PM

Do you have to use FreeGLUT?  Why not pick something more recent (i.e have been developed on in the last 10 years), like GLFW or SFML? 

 

Cheers, 

 

Bob




#5033105 2D Rendering Engine Architecture

Posted by Scourage on 16 February 2013 - 12:37 PM

I would start by thinking of all the abstractions you want from a high level.   Then think of the abstractions required to support those, and keep working your way down until you're hitting OpenGL.  

 

I would think for a 2D engine, you would need the concept of a layers.  Background and foreground layers.  I would guess they need to be z sorted as well.  The layers are probably bigger than the screen, so they need some dimensions, and they might need to rotate, so a layer would need a rotation parameter.  You probably want to have sprites be on the layers, so layers need to have a list of sprites and where to put them (sprite position might be part of the sprite).  You probably need some kind of container for the layers to keep them in the right order for rendering (although simply sorting the list of layers every time you render probably won't show up in a profiler).

 

Sprites probably contain some kind of graphic, a position, scale, rotation.  If its animated, it might contain an animation time, looping variable, and a list of graphics to animate between. 

 

Your renderer might take a list of layers, sort them, then iterate over each layers sprites, rendering the graphic for each one.  Try to keep each object you design have one and only one job.

 

Hope this gets you thinking in the right direction. 

 

cheers, 

 

Bob




#5009498 Game Component Architecture

Posted by Scourage on 11 December 2012 - 12:50 PM

What I think you are talking about is parameter driven models (or components). If you want to have a bunch of zombies each with different health values, they all have a health capability, just with different initial values. Same thing with size, speed, aggression, etc.

My system (also a zombie game) uses this approach. In my entity definitions (which are lua scripts) I allow for functions to be used for initialization data, which then return randomized values (within a valid range) each time a zombie is created. This gives various types of zombies, some harder to kill than others with the same game object model and initialization script.

Here's my initialization script for a zombie:

[source lang="cpp"]ENTITY{ type="zombie"; inherits="baseEntity"; attributes= { type={type="string", value="zombie"}; state={type="string", value="wander"}; }; behaviors= { RenderBehavior = { model="../data/models/zombie/zombie.ms3d"; texture="../data/models/zombie/zombie.jpg"; scale={0.2, 0.2, 0.2}; --scale={1.0, 1.0, 1.0}; translate={0.0, 0.0, 0.0}; rotate={0.0, 0.0, 0.0}; animated=true; }; AnimationBehavior= { animations={ {name="walk1", start=2, finish=20, fps=24, loop=true}, {name="walk2", start=22, finish=36, fps=24, loop=true}, {name="damage1", start=38, finish=47, fps=24, loop=false}, {name="damage2", start=48, finish=57, fps=24, loop=false}, {name="fall", start=59, finish=75, fps=24, loop=false}, {name="prone", start=78, finish=88, fps=24, loop=false}, {name="die", start=91, finish=103, fps=24, loop=false}, {name="kick", start=106, finish=115, fps=24, loop=false}, {name="punch", start=116, finish=128, fps=24, loop=false}, {name="headbutt", start=129, finish=136, fps=24, loop=false}, {name="idle1", start=137, finish=169, fps=24, loop=true}, {name="idel2", start=170, finish=200, fps=24, loop=true} } }; CollisionBehavior= { radius=1.0; }; ScriptBehavior= { script="zombieAI.cs" }; AudioBehavior= { sounds={"../data/audio/zombie-brains1.wav", "../data/audio/zombie-brains2.wav", "../data/audio/zombie-brains3.wav", "../data/audio/zombie-moan.wav", "../data/audio/zombie-gurgle.wav"}, period=10 }; SenseBehavior= { range=function() return math.random(200,500) end; acceptTypes={"player"}; }; DamageBehavior= { health=function() return math.random(25,75); end; }; }; reflected= { "RenderBehavior", "AudioBehavior", "AnimationBehavior", };}[/SOURCE]


#5008798 archtitecture with callback

Posted by Scourage on 09 December 2012 - 08:47 AM

In GLUT there is a glutPostRedisplay() function that will redraw the screen for you. I'm not sure that this will pump any user inputs (as it would in GLFW), but it may. When you get a new caputure frame, update your PBO and then then call the postRedisplay() function to ask GLUT to redraw the screen.

GLUT and FreeGLUT are pretty old. I recommend GLFW as well (full disclosure: I've contributed to it in the past). It's a great windowing framework and gives you the primitives to build your own loop around.

Cheers,

Bob




PARTNERS