rnlf

CBase(unsigned int spaces(1), char* cpName)

What's this (1) supposed to mean?

Why don't you use for-loops instead of building for loops out of while loops? Maybe you find your error faster if you don't have to deal with unnecessariliy bloated code...

 

And are you sure, your loops in Drawtoscreen are supposed to loop while <= MAP_SIZE; not <MAP_SIZE?

Yeah, looks like you start the program from your IDE, which does not keep the console windows open after the program ends, so after displaying "bonus: foo", the program ends (as intended) and the console window belonging to it is closed by Windows. Do what Aliii proposes. Maybe use cin::get() so you don't have to add more headers.

From the C++11 standard, section 8.5:

 

The form of initialization (using parentheses or =) is generally insignificant, but does matter when the initializer or the entity being initialized has a class type; see below.

 

So it should really result in the same assembly being created for pointer initialization. It has, by the way, little to do with the new keyword but rather with the initialization of the object p.

 

Edit: Damn you Hodgman. You're just to fast for me

How can you ever hope to accomplish anything without using formal mathematics? Even your programming language's syntax is formal mathematics (thus the name "formal language"). So by writing a program you do actually use formal mathematics.

 

Also, without formally finishing your derivations, you will write unneccessarily complex code, which will often lead to slower code.

 

On the other hand, there seems to be no sensible reason not to use mathematics. Or can you name even a single one to back up your statement?

Just as an addition, I always prefer using the C99 header stdint.h (also available as cstdint in C++) and the types uint8_t and similar and not handling this mess myself. In one company I worked for, this was not done and during a switch to 64 bit I had to update a whole bunch of header files with lots of #ifdefs to take care of this. Had the project used stdint, it would have saved me a whole day of debugging to find the problem and fix it.

Don't go for the 3d engine too quick. Take your time to really understand the basics of programming. Read books or online articles about efficiency and correctness. Do some serious work on 3d maths. Study other engines' structures. Blender may be interesting because it can show you how artists think about 3d data (and how that may differ from a programmer's perspective).

 

So, yes it is possible to write a polished 3d engine in C++, even on your own, but it is nothing you can do in a few months or (depending on your learning curve, spare time and motivation) even years. Keep that in mind. Also, if your goal is to write a game, write a game, not an engine.

 

Ruby is a fine language and I see no reason why it shouldn't be usable as a high level scripting language.

 

EDIT: Oops. Typo messed up the meaning.

I did never write a lot of scheme, but it looks to me like you have one closing parenthesis to much in line 2.

You could use OpenGL, but this means you'll have to write a lot of shader code to do this. And since you (I assume) don't have to make it a real time program, you might as well use the CPU instead. If you are allowed to use it in course, take a look at OpenCV, which is one of the most used libraries for image processing / computer vision.

 

It should have at least Sobel and median filters built in, but they are really easy to implement yourself (and doing so will teach you some of the most importent basic tools and techniques in field), like simple matrix convolutions, image formats and the like.

I don't think there is a function to lock the cursor in position (shame on me if I'm wrong), but you can call XWarpPointer every time you receive a mouse event, which has the same effect.

You will overcome this problem by adding a check for the level of your current node. Quick example (please put it together with the rest of your code yourself):

[source lang="c++"]void create(std::shared_ptr<OcTree> _tree, int level) {... all the rest, test for intersections and stuff ... if(cnt <= 1 || level > max_level) { ... all the stuff you do in your original code, except that you may have a list of nodes instead of only one ... } else { .... create(..., level + 1) ... }}[/source]

Hope this is understandable, don't really have the time to go more in depth at the moment.

The most important thing about being a programmer is "getting things done". You will earn credibility iff you get things done. It can be quite a lot of fun to design your own engine and writing the best possible code around this design for years, but unless you produce a real game with it, it is worth nothing.

That being said, it is quite an advantage if you still try to write the best code possible, if you keep in mind, that you have to get finished some day. Sometimes a (well considered) hack will save you weeks of work. If you make sure not to hurt the rest of your code with this hack, it's in my opinion absolutely okay to use it.

Also "professionals" are not writing their engines from scratch. There are TEAMS of engine developers who create the engine which a TEAM of game programmers uses. Would you say the team of game programmers do not do real "game programming" just because they didn't write the engine themselves?

In fact, it is a sign of a good engineer that he does not re-invent everything. If every car designer had to re-invent the wheel, we would still drive around in horse carriages.

Yes, he tries to stop the recursion. create will only create child nodes if the number of intersections (however they may be definied by bbox.intersects) is greater than 1.

But I still guess the abort criterion is wrong. If there are overlapping scene nodes, "create" will never reach its stop criterion.

Does it work if you use an empty scene graph or make sure there are only scene nodes that are far enough apart?

But passing the current depth recursively to create and adding a condition for this depth to be below a configurable value around line 27 of octree.cpp should solve the problem.

To elaborate a bit: bricks[2,4] is still valid C++, take a look at http://en.wikipedia.org/wiki/Comma_operator.

What it actually does is discard the value of 2 and use 4 as the array subscript. As a result, bricks[2,4] evaluates to bricks[4], which is of type bool[5], thus the incompatibility error.

CatmanFS: Not quite sure, what you mean, but if you want to have a vector<int*>'s element point to instances of anything different than ints, you will have to use an explicit cast. This will work maybe, but is more or less one of the most evil things to do.

Also, as Cornstalks already said, using raw pointers instead of smart pointer creates a lot of potential problems later on.

Edit: you ninja, BitMaster