Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Feb 2001
Offline Last Active Jul 13 2015 02:58 AM

#4898321 Need help with my .OBJ loader...

Posted by on 30 December 2011 - 07:10 PM

For debugging, a much smaller test case would be preferred. Can you export a single 4-sided poly, and does your code correctly read it in and turn it into triangles? If not, start there. In that case it's easy enough to understand what the results should be by hand, so stepping through your algorithm in a debugger should be much easier.

#4898318 What would RAII look like in assembly?

Posted by on 30 December 2011 - 07:05 PM

I just ran the program in the debugger and switched to the disassembly window.

For your other question, the destructor will be called whenever the object goes out of scope, so the compiler will add another call to the destructor just before that other return.

#4898300 What would RAII look like in assembly?

Posted by on 30 December 2011 - 06:08 PM

Using MSVC, this code:

int main()
  MyClass c( 12.0f );

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

#4898297 What would RAII look like in assembly?

Posted by on 30 December 2011 - 06:02 PM

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

#4898261 Per pixel point light: interpolating vertex world pos

Posted by on 30 December 2011 - 03:56 PM

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 );

#4898249 Sorting alpha-blended objects

Posted by on 30 December 2011 - 03:29 PM

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

#4898235 Per pixel point light: interpolating vertex world pos

Posted by on 30 December 2011 - 02:27 PM

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.

#4897699 How to get Lookat Vector ?

Posted by on 28 December 2011 - 10:26 PM

sounds like you need to first learn Linear Algebra

#4842723 The Process of Creating A Game?

Posted by on 30 July 2011 - 09:22 PM

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.


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.

#4838420 Functions and Variables (C++)

Posted by on 21 July 2011 - 06:59 AM

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

#4837381 DX11 full screen quad problem

Posted by on 19 July 2011 - 07:59 AM

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

#4836200 why is C++ not commonly used in low level code?

Posted by on 16 July 2011 - 06:28 PM

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.

#4836170 vector Clear method....C++

Posted by on 16 July 2011 - 04:44 PM

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.

#4835980 how to debug glsl shader

Posted by on 16 July 2011 - 07:05 AM

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

#4835907 What's the point of C++0x?

Posted by on 16 July 2011 - 12:05 AM

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.