Irrlicht Engine

BTW: git is also an alternative. But IMHO both have the same chances to lose code somewhere in one or the other branch.

I would also advice against Git. While it's not bad per se, I experienced it as quite complex (there are some commands with the same name and different actions in git and svn/hg ...

Just use the stl ...
And if you really need formatting use boost.

greenya wrote:

Code: Select all

c8 str_c [ 10000 ]; 

and never worried about that any more.

Because the number is large doesnt mean it won't happen ... especially as 10000 is not _that_ large. Can anyone say buffer overflow?

@Ion Dune:

_Much_ better solution.

It's not incorrect per se. It's just bad style, old (C) style and buggy. If you use a pointer you have, of course, to allocate some memory ... you cant just start writing at 0x00. When you use a array of size 32 you should NOT write something there thats longer than 32 chars. Ever heard of buffer ...

ROFL ...

Do you actually know what this line means:

c8 str_c [ 32 ];

There is no difference between arrays and lists as far as sorting is concerned!

The advantage of list for insertions is offset by the need to traverse the list to get to a location. Random access to an array is O(1).

If you want to be able to cope with many nodes in a path-finding algorithm use a ...

A binary heap uses a binary tree. It's just not ordered totally. It's only guaranteed to have to min or max element in front.

Why is sorting with binary heaps faster than bubblesort?
Bubblesort is obviously O(n^2).

You can insert a element into a binary heap in O(logn). You have to do this n times ...

I'm sorry to say, but you got several things wrong.

Sorting: You described something that could best be compared to Insertion sort. Thats a O(n^2) sorting algorithms. Try heap- or quicksort. They run in O(n*log(n)), which is much faster (Break-even point is around 5-9 elements).

True is: If you ...

You should use in-place algorithms for sorting. They dont require any reallocation.

I also think that inserting at the end is so uncommon (I use std:vector regularly in high performance computing applications).

The bad thing about benchmarks is reproducibility. I did my own test (in java though ...

Array is faster when iterating.

From a technical PoV: yes.

List is faster when inserting extracting elements.

Not if you insert elements at the end of an array. Even with reallocation.

If number of elements is dynamic, its better to use list, especially if you deal with 1000 objects ...

Try removing ifs ...
Branches are really slow, as they cause shader threads to diverge (see CUDA docs)

IMHO a component model fits well into the distinctions you have to make when using a approach with different engines:

You have a Irrlicht-scenenode and some code to get it drawn.
You have a physics-node and some code to get it into action.
You have scripts for a object.

That are all pretty ...

Ion Dune wrote:I had planned to use structs, but it seemed a little old fashioned so I wanted to see what was recommended in cpp for this kind of thing.

In C++ a struct is a class with default accessibility public. (If its not a POD, but you shouldnt be concerned about that). Conclusion: Using structs is ok.

If you haven't already done it, download the irrlicht source code. Look up the collision detection part. Learn how it works and apply it to your camera.

Or use the forum search... I'm pretty sure that topic came up a few times.

Array initializers must be known at compile time. So they are not allowed to be stored in a structure. Of course values in this example could be retrieved by constant folding, but thats not generally true.

As for unions and const-casts. Both is possible and should be considered evil .
Const is just ...