C++ question

How do C++ developers deal with not having an engine like Unity? How do they arrange stuff like we do in unity in the scene view? I stupidly imagine that they have to picture inside their heads where the object goes, and thats how they decide its Vector3 or whatever they call it.

Do C++ developers create their own engine like Unity? i know World of Warcraft has its own customized engine, but how about games like GTA 5 or Max Payne?

 

There are other engines that act similarly such at Unreal or Cryengine etc. Also you can do it all in code. Technically you don't HAVE to put much of anything into your unity scene view if you don't want, except a single Monobehavior to start things off. If you are building a large game with a predefined world you will want level tools for artists, but that could even utilize blender or 3d studio if need be. It really depends on your scope, budget and technology.

 

lol, I'd be very surprised if 'C++ developers' programmed all their game in C++. I'm sure they have written custom in house tools very similar to CryEngine, RedEngine, Frostbite, etc.

 

Most games are built off of engines that work off of this language or that. Dreamfall Chapters is on Unity for C#, Crysis was in CryEngine for C++, Everquest Next/Landmark is done in Frostbite for C++... The biggest difference c++ developers face is pointers. Pointers can suck to learn.

 

Pointers are pretty easy to learn. Just envision a 'pointer' is literally pointing at a block in memory. This is why you can increment/decrement the pointer to 'point' at a different address. Great fun begins though when a programmer increments out of bounds and starts overwriting memory that he did not allocate. The results are undefined but can lead to great tears tracking them down and resolving. A lot of your AAA games written in C++ will usually have some sort of Memory manager or tools to help track down stomps tho. So it's not all gloom and doom

 

Please dont tell ppl that C++ is all about facing Pointers. It exist smart pointers since quite a well, in GameEngine's even longer...

 

C++ is mid level language, aka neither high level nor low level. What will you do with c++, depends heavily upon your goal, budget etc.

An engine written from scratch is generally time consuming and done by a team of developer, people call them engine developers. Another way can be, you grab some existing code, lets say someone's network code, someone's gui code, even someone's renderer code and you match them up nicely. And/Or you add your own shader compiler. possibilities are virtually endless. Its like asking "what types of games can be done with unity?" or "what can we do with wheat?"

About pointer, its notion between declaration and "using inside code snippet", is confusing. Also pointer is a necessary evil. Not only general system memory but also, all other addressable memories can be manipulated with pointer.

 

I have a malloced non-const* pointer to an array of const* pointers to objects that begs to differ with that assessment.

 

Yep, if you don't have an engine you have to just program in the coordinates of everything. A bit of guesswork. A bit of maths. But we got by.

 

I don't mean to say that pointers are some mystical entity, but the fact is, if you haven't approached C++ before, it's probably what's going to give you trouble. Once you learn them, it's pretty simple, but as shaderop noted, they can get quite convoluted. Other than pointers though, c# and c++ are not that much different. c# is a notch higher, and thus a notch simpler. Some people seem to look down on that, personally, I think high-level programming is all indie developers should approach for the sake of budgeting.

 

Still just memory blocks. Still pretty simple when you look at in a Memory manager or draw it on paper.

 

[sarcasm]
Yes, just cast it to void*, problem solved. Why shoot yourself in the foot with a shotgun when you can do it with a bazooka.
[/sarcasm]

All engines are created in C++ or C, Unity too. You add some scripting like C# or Lua or visual scripting such that not only engine programmers can create game logic. But certain stuff that must be fast as S*** must be done in the core in C++ for a AAA title.

No large project can organize code like that, it would be one mess. You create separate independent modules and sub-systems. That's basic programming 101.
(That's why Unity has lots of bugs and is developed slowly compared to other engines: the code base has grown to a monolith and nobody wants to clean it up or start from scratch. Any software book will tell you what the effects of that are)

 

Would you mind pointing me to one of those "Memory managers" that you've used? It sounds like a useful tool to have.

 

Unfortunately they are all belonged to the companies I worked at. Now, for a home project, I did use Paul Nettle's Memory manager which helped me track down some problems.

 

That tool looks like it might be useful for detecting issues with memory allocations and deallocations, but I'm not sure how it would allow anyone having difficulty wrapping his or her head around pointers to—and I'm quoting you—"look at it in a Memory manager." By that time the lack of understanding of the subject has already done its damage, and having to use that tool sort of proves that it's anything but "pretty simple."

 

Then you misread my original post. I never said a Memory manager will help someone understand pointers. I said it helps track down memory stomps.

My post is quite clear.

Ah, maybe you're nitting at this post

No, I don't believe Paul's Tool has that feature. Sony has tools that do that sort of thing but you have to be a registered developer.

[edit] In Visual Studio (C++), you can get the equivalent. It is not difficult. In the watch window you can give it an address and look at the contents of memory. Granted, it won't show the rectangles around each byte or anything. I'll upload a picture in a bit when I get a chance

[edit - appending code sample]
Okay, so here is the challenge:

Code (crap how to get it to show C++)?...

Code (csharp):

1.  
2.     // Test
3.     struct Test
4.     {
5.         int32 x;
6.         int32 y;
7.     };
8.  
9.     Test * t1 = (Test*)malloc(sizeof(Test)* 3);
10.     Test * begin = t1;
11.     ZeroMemory(t1, sizeof(Test)* 3);
12.     size_t testSize = sizeof(Test); // optional, should be 8 and naturally byte aligned
13.  
14.     t1->x = 1;
15.     t1->y = 2;
16.  
17.     t1++;
18.     Test * t2 = t1;
19.     t2->x = 3;
20.     t2->y = 4;
21.  
22.     t1++;
23.     Test * t3 = t1;
24.     t3->x = 5;
25.     t3->y = 6;
26.  
27.     const Test * myArray[3] { begin, t2, t3};
28.     Test * easyPtr = const_cast<Test *>(myArray[0]);
29.  

Expected output (remember to set Memory window to display Int32). For me, easyPtr = starting address 0x0000000013031010

Code (csharp):

1.  
2. 0x0000000013031010           +1          +2          +3  ............
3. 0x000000001303101C           +4          +5          +6
4.  

In Visual Studio (C++), if you want to get a better understanding of how pointers work, you use a combination of the Watch and the Memory windows.

In Watch window, grab the address of easyPtr (after you set a breakpoint on it). Ignore the const/const_cast crap which is against most any decent coding guideline (Casting away const) and does not matter as far as the computer is concerned- since all it cares about is the memory that 'easyPtr' points to. Simply pull it up in Memory window and you'll see the entire arrangement of the pointe (or rather, the memory location it points to)

So yes- the syntax can seem confusing. But once you look at the memory directly you'll quickly acquire a low level understanding of how pointers work

Pointers are easy. Yes C/C++ syntax can get nasty. But pointer themselves are quite simple. They just simply point to a location in memory. That's it. Sure, maybe that code sample would fly over a noob's head but I bet they will understand that memory layout in 1 min (expected output)

 

So what you're basically saying is that pointers are easy as long as one doesn't have to use them in C/C++.

I guess I can agree with that.

 

Raw Pointers are by no a nobrainer, but since C++11 with the smart_ptr implementations i see less and less worry about them.

 

Smart pointers may be slow for some code sections.
Also - isn't malloc a no-no for c++ now?

 

It has been for a while. The "new" operator is what is generally used.

 

Your example was against most any decent coding standard (casting away const, malloc, etc). [edit] Now aligned_malloc is very useful. Well, to be fair, malloc is useful when you need to allocate a buffer. Anyway, that's another topic. But for sure you dont use malloc to allocate an array of objects. Use new operator

Here is a much simplified way to accomplish the same thing using proper coding conventions:

Code (csharp):

1.  
2.    // Test
3.    struct Test
4.    {
5.       int32 x;
6.       int32 y;
7.    };
8.  
9.    Test * t1 = new Test[3];
10.    Test * easyPtr = t1;
11.  
12.    t1->x = 1;
13.    t1->y = 2;
14.  
15.    t1++;
16.    Test * t2 = t1;
17.    t2->x = 3;
18.    t2->y = 4;
19.  
20.    t1++;
21.    Test * t3 = t1;
22.    t3->x = 5;
23.    t3->y = 6;
24.  

A beginning C++ programmer should be expected to understand this easy. If not, they should checkout Ivor Horton's Beginnning C books. He has an excellent chapter on Pointers!

 

And what example was that, if I may ask? If you somehow managed to construct actual code from my prose then I'm afraid that its your imagination that is faulty, not my nonexistent code example. Also if you don't know the difference between a const pointer to a non-const value and casting away const-ness then you really have no business advising anyone on pointers.

I'm not sure what point you're trying to make after you've gone through the trouble of constructing that whole straw man. One shouldn't use malloc? What if I'm implementing my own new operator? I shouldn't cast away const-ness? Point me to where I did in my imagined code example, which would still be indicative of your faulty imagination.