rdragon1

Using MSVC, this code:

int main()
{
  MyClass c( 12.0f );
  std::printf("Hello\n");
}

Looks like this in x86 asm:

00CE1260  push		ebp  
00CE1261  mov		 ebp,esp  
00CE1263  sub		 esp,44h  
00CE1266  push		ebx  
00CE1267  push		esi  
00CE1268  push		edi  
00CE1269  push		ecx  
00CE126A  fld		 dword ptr [__real@41400000 (0CE4838h)]  
00CE1270  fstp		dword ptr [esp]  
00CE1273  lea		 ecx,[c]  
00CE1276  call		MyClass::MyClass (0CE10C3h)  
00CE127B  push		offset string "Hello\n" (0CE4830h)  
00CE1280  call		dword ptr [__imp__printf (0CE7238h)]  
00CE1286  add		 esp,4  
00CE1289  lea		 ecx,[c]  
00CE128C  call		MyClass::~MyClass (0CE100Fh)  
00CE1291  xor		 eax,eax  
00CE1293  pop		 edi  
00CE1294  pop		 esi  
00CE1295  pop		 ebx  
00CE1296  mov		 esp,ebp  
00CE1298  pop		 ebp  
00CE1299  ret  

You can see the call to constructor and destructor at 00CE1276 and 00CE128C

Hi, I know that when a variable comes into existence its constructor will be called, and its destructor will be called upon exiting scope, I just wonder what those processes look like in assembly? I've been thinking like crazy!!

It looks like a 'call' or 'branch' instruction to call the constructor at the beginning of scope, and another call to the destructor at the end of the scope. They're just functions.

Of course, there may be optimizations at play that inline the constructor or destructor, so you might not see an actual call/branch/whatever instruction

per vertex lighting:

NdotL0 = dot(N0, L)
NdotL1 = dot(N1, L)
V = NdotL0 + t (NdotL1 - NdotL0)


per pixel lighting:

N = normalize( N0 + t( N1 - N0 ) );
V = dot( N, L );

like this:

D3DXVECTOR vObjPos = (D3DXVECTOR) *m_World.41;
D3DXVECTOR3 vDistance = vObjPos - camera.vEye;
float fDistance = length(vObjPos);

Isn´t this to inefficient for 100 leaves on a tree or 100 grass tufts?

What's inefficient about it? How long does it take on your hardware?

Computing the lengthSquared might be slightly cheaper as it'll avoid a divide, and you can sort by that just the same

I think you can make the same argument that the diffuse lighting calculation should be the same whether it's done per pixel or per vertex. In the per-vertex case you're computing the N*L dot product at the vertex and interpolating that to the each pixel. In the per pixel case you're interpolating the normal and computing the dot product per pixel but the dot product is a linear operation so it interpolates the same.

With specular lighting you have a non-linear term (a value raised to the specular exponent) which does not interpolate the same. Which is why vertex-lit meshes usually have  weird looking specular highlights.

Definitely not. You're talking about the difference between vertex lighting and per-pixel lighting. Calculating NdotL at each vertex and interpolating the result is not the same as interpolating the normal and calculating NdotL at each pixel.

Think of a quad with vertex normals pointing away from the center, and a point light source directly above the center of the quad.

sounds like you need to first learn Linear Algebra

Generally speaking, I'm a proponent of spending a majority of your time doing documentation. I've done my fair share of development, both for companies, on my own, or for my own company, games and non-games a like. Mainly, if you're doing a game, I'd suggest things such as Case Diagrams, Flowcharts, UML. If the operation is smaller, this would be an ideal time, to do detailed storyboards, wireframes of user interfaces. Whiteboards are your friend. Frankly, a lot of your common software development methodologies easily applied to games.

Regards,
Quinn

I recommend the opposite. Especially in the early stages, spend as little time in documentation as possible. Instead, get your game design ideas prototyped and into a working version as quickly as possible so that you can start iterating on them. This goes for 1 man projects through "AAA" games. You're not going to get breakthroughs writing words about your game - you need to iterate hundreds (thousands?) of times on something you can actually play to discover something great. The really good stuff is unintuitive at first, so you need to be a little reckless sometimes and just try things. You will throw away most of it, and that's OK.

Show me the line that assigns a value to initpop. I don't see one.

Is the winding order of the vertices correct? (ie, is the triangle facing away from the camera and thus getting backface culled?) Need more, specific data

One of the central design principles of C++ is "don't pay for what you don't use", so I don't know what you are all on about "C++ overhead". C++ programmers are very adamant to the language committee that we don't want features to impact performance if they aren't used.

C++ *is* commonly used in "low level" code, and you can write operating systems with C++ just as you can with C.

Comparing a popular version control system with an unpopular one and claiming the performance difference is due to using a C++ compiler vs a C compiler is just silly.

You have to loop through and delete each object the pointers point to. Vectors simply destruct the objects they contain. In this case it contains pointers, which have no destructor, so destroying one doesn't do much.

Or use a type to hold your pointer that deletes the object in its destructor (a "smart pointer")

Also, negative sizes or indices don't make sense, so use unsigned types for sizes/indexes. Preferably std::size_t so things like porting 32bit->64bit are far less painful.

Most shader debugging i've done is with "printf debugging" - that is, exiting early from the shader and returning some debug value that you can visualize to figure out what's up. Then just work your way through the shader until you figure out which calculation isn't returning what you expect, and go from there

This works better if you can hot-reload the shader while the game is running

He's fine to have those beliefs, but game development is "extreme performance computing", and it's not acceptable to sit back and "throw more hardware at it".

For consoles, there is no "more hardware" - you have what you're given, forever. Also, most consoles don't support JIT compilation.

For PC's, it means your competitors will automatically have all of the compute power you gave up to be able to use a managed language and at least be able to run on lower spec machines or at higher frame rates, or both. With garbage collected languages, it requires significant amount of effort to make sure the garbage collectors don't kick in at "the wrong time" and freeze your game for unacceptable periods of time.

I don't agree with the argument that managed languages solve many problems in game engine runtime development.

Here's a good reference for the new features/changes:

http://en.wikipedia.org/wiki/C%2B%2B0x

The "point" is simply that it's a next version of the language. It's not "extensions", it's simply an evolution of what C++ is from this point on. The C++ you know and love is "C++98" or "C++03". This version is expected to be "C++11".


I don't think a central focus is to make it easier for beginners to start with. C++ is a high performance systems programming language meant to be able to get "close to the metal", and there are simply tradeoffs to make where adding essential capabilities will indirectly make the learning curve steeper. That said, there are lots of other features (for example, lambda functions) that make obsolete current tedious conventions and replace them with something much more elegant, which will indirectly make the learning curve easier.

In short, it adds lots of stuff and changes the way lots of existing stuff is done. As a C++ developer for several years, I welcome the changes. It will result in less code that's more readable, and get rid of some of the nasty hacks that we've come to love. It will also enable expressing new things, and new idioms will appear, which will evolve over time and make C++ better.

That's the GUID for the shader reflection interface. You'll also need to link against dxguid.lib

This bit me too. Would be nice if it were in the docs