If you're running under the simulator, it actually compiles an i386 version of your iOS to execute.

I know, but this happened on the device... I'm not sure that the situation was that exactly, but at least now it works as it should.

In the end it was an xcode bug mixed with a mistake - in a subfolder of the "Framework Search Paths" there was the folder where I compiled the OSX version of my library.
For some malignant reasons, it found that library in the subfolders, and while actually compiling the .cpp files in the project, it would link with the OSX version.
I really don't know HOW it could link an ARM app with an i386 app, but removing the folder from its reach, it worked.

I think that the whole marketing thing is because they realized that it isn't a good game, and they cannot achieve the same success with another "non angry birds"... I think they would fail miserabily really.
And that clashes with their self-assigned image of "market changers" "new nintendo" "new way to make games" and whatever.
And so they milk the cow until they get some idea to live up to their own hype, if they can.

The code

Code:

platform->initialise();

does not cause the execution of initialise(), instead reliably executes

Code:

virtual ~Platform()
{

}

The sheer genius of XCode bugs never ceases to amaze me, it is like some evil mind coded it with the most obscure behaviour to test those worthy to publish on AppStore.

-cut-

Now that was an good rant to read 

I'll echo the recommendation to create the engine along-side your game. Here's a very worthwhile read: http://scientificninja.com/blog/write-games-not-engines

This must be carved in stone somewhere, it's exactly what i meant.

Ok, I misunderstood that!
Good luck 

Now time to write an engine, and then a game to use that engine... *evil laugh*

random advice: do both at the same time, or you will end up with an "engine" that fits absolutely no purpose and has to be constantly hacked to be used in a game.

short version: you don't know how to make a game, so you can't write an engine.

I think Paul Eres' signature should be sticked somewhere in the front page, it is made of truth.

Designing a game in detail.

I was generally a design-hater, only to find out that when you really know what you're designing, knowing upfront what to code cuts development time by many times.
Now I only start implementing things when I wrote most of the headers and the game design. It is SO faster.

Braid

Or basically any hand drawn game?

Wow, now that's a bug. Recompile? 

Probabily you've stumbled on a compiler bug, looks like it is not generating the same data structure for your class in any compilation unit... but it is really strange that it works on *any *cpps but not on headers, as h's *are* cpps, in the end.
Looks like it can find somewhere an older copy of the declaration of your class, one that by include order is compiled just before your headers?

That article was really interesting, thanks  

Anyway, voxels do not have dimensions, they are just points that happen to be defined in a grid.
So, when that grid is sparse and you can place the points nearly anywhere, "sparse voxel tree" is exactly equivalent to "point cloud tree".

Maybe the one slight difference is that at leaf level voxel are stored into a micro-grid that represents world data and is contiguous to related micro-grids, while in the point could tree there is no leaf level and any node only owns a map of childs and positions. They only differ in the resolution of the samples: with a microgrid it is the resolution of the grid, with the list it is the granularity of float/int.

In both cases the structure can model volume objects with no effort, if they happen to model only the surface is to use less space when the data can't be changed.

In fact one thing I'm curious about this tech is the typical precomputed/dynamic conflict: it is reasonable to think that if their "point search algorithm" is so fast, they have LOTS of baking to achieve this speed.
And then poof, goes one of the key advantages of voxels, that is interactivity.
In fact you couldn't dig into those structure, because each change would require a non-realtime amount of re-baking.
But after all, who knows.

why do people keep calling this voxels or octree rendering -- i thought the video is clear that it is neither of these

I'll concede you that I should have said "tree" instead of "octree" as we do not know what type of hierarchy they use, and in fact I don't think it is an octree... also, voxel has traditionally meant something that is part of a grid (as a pixel) so it is not what they are using.

But other than that, "sparse voxel tree" is synonimous with "point cloud tree", and they are definitely rendering hierarchies of point clouds arranged in some tree, as they clearly state that.
The point search algorithm should be something really clever as it approximates the first bounce of a raytracer, but still this has been done a lot of times - I think that all the hating they received is because they accurately avoided all the heavy drawbacks of their tech to advertise it as a generic silver bullet... and that's bullshit.

assassin's creed

Actually this has been done

because the technology would be stolen instantly

A technology that can be stolen instantly from a binary demo is worth nothing, someone will get to it eventually, and very soon.
Even if I shown you the Google PageRank code you could not "steal it instantly"... it would hardly make sense.

It is not a scam, it is just really uninmpressive when you trim off the marketing bullshit.

It is a sparse voxel octree raytracing that renders a small amount of instanced point clouds, notice the extreme tiling shown even in the video.
Everything is static, even the lighting, and everything is in core memory.
This is really old and already done without crazy claims of revolutions, and even something like ZBrush manages to do this better.

Voxels' problem has always been and is the huge amount of both RAM and disk memory used and staticity, and this makes absolutely no attempt at solving those problems.

Verdict: marketing bullshit  

On the other hand, for a few games that do not mind its limits but need such detail, this could be interesting!

Unpaid: check
no team: check
no previous work: check
team leader is an "idea guy": check
project is overly ambitious with scope: check
fear of idea stealing: check

Diagnosis: this won't be done.

Not to be too harsh, but this kind of project really comes up every other day, and I've still to see one going past the prototype stage.
Try a more focused approach, try a simpler idea, try to learn something that is not writing, because with any team smaller than 20 peoples writing is actually irrelevant past design stage.

my two cents  

This could in fact be the one and only game where the Wii Vitality Sensor could have an use AT ALL!

Bravo, I thought it would be never useful for anything.

Actually I've got a 9800 GT. Quad-core intel processor.

Now sir, this is why nobody uses opengl  
That's an on-steroids version of my system... why the heck it runs so slow? I think I need to do some profiling on other machines...
see the "TPF" or "Time per Frame" stat on top left of the screen? It should be consistently < 2.2 ms... what timings do you get?

mmm... I would really like to remove the crash, but I don't have any Intel (un)powered machine.
Maybe adding some logs it would be possible to know at least *what* crashes...