Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 20 Feb 2007
Offline Last Active Jul 31 2014 08:28 PM

Posts I've Made

In Topic: Irrlicht any good?

13 December 2012 - 12:48 PM

I've used them both quite extensively, and they are both capable tools. I would say that for a true 3D game, wanting to use the most modern rendering techniques, Ogre is probably a better choice. It has a much more flexible material system, and supports deferred rendering out of the box (as of Ogre 1.8). Some people dislike the use of singletons or it's reliance on a scene graph, but those are minor quibbles when you're trying to make a game. It's not a religion, it's an engine.

Irrlicht is a slightly different beast. It's much less feature rich, but it's very tight, and it provides some higher level functionality that Ogre does not (though Ogre CAN provide that functionality, it just requires coding from the developer). This is mostly in the 2D space, where Irrlicht comes out of the box with an entire orthographic drawing library.

I am currently using Irrlicht (via the IrrlichtLime .NET wrapper) in my project, because it's 2D and I like the easy to use built in 2D functions of Irrlicht. That said, they are rendering engines, not game engines. If you want a game engine, you're better off going the Unity or UDK route (I'm not sure why you don't want to learn C#, if you know C++ you basically already know C#...I sense some bias there).

In Topic: Solid 2D engines worth considering?

13 December 2012 - 12:35 PM

I rarely, rarely ever recommend this...but in the 2D space, you should probably roll your own. There just isn't a lot of movement in the 2D engine space, and through my own research, most people will just point you to a 3D engine and tell you to use it with an orthographic projection. That's fine, I guess...but in many cases those engines will be saddled with tools and processes that are completely unhelpful for 2D development.

I was surprised to find that the actual tools to create 2D content were readily available (things like Mappy, Tiled, Paint.NET), but the engine to use them just weren't around, had terrible licensing terms, were too focused on one bit of technology, or weren't feature complete.

In the end, I ended up rolling my own using IrrlichtLime as a very simple wrapper around DirectX and OpenGL. I have access to the fully hardware accelerated pipeline if I actually need it, but I'm not saddled with a bunch of tools I can't use and hoops to jump through. I use IronRuby as my scripting environment, as it allows me to embed Ruby (my favorite scripting language) very easily in a .NET app, even allowing me to sub-class native side engine classes directly from the Ruby code. I've integrated Tiled in to my pipeline for creating maps and I use Paint.NET for all my art.

From engine start to "making a game" took me about four months. Mind you I'm an experienced programmer who has been writing code professionally for 12 years, so writing large complex software is not a daunting challenge for me. Your mileage may obviously vary.

In Topic: How does C# handle pointers internally?

13 December 2012 - 12:18 PM

They aren't "pointers" in C#, they are references. This sounds like a non-important distinction, but it is important because C# has actual pointers as well.

.NET does not use reference counting, it uses a generational garbage collector where objects are moved along the generations as they are no longer rooted to another non-collected object. You'll hear the terms "anchored" or "rooted" a lot when dealing with this kind of GC. You'll also hear terms like "gen1 object" or "gen2 object", and this just has to do with where in the GC process the object is. Note that this is all true for the reference implementation of the .NET framework. It's quite possible that projects like Mono have their own implementation, though I am almost positive that Mono uses a very similar generational GC.

That said, your understanding of what's going on from a high level is correct. When you put a reference to your object in to that list, the list now holds it's "root" (or one of them anyway, you may have references in other places). The fact that the variable the reference was assigned to is local means nothing. That local variable will fall out of scope, but the reference it was attached to will not be swept by the GC because you have it anchored in that list.

In Topic: GCC issue with "typedef typename ..." line (ok with MCC)

01 February 2010 - 01:31 PM

I can't test this, because I don't have GCC readily available, but I'm pretty sure you don't need typename in your deceleration.

Just do typedef forward<_node_data_type> _node_type;

In Topic: Redundant Scripting?

08 January 2009 - 04:56 PM

Since I think you are both writing MUD servers, and scripted objects in a dynamic environment are important in that arena, you may want to look at some of the other OO MUD servers like DGD and ColdC. DGD is an LPC server with some modern programming concepts sprinkled in. They both may give you guys some interesting ideas.