Basic core engine

About the actual programming of the game.

Re: Basic core engine

Postby adam » Fri Aug 30, 2013 7:51 am

Pseudonym wrote:
croxis wrote:My understanding of a "pure" ecs (from the t-machine article) is that components just hold data and have no functions of their own -- their internal states are read/written to by the appropriate systems. That being said two ecs systems I've seen (unity and spout) have convenience functions in the components. I understand the need for a more pragmatic design though.

Do you have a link to that article?

I don't see a problem with either approach in principle. Whether you tell a sound effect to play itself or get a sound effect which you play... it doesn't matter to me as long as we stick to one. However, I can certainly imagine that some components may have to make some decisions which require logic, like deciding whether or not the enemy and the player have line of sight.


Here is my article about ecs which describes how components should be data only http://www.gamedev.net/page/resources/_/technical/game-programming/mvc-and-cbes-as-it-relates-to-game-programming-r3114
adam
 
Posts: 113
Joined: Tue Aug 20, 2013 11:58 am

Re: Basic core engine

Postby croxis » Fri Aug 30, 2013 4:31 pm

Pseudonym wrote:Do you have a link to that article?


http://t-machine.org/index.php/2007/09/ ... nt-part-1/

5 part series, some of it specific to mmo.



http://piemaster.net/2011/07/entity-component-primer/

Another tutorial with a bit more concrete examples.
croxis
 
Posts: 282
Joined: Tue Aug 13, 2013 1:37 am

Re: Basic core engine

Postby Pseudonym » Sun Sep 01, 2013 9:47 am

Having read through the blog post on Artemis, it sounds extremely persuasive. I understand Adam's point that component attach and detach could become a bottleneck in a multi-threaded environment. If that's the case, I think that the "right" answer is to use lock-free techniques.
Pseudonym
 
Posts: 129
Joined: Tue Aug 13, 2013 3:54 am

Re: Basic core engine

Postby jherico » Wed Sep 04, 2013 9:01 pm

Pseudonym wrote:
adam wrote:For math wouldn't glm be a decent choice as it is designed for OpenGL and GLSL inherently.

GLM is a decent choice, but it has several problems. Rather than badmouth GLM (it is a decent library despite its weirdnesses and quirks), I'll just note that its main strength is also its main weakness: it's inherently designed for OpenGL and GLSL, which means you need to do as much work to interface it with anything else (e.g. a physics engine) as it takes to just write the operations you need in the first place.


That doesn't make any sense to me. There is no universally accepted math library, so any off the shelf library used would require translation at points where it interfaces with another system that uses it's own representations of vectors, quats and matrices. Same thing with writing your own math library. In other words, it requires exactly the same amount of work to interface any math library with another component, regardless of whether you wrote the math library or not. The only way around that is if you write every single component yourself around the same math library, in which case, there's still no reason not to write it around something like GLM rather than something your write from scratch.

GLM has a number of advantages. It's extremely complete in terms of operations (lots of libraries I've seen just implement some basic operations and leave out critical things like applying a quaternion to a vector). It's header only, so you're not saddled with additional library requirements. And it lets you use for the most part the same syntax in your C++ code that you use in your shader code. In the longer term I expect that these advantages will eventually make glm the most widely adopted math library for C++ for non-SIMD applications. It's also actively developed, so new features and bugfixes show up without effort on our part.

Pseudonym wrote:It's just not that hard to write fixed-size matrix multiplication.


GLM is over 2 MB of code, 10 MB of docs and almost a megabyte of test cases. You just hand-waved several man-years of work. Neither is it hard to write a string class or a linked list, but I doubt we're going to be doing any of that. And even if we did, we'd be stupid, because there's no way our version would have the functionality and test coverage of the 'real' versions. As far as I can tell GLM is the 'best in class' of (free) C++ math libraries, so unless it's a project goal to actually to write something of that level of quality and make it something that people could download and use independently of the game, it's a waste of man-hours not to just use it.
jherico
 
Posts: 13
Joined: Wed Aug 21, 2013 2:35 am

Re: Basic core engine

Postby Pseudonym » Fri Sep 06, 2013 5:19 am

I did mention that I don't want to badmouth GLM, and I'm still not going to do that, but I do think I need to expand on what I said.

jherico wrote:GLM has a number of advantages.

That's true.

jherico wrote:It's extremely complete in terms of operations [...]

Leaving aside a couple of misfeatures or outright bugs (which are admittedly rare, but they do exist; did you look at the semantics of operator++ on a matrix?), many operations are available, but not type-safe. This is a huge red flag for me. GLM does not, for example, distinguish between points, vectors and normals, and will happily let you use them incorrectly.

Of course I know why GLM does this: it's the way that GLSL does it. GLSL needs to be compiled extremely quickly, so lots of type analysis is probably a bad idea.

Look at what's not there: planes, frustums, cones... all of those necessary geometric objects.

Also bear in mind that we hope to use SIMD operations for a lot more than just graphics. We might be using it for audio (unless there's a good off-the-shelf solution). We will probably be using it for NPC AI if we ever need it. GLM doesn't support some of the operations we want, and even if it does, it doesn't let you automatically adjust at run-time for whatever the host CPU supports.

I don't want to write off GLM. It's useful and pragmatic for many purposes. Right now, it seems like a poor fit for what we're specifically trying to do.

We could try to make GLM better, but I suspect that they don't want to sacrifice GLSL compatibility even if GLSL gets it mathematically wrong. Alternatively, we could just copy anything nontrivial that we need (respecting the MIT licence, of course).
Pseudonym
 
Posts: 129
Joined: Tue Aug 13, 2013 3:54 am

Re: Basic core engine

Postby plop » Fri Sep 06, 2013 4:58 pm

For the SIMD part, bullet's vectormath lib is the best choice, IMO.

However, a SIMD math library is not easy to use. You can easily write slower code than its naive scalar equivalent.
I think it would be a good idea to have an easy-to-use scalar math library for "high level" and non performance critical code.
GLM would fit in this role, but I'm not particularly advocating GLM.

EDIT: does someone know a serious alternative to GLM? Writing a math lib from scratch - and testing it - might be very time consuming...
plop
 
Posts: 15
Joined: Mon Aug 19, 2013 9:33 pm

Re: Basic core engine

Postby Zcool31 » Sat Sep 07, 2013 4:34 pm

The Eigen math library, to my knowledge, does various alignment and vectorization internally, and is no more difficult to use than the standard complex type.

http://eigen.tuxfamily.org/index.php?title=Main_Page
Zcool31
 
Posts: 7
Joined: Fri Aug 30, 2013 11:58 pm

Re: Basic core engine

Postby Qworg » Sat Sep 07, 2013 4:53 pm

I really like Eigen. I use it in much of my 3D perception work.
Qworg
 
Posts: 23
Joined: Wed Sep 04, 2013 11:16 am

Re: Basic core engine

Postby Pseudonym » Tue Sep 24, 2013 2:07 am

Pseudonym wrote:Leaving aside a couple of misfeatures or outright bugs (which are admittedly rare, but they do exist; did you look at the semantics of operator++ on a matrix?), many operations are available, but not type-safe. This is a huge red flag for me. GLM does not, for example, distinguish between points, vectors and normals, and will happily let you use them incorrectly.

I'm dumb. In retrospect, there's an obvious solution: Wrap GLM in a layer of type-safety.

This ticks all the boxes: it solves the problem (GLM follows GLSL's API, even when GLSL is wrong), it imposes essentially no cost at run-time, and it limits the code that we have to maintain to only that which GLM doesn't provide.
Pseudonym
 
Posts: 129
Joined: Tue Aug 13, 2013 3:54 am

Previous

Return to Code

Who is online

Users browsing this forum: No registered users and 1 guest

cron