Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 24 Apr 2010
Offline Last Active Today, 02:54 AM

#5057382 dx9 tutorial help

Posted by Khatharr on 27 April 2013 - 07:59 PM

D3DXMATRIX matRotateY, matTranslate, matWorld;

//generate the rotation
D3DXMatrixRotationY(&matRotateY, index); 

//generate the translation
D3DXMatrixTranslation(&matTranslate, x, y, z); 

//concatenate them into the world matrix - if you add scaling then it comes first (world = scale * rot * trans)
matWorld = matRotate * matTranslate;

d3ddev->SetTransform(D3DTS_WORLD, &matWorld);

#5056552 dx9 tutorial help

Posted by Khatharr on 24 April 2013 - 10:09 PM

To draw it more than once you just change the transform and then draw it again.




should be what you're looking for.


You have to reset the world matrix for every time you render the model. That means set the matrix to the identity, then do your scaling, rotation and translation -> every time. Once the matrix is set just do your draw call.

#5056504 C++ - freeing dynamic memory

Posted by Khatharr on 24 April 2013 - 05:31 PM

This is all good advice, but do make sure that you get comfortable with raw pointers and manual memory management as well. There's all sorts of exciting trouble that you'll miss out on if you don't. (Seriously, though. These are core concepts, so get good with them.)
A pointer is a numeric value that is typically used to store a memory address. It's not the data. It just points to the data.
A pointer is just a number:
char* aPointer = (char*)100;
aPointer -= 50;
std::cout << "The number is " << (int)aPointer << "..." << std::endl;
//Note: Do not do this in production code or the skeleton man will eat you.
You can use a pointer to point to things on the stack:
int ary[] = {5, 6, 7};
int* aPointer = ary;
std::cout << "The array contains: " << std::endl;
std::cout << *aPointer << std::endl;
std::cout << *aPointer << std::endl;
std::cout << *aPointer << std::endl;
//Note: You can get fired for that too, unless you have a really good reason.
Or you can use it to point to dynamically allocated memory.
The thing to really grasp in that case is that new and delete are just functions with their own weird syntax. 'new' reserves a block of memory from the heap, and 'delete' releases a block that was previously reserved by 'new'. They're almost completely unrelated to the pointer or pointers that you use to keep track of that block during its lifetime.
One way to think of it is to think of memory as a set of pay lockers. 'new' puts a quarter in the slot (reserves the memory) and you write down the locker number (address) on a note-card (pointer). You can copy that number to another note-card or really do whatever you want with it. Just remember to return the locker key at the end of the day (delete).

#5056306 dx9 tutorial help

Posted by Khatharr on 24 April 2013 - 03:10 AM

Ain't reading fun?

#5055048 What is an entity?

Posted by Khatharr on 19 April 2013 - 04:32 PM

It's not a concrete term, but the general understanding is that it's a 'thing' within the simulation that interacts with other things.

Players, NPCs, items, etc.

Not menus or sound effects, etc. (Usually.)

In your own game you make the call yourself where to draw the line.

#5054782 Coding Style: Curly Braces

Posted by Khatharr on 18 April 2013 - 09:29 PM


Get in the dome.

#5054494 Coding Style: Curly Braces

Posted by Khatharr on 18 April 2013 - 03:13 AM


The reason this style is bad is because it's inconsistent and doesnt align the matching braces.  The opening brace is at the end of the first line of the code block, while the closing grace is inexplicably on its own line after the code block.  No consistency whatsoever.  Since you're aligning the end-brace with code instead of an open-brace, that open brace might not even be there and you'd never notice until the compile fails, which might be a significant amount of time wasted on big projects.


It's not bad. It's just not the style you use. The end brace matches the block owning statement. It reads very naturally to people who prefer that style.

#5054377 FADD vs FMUL time

Posted by Khatharr on 17 April 2013 - 07:12 PM

A lot of time and effort (and die space) spent on optimizing fmul.

Are you asking for the specifics of the floating point ALU? That's getting pretty deep, man. I'd be curious to see it if anyone has access to that info.

#5054098 RECT font_rect

Posted by Khatharr on 16 April 2013 - 11:21 PM

Syntactically? Yes. RECT is a POD struct. It's just a container for data. If that's the Windows RECT then it's just a container for four 'long's.


Are you getting some kind of bug or error?

#5054088 class problems

Posted by Khatharr on 16 April 2013 - 10:52 PM

How come you don't delete gameInstance?


The page it exists in will be freed when the application terminates. It's good form to do it anyway, but on most platforms it's not necessary in a case like this.


The real question is why it's dynamically allocated in the first place.

#5053981 Academia

Posted by Khatharr on 16 April 2013 - 03:39 PM

The right balance depends on the scope of the variable. If you've got a 3-line loop body, with Vec3 p = blah.position; as the first line, then there's no problem, as further explanation about what 'p' means appears in the same context.
If someone has a member variable named 'p', then the class better be pretty damn simple/small/self-explanatory.
If someone has a global variable named 'p', they can GTFO ;-)

The larger the scope, the longer the appropriate name length.


Yeah, that sounds like a reasonable line of reasoning.


I think it's reasonably reasonable for you to say that his reasoning is reasonable.

#5053342 Multiline comments - why the extra stars?

Posted by Khatharr on 14 April 2013 - 11:14 PM

I like to indent the stars in the subsequent lines so that all the stars are in the same column.


Very satisfying.

#5052955 dx9 tutorial help

Posted by Khatharr on 13 April 2013 - 05:03 PM

You'll want to create a static model of your pyramid. That means no variables in the pyramid declaration. Once that's done you use a transform to place the pyramid where you want to render it in the world.


This process is described in lesson 5 on the site you're using.

#5052732 How was this achieved?

Posted by Khatharr on 13 April 2013 - 04:07 AM

Depth testing is performed by the graphics hardware. It would be horridly inefficient to do it on the CPU. I think you're still not understanding how the depth buffer works.


It may be easier to understand it in 2D terms. Say you have a 10x10 grid of pixels that represent your render target. In order to simulate depth you'll need a 10x10 grid of pixels that hold the depth value for each pixel in the render target. Now, when you draw a sprite to the grid, you also specify a 'depth' for that sprite. For each pixel being drawn to, if the current value in the depth buffer is 'under' the sprite depth then the depth value is for that pixel is updated and the color value is set to the corresponding texel value. If the current value in the depth buffer is 'over' the sprite depth then processing for that pixel stops - it failed the depth test.


Graphics hardware is ridiculously efficient at this kind of task. All you have to do is tell the API to render something and all this gets done 'under the hood'. All you typically have to do with the depth buffer is remember to clear it at the start of each frame, just like the color buffer. The only thing they're doing different with the water in this case is that they're not clearing the depth buffer before drawing, but instead they're copying in a set of pre-computed values so that when the water is rendered it will have depth values to compare to in order to simulate a 3D interaction.

#5052679 How was this achieved?

Posted by Khatharr on 12 April 2013 - 10:03 PM

The z buffer belongs to the destination buffer, not the texture. In this case they're blitting the pre-rendered depths into the depth buffer. They rendered the scene in 3D and saved both the color buffer and the depth buffer. When they start the scene they draw the texture (the color) and then blit the depth values from the pre-render directly into the depth buffer. Once that's done they can place 2D sprites or whatever into the scene and get semi-realistic clipping. The water is just a dynamic texture on a plane, yes. If you think of the water as being a transparent plane and then imagine lowering that into a pile of pebbles you'll get a similar visual effect. Mind that the plane is not necessarily parallel to the screen.


Remember that when rendering you give each vertex a 3-dimensional coordinate. When the hardware renders the water it creates the plane mathematically. Each triangle is just 3 points (in a specific order). After those points are run through the rendering matrix to get their correct positions relative to the viewer, the rasterizer starts. The rasterizer checks each pixel in the viewport (probably the full screen in this case) to see if a ray from the front of the frustum to the back collides with the triangle represented by those 3 points. If it does then the depth value at the location of the collision is checked against the value in the depth buffer. If the collision is 'underneath' the existing depth buffer value then the pixel is skipped. If it's 'on top' of the depth value then the depth value is replaced, the color of the primitive at the collision location is calculated, any lighting effects are applied, and the pixel is colored accordingly.


So when they draw the pre-render and blit the depth values, after that point in the frame the scene is identical to what it would be if they had redone the full 3D render, but without all the work.


The graphics pipeline is complex as a whole, but it's actually just a combination of many fairly simple parts. Most of the parts are one means or another of reducing work that doesn't make sense. If you study how the three transforms work and understand that each primitive is rendered independently then you can easily see where all the other stuff fits into place.